Same experience, except i would strongly advise against using core data, and i would also recommend to do layout with autolayout in xib ( not storyboards) for complex views, instead of code, and use manual layout only for performance critical code.
Many people don't realize they don't actually need a database.
. Most app have their full set of data weight less than a megabyte, so it fits in memory without any trouble.
. Querying is often never more than a call to a map on an array ( simpler to debug than a core data query, and type safe)
. Atomicity with concurrent access, if you absolutely need it, is a real mess in core data. Even with core data you often end up doing everything on a single thread anyway (and most often this is the main thread).
. Core data will blow up in your face, either when trying to upgrade your app, or duplicate the data for backup. In ways that'll make you sweat everytime you push a new version.
So my advice is to work with a dumb data structure ( structs and not classes) that you dump in a file when application goes to background (or periodically if you want to play it safe), and perform your queries manually, and load all at once at application start.
And if you need parallell access to the data, work with message passing style concurrency, and have a data component that works within its own thread ( very easy to do with gcd). You'll feel like writing a bit of boilerplate code, but at least you'll understand what's going on.
Thanks for your reply! I don't agree that concurrency is a mess with Core Data, it has good support for this. Of course you need to be careful to get things right, but this goes for whichever technology you are using. As for upgrading the app, if you are doing anything else than a lightweight migration you need to know what you are doing, but that problem doesn't at all go away if you roll your own database layer. I believe Core Data is actually of great help in solving those pretty complex problems.
The whole managed object context paradigm is clunky. It's meant to be a system of nestable sandboxes for performing discardable operations on the database, but when you start to mix concurrency inside, it becomes intractable.
IMHO, i don't think that 80% of the people using core data understand the concept of managed object context properly. For example, i'm pretty sure everyone wonders what's going on when they try to reuse an object from a context in another and get weird behaviors.
My main point isn't that one should recode a database manually, but that it's extremely rare to need that kind of system in a mobile app in the first place.
Also i think that performing a set of sql query in an sqlite database is much much simpler than creating a correct process for a core data model migration.
Appreciate your thoughts on this! Core Data is far from trivial but can also be incredibly powerful. I actually think a lot of apps can benefit from the persistence and advanced notification system it offers.
iOS developer for 7 years. Not sure I agree with every point.
- Storyboards are incredibly, incredibly helpful. I work on complex UI with well structured layout constraints, sometimes with dozens of constraints per view controller. That's a lot of boilerplate code that you'd need without a storyboard. Also, you can see the layout in real time as you create it. No need for a run and check workflow to get layout parameters exactly right.
- While I agree about not using external frameworks for the most part, there are some that I've found incredibly helpful. Recently I used one along the lines of 'TOCropController' from memory. Looked great, no changes needed - saved heaps of time.
- I'm a big fan of Core Data, but I've also worked on projects that it hasn't been a good fit for. I once helped move a project to a straight SQL database (reason was mostly performance related).
- While I mostly agree with going native, there are always exceptions to the rule. The native experience is always best, no doubts there. But sometimes cross platform can save a ton of time, and doesn't detract from the goal of the software.
Interesting to hear your view on Storyboards. I know what many developers agree with you althought I have never really understood why :) Good that it works for you. And thanks for sharing your thoughts on the article!
The advantages of Storyboards or other parts of Interface Builder could have been had without the disadvantages; they just weren’t designed properly.
For instance, there is no particular reason they couldn’t have a “view equivalent code” or “convert to code” or similar button allowing someone to start in a visual layout environment but still see what they end up with (optionally choosing to maintain only the code).
Similarly, Apple continues to be terrible about unnecessarily modifying files and creating revision-control nightmares, and this is just poor design. They could have created Storyboards in a way that works with teams and code repositories.
I prefer the way Android does things for layouts. You write XML (yeah it's XML, but it works) and Android Studio will generate a preview on the other side of the screen.
9 comments
[ 5.1 ms ] story [ 24.7 ms ] threadMany people don't realize they don't actually need a database.
. Most app have their full set of data weight less than a megabyte, so it fits in memory without any trouble.
. Querying is often never more than a call to a map on an array ( simpler to debug than a core data query, and type safe)
. Atomicity with concurrent access, if you absolutely need it, is a real mess in core data. Even with core data you often end up doing everything on a single thread anyway (and most often this is the main thread).
. Core data will blow up in your face, either when trying to upgrade your app, or duplicate the data for backup. In ways that'll make you sweat everytime you push a new version.
So my advice is to work with a dumb data structure ( structs and not classes) that you dump in a file when application goes to background (or periodically if you want to play it safe), and perform your queries manually, and load all at once at application start.
And if you need parallell access to the data, work with message passing style concurrency, and have a data component that works within its own thread ( very easy to do with gcd). You'll feel like writing a bit of boilerplate code, but at least you'll understand what's going on.
Reading the documentation on concurrency and managedobject context would make any people's eyes go blank (https://developer.apple.com/reference/coredata/nsmanagedobje...).
IMHO, i don't think that 80% of the people using core data understand the concept of managed object context properly. For example, i'm pretty sure everyone wonders what's going on when they try to reuse an object from a context in another and get weird behaviors.
My main point isn't that one should recode a database manually, but that it's extremely rare to need that kind of system in a mobile app in the first place.
Also i think that performing a set of sql query in an sqlite database is much much simpler than creating a correct process for a core data model migration.
- Storyboards are incredibly, incredibly helpful. I work on complex UI with well structured layout constraints, sometimes with dozens of constraints per view controller. That's a lot of boilerplate code that you'd need without a storyboard. Also, you can see the layout in real time as you create it. No need for a run and check workflow to get layout parameters exactly right.
- While I agree about not using external frameworks for the most part, there are some that I've found incredibly helpful. Recently I used one along the lines of 'TOCropController' from memory. Looked great, no changes needed - saved heaps of time.
- I'm a big fan of Core Data, but I've also worked on projects that it hasn't been a good fit for. I once helped move a project to a straight SQL database (reason was mostly performance related).
- While I mostly agree with going native, there are always exceptions to the rule. The native experience is always best, no doubts there. But sometimes cross platform can save a ton of time, and doesn't detract from the goal of the software.
For instance, there is no particular reason they couldn’t have a “view equivalent code” or “convert to code” or similar button allowing someone to start in a visual layout environment but still see what they end up with (optionally choosing to maintain only the code).
Similarly, Apple continues to be terrible about unnecessarily modifying files and creating revision-control nightmares, and this is just poor design. They could have created Storyboards in a way that works with teams and code repositories.