Marcus Zarra (comments):
In the best way, we go back to having one PSC, but we’re going to use the new APIs in iOS 6. We’re going to add a private MOC that talks to that PSC. Then, we’re going to add our main context and define it as a main context, and we’re going to make that a child of that private MOC. Any data processing will be below the main MOC, so we will have three levels of contexts.
[…]
This design allows us to have asynchronous saves, which is extremely important. It allows us to save and to consume or process data without blocking the UI. A user can happily scroll through our application, look at data, play with it, and we’re not telling them that they have to wait for us.
[…]
We have an extra level of indirection between the PSC and the main MOC, so we will get a little bit of slowness there. When I say little bit, I mean if I build up a test case it does thousands upon thousands of iterations, I will find a 1-2% variance in the speed.
[…]
You can use notifications to force one child to consume updates from the other child, but don’t do this. It’s just a bad idea.
Concurrency Core Data iOS iOS 9 Mac Mac OS X 10.11 El Capitan Programming
Soroush Khanlou:
Nobody has any idea what the words “view model” mean, and so they can’t agree on what to put in them. The concept itself is too abstract. None of these writers would disagree about what goes in a Validator class, or a Presenter class, or a Fetcher class, and so on. Those are all better names with tightly defined roles.
Giving the same name to a wide variety of different objects with drastically different responsibilities only serves to confuse readers. If we can’t agree view models should do, what’s the benefit to giving them all the same name?
Update (2015-12-21): Ash Furrow (comments):
Next, does MVVM encourage objects that have many responsibilities? Sure, I guess it does. But again, the alternative that most iOS developers are familiar with is a massive view controller. So compared to MVC, MVVM is just telling you to use objects with one fewer responsibilities, which is a step in the right direction!
[…]
I argue that moving to MVVM (keeping the existing app structure, plus view models) is still a great idea. Separating as much code from the view layer as possible makes it way easier to further factor those components into smaller-yet objects.
Jason Brennan:
Both articles, I think, are really arguing the same things, but maybe from different directions[…]
Craft Model-View-ViewModel (MVVM) Programming
Greg Heo (via Natasha Murashev):
First up we got the “Can do” protocols. And these describe things that the type can do or have done to it. And they also end in the -able syntax which makes them easy to spot as you’re browsing through the headers. Here’s a first example: A type that conforms to the Hashable protocol, means that you can hash the thing down to an int.
[…]
Next step are the “Is a” protocols, and these describe what kind of thing the type is. In contrast to the “can do” protocols, these are more based on identity. That means conforming to multiple protocols of this kind feels the closest to something like multiple inheritance in Swift. You can identify these protocols in the standard library because they end in the word “-type”. And this is fully half of the standard library, something like 35 or so of those 54 are of this kind. Let’s look at an example. CollectionType is a good one. Not surprisingly Array, Dictionary, and Set conform to CollectionType. Maybe slightly more surprisingly, things like Ranges and String views.
[…]
Finally we have the “Can be” types. Rather than just an alternate view of the same thing, as we have already seen, these are more about straight on conversion. Changing from type X over to type Y. And these ones end in the word “-Convertible”. So that means that the type can either be converted from or converted to something else.
Language Design Programming Swift Programming Language
