Roughly two years ago I started blogging about the challenges of developing a new Mac app. I decided to do so after reading Brent Simmons great series on Vesper development. I thought it was a great way to 1. structure my thoughts and 2. help the community.
It’s been one of the most fun times I’ve had in years. The kick I get out of creating something from nothing* is not easily found anywhere else.
Also worth mentioning is the Mac community: all fellow Mac developers I engaged with were very helpful and responsive, I’m extremely thankful for that. Thank you.
Enough rambling, about the app I’ve been -indirectly- blogging about: It’s called Denarius and it’s a Personal finance Mac app. For years I controlled my personal finances with excel; existing Mac apps had a lot to offer but they required a lot of micromanagement as well.
My goal for Denarius was simple: the app should tell you all you need to know with minimal effort.
I hope you like it, you can know all about it here. And you can get in touch with me via Twitter at @MarcMasVi
Will update you on how the app does and what I will be working on next.
* leveraging the awesome work of Apple developers who worked on all the frameworks I use.
When they are initialized both contain the same data. However once changes are applied to one of them -in this example the main- like adding, changing or deleting rows, the other will not know -in this example the background/private one-.
Therefore if we add objects to the main managedObjectContext, when we fetch the backgroundManagedObjectContext we will not get them.
How do we fix this? Well first we have to save the changes of the objectContext that was modified. We do so by adding once we’ve finalized the changes:
print(“ERROR: Cound not save Core Data”)
At this point we have saved the changes in the Persistent Store. We still have to ask the backgroundObjectContext to get them from the persistent store thought. For that we will use the automatic notification “NSManagedObjectContextDidSave”.
In the class where the backgroundThread is contained we will add an observer for the notification (note that we’re passing as object the context that was modified):
//Handle changes in core data for background thread
In this case you would be showing the notification after 5 seconds, more useful though is to plan it for a later date, like you can see in my commented code. The getDateOfNextNotification function simply returns the NSDate where I would like the notification to trigger.
If you plan to use this, for instance in App Delegate, you may want to check if you have already scheduled notification to avoid duplicates. You can do the following: