Hi, I'm Jeremy Foo.
I write software to make lazy people lazier.
tweet @echoz email jeremy@ornyx.net
Its been about 3 weeks, but I’m finally done with a piece of work that will be used (hopefully) in the iCloud capable version of Mindnode.
MNCoder is what I’d call a clever hack using NSKeyedArchiver and NSKeyedUnarchiver to help with portability of certain Apple classes between iOS and the Mac. If you worked on both platforms, you’d know that iOS has its own implementation for colors and fonts. With iOS 4 this has been extended to NSAttributedStrings that take Core Text attributes instead of the nicer AppKit additions to NSAttributedStrings.
While I’d admit this is a somewhat complicated way of going about things, 2KSLOC to be exact, I figured this was the most straightforward and intuitive way to help people understand and possibly contribute additional code in the future.
What MNCoder does is that it uses a neutral platform independent NSCoding compliant object to store the base attributes that is needed to reconstruct an equivalent on either platform. Using #ifs, the object will give you the appropriate object. Adding to the system is NSCoder which helps with the finding and replacement of objects at runtime when doing serialization.
Its pretty much like old school language translation. Translate your source language into a intermediate version and then translate that to the target language. Nothing too fancy and easily understood.
The work is released under a BSD license which Markus has nicely given his approval of so here’s hoping it’ll have more contributors as it goes along.
Nice side effect of this is that I’ve had extensive time with Core Text and I’d say its pretty fun.
Everyone’s first encounter with Core Data would be through books and the occasional glance at the documentation. No one tells you what are the base tips in bullet points that you need to know. Having worked on Core Data for the past 9 months, I thought it’ll be a service to the community to at least commit something to Google’s memory.
- Everything except NSManagedObjectContext is thread safe.
- Create NSManagedObjectContext in new threads prior to using them. Pass them the NSPersistentStoreCoordinator of any NSManagedObjects across threads is fine.
- NSManagedObjectID is your friend. Always use it if you are doing threading.
- NSManagedObjectID is sometimes temporary. Use obtainPermanentObjectIDs to ensure that they are permanent.
- Getting a permanent ID might cost disk access so use wisely.
- Process cross context saving on the thread that the NSManagedObjectContext was created.
- Instrument’s time profiler is your friend to find where Core Data calls are taking a long time.
- Additionally, you can also get SQL statements that are generated as debug messages in console by turning on a flag.
- Use as little relationships as possible when fetching objects. Easier to fetch criteria based on the actual operating object and have the fetch also fetch all relationships.
- Sometimes it is easier to spin off a thread to fetch results and process them before calling the completion block with results.
- Have a manager to handle all Core Data fetching of objects instead of being smart and trying to have individual managed object subclasses handle everything.
- NSFetchedResultsController is sometimes a bitch when sending notifications of changed content. Don’t use UITableView’s reloadSectionsWithAnimation and its siblings when crashy happens.
- Don’t look into [NSManagedObjectContext registeredObjects] to get objects back. They might already have been deleted but still cached. Stupid stupid me.
- Always test Core Data performance on device.
- Always do fetches on entities that you are filtering criteria for then use inverse relationships that are prefetched to get the data you really want (Basically think topsy turvy; less database joins the better because this is an object graph).
Not too sure if this is the right way of doing this, or if anyone has even tried, but be sure to check the registeredObjects NSArray of the NSManagedContext prior to fetching stuff. This of course only applies to SQLite backed stores, and this is done to reduce SQLite queries and inevitably disk I/O.
You can effectively query the registeredObjects using almost the same predicate as your subclassed NSManagedObjects in order to ensure that the NSManagedObject you want is the same.
Have been very much inspired by the work on nodejs. For those of you who don’t know, nodejs is a basically a system to do Evented I/O using Google’s V8 Javascript engine.
One such application of nodejs is the development of servers both HTTP or socket based that doesn’t require the spinning up of threads to handle connections and/or network events. Callbacks are assigned to events and when those events happen, the callbacks are ran. No threads, easy peasey, low overheads, etc.
Currently there are 2 ways to do NSURLRequests. You can either wrap it around a thread and execute the operation synchronously or implement its delegate methods and have it run within the runloop.
JOURLRequest is an encapsulation of the NSURLRequest and its delegate methods to provide for a way to easily implement run loop based event-ed NSURLRequests.
There’s this curious thing about working on Xcode.
I’ve never seen myself, upon finishing a project, go immediately back to the IDE and start on a new one. Has never happened to me back in my Windows days with Visual Studio 5.0, 6.0, .Net and what not. Has never happened to me with NetBeans and whatever other incarnation of a Java IDE for school.
Maybe its just being a fan boy, but seriously, an IDE? Comparing Xcode to something that is more featured and complex like Visual Studio, you get a feel that Xcode is not truly in the the same game.
Hell, for newbies going to Xcode for the first time, its the most unintuitive POS ever. And yet, it still is a joy to work on once you get the hang of it.
I sometimes think, Objective-C has a part to play. But I can’t be sure.
Working on a new project. Using stuff learnt from the initial work on Traversity. Namely the process where creation of the data model and associated libraries are done first and foremost before connecting up the GUI.
As a usual practice, the library will be open source. No sense creating something that no one else will use. Check the progress on Github.
This should be fun.
