IOS Development

Feeling weird while doing MVC in iOS? Have doubts about switching to MVVM? Heard about VIPER, but not sure if it worth it?  Keep reading, and you will find answers to questions above, if you don’t — feel free to complain in comments. You are about to structure your knowledge about architectural patterns in iOS environment. We’ll briefly review some popular ones and compare them in theory and practice going over a few tiny examples. Follow links if you need more details about any particular one. Mastering design patterns might be addictive, so beware: you might end up asking yourself more questions now than before reading this article, like these: Who supposed to own networking request: a Model or a Controller? How do I pass a Model into a View Model of a new View? Why care about choosing the architecture? Because if you don’t, one day, debugging a huge class with dozens different things, you’ll find yourself being unable to find and fix any bugs in your class.”. Naturally

Introduction :  Up to now, we've used a single managed object context, which we created in the  CoreDataManager  class. This works fine, but there will be times when one managed object context won't suffice. What happens if you access the same managed object context from different threads? What do you expect happens? What happens if you pass a managed object from a background thread to the main thread? Let's start with the basics. Concurrency Basics Before we explore solutions for using Core Data in multithreaded applications, we need to know how Core Data behaves on multiple threads. The documentation is very clear about this. Core Data expects to be run on a single thread. Even though that thread doesn't have to be the main thread, Core Data was not designed to be accessed from different threads. Core Data expects to be run on a single thread. The Core Data team at Apple is not naive, though. It knows that a persistence framework needs to be accessible