@Sven Groot: thx sven. afaik your 1st example is the one in use. status (lower case) is always on an instance of Something and should only ever be touched by 1 thread. i guess my question was if it's safe for multiple threads to read/access the enum type at the same time.
@Proton2: mine? yes. others? no. :P
creating objects whose sole purpose is data transfer. that, and "adapter"-type interface implementations.
ahh gotcha, if it's a member of something else... lock that member. for legacy reasons i don't want to get into, let's assume the enum is being used like a global static store for common strings across multiple threads. i'm trying to track down a rare, quirky bug in prod and i think there might be contention on a few huge enums. i've been looking for an excuse to use concurrentdictionary but ripping out all the enums will be a big undertaking.
i'm hopeful... xamarin could use some competition in the .net space. i've noticed a trend in enterprise towards mobile/tablet driven mostly by users who bring consumer-oriented expectations to line of business apps, regardless of legacy or the fact that you cannot possibly cram a million mission critical controls/features into a slick, minimal ui.
100% agree... in fact, i ripped out all the breeze stuff and am doing my own datacontext 'service' just using basic jquery xhr requests and to my amazement everything worked the 1st time by just following the demonstrated pattern with the included logger service.
the way things are wired up by default (as long as you follow naming conventions), you get an automatic 'merging' of the current viewmodel onto the view for ko binding, but you don't even HAVE to use this. if you choose to, you can just handle viewAttached() in the viewmodel (which acts a lot like the docready() in jquery, although this admittedly gets away from the declarative binding that ko brings and puts you back in the 'select and modify' pattern... i'm okay with that for now).
the durandal framework exposes a few 'page-like' events that are very, very convenient. all you have to do is define them as functions, export/expose them through the viewmodel and they get called when the page (viewmodel) activates, deactivates, viewAttached, CANdeactivate, etc... SUPERB stuff.
you can do so much from this starting point, if you just know a couple of the quirks/hacks. i'm still trying to wrap my head around the functional/promise/async aspects of the js language. things that look like hacks to me are embraced language features!
i just pulled this project with nuget... wow. it's like a masters course in client side architecture.
kudos to john papa and the author's of the respective libraries. it's eminently easy to extend by just dropping in new html/js files for views/viewmodels. wire up the viewmodels to ko bound data service webapi endpoints and everything just works.
the freaking back button works like you would expect without doing a single thing!
i'm working through the samples to figure out 'where does my jquery go?' and demystify the magic, but my initial impression is good. i think right now this is as close to having a ms sanctioned client-side design pattern as you can get.
i guess upshot is gone and now breeze is in?
@Ian2: Fair enough... I haven't played with Windows Movie Maker since it was first released but I do remember it being surprisingly quick and to the point.
The killer features for me with Vegas:
1) Audio is a first class citizen - the whole thing reminds me of an old school audio editor/mixing desk. VSTs are supported and the built-in Sony dynamics are world class.
2) Automatic crossfades of audio AND video (with adjustable curves) if you just overlap video or audio tracks on the timeline - HUGE TIMESAVER
3) Editing is dead easy right on the timeline. there is no forced antiquated analogy that most nle's embrace (although it's there if you want to use that analogy). Split a clip by just pressing 's' and delete the trim. you can do a lot of your editing by just knowing that 1 hotkey.