Procastination tweets (micro.blogs) whilst I avoid the next chunk of work.

One more thing: IMAP response parsing is insane. Of another era so I have to forgive its quirks. Using Swift enum for parser pattern matching has been awesome though. When I get a chance will write something about it.

Also, Swift-first approaches for my Realm and MailCore alternatives make me smile. 😀

I’d previously rolled my own object store to replace Realm to remove that dependency and add fubctionality that it did not have.

Phew. I’ve rolled my own (very incomplete) IMAP client built on the new iOS12 Network Framework. Now to remove MailCore which has been fundamental to getting to where I am but it’s time to remove by biggest 3rd party dependency and evolve my own client as and when needed.

I no longer actually use MS Office as each time I try to open a doc to read I have to sign in with my Microsoft credentials that I have to reset every time due to infrequent use and I just can’t be bothered any more.

Annual argument about who gets to put the fairy on the tree. And they why wonder why I don’t enjoy xmas. Just a series of pointless arguments about nothing.

One difficulty I have with IMAP is that there is very little documentation for implementers to go by that I can find. I had to read a python imap library bug report in order to confirm my reading of RFC3501 whilst reverse engineering real responses from a gmail server.

Finally got the an IMAP response with string literals containing CRLF sequences to scan into a single line to pass to the parser. Created inline references to the literals using a modified literal syntax. Utter madness.

More IMAP weirdness conquered today.

Project Manager follow up. After trying out a dozen or so solutions, I have now settled on OmniPlan.

I’ve spent many hours over the last couple of days researching project management tools for small developers. Trello is currently my top pick.

Now I have my new iPad Pro 11”, I’ve gathered up all the rest in the house. How many iPads constitute a problem? Is 7 too many? I still have 2 originals.

Having switched from CoreData to Realm, I thought it would be useful to note the key differences.

Firstly, I’m not using the cloud features of Realm and will probably use iCloud to sync data. I’m choosing free services and Realm is free to use if you don’t need to sync via their cloud platform.

Both CoreData and Realm use Objective-C based classes to instantiate real objects that are backed by some kind of store. CoreData uses an sqllite database by default so you will need some sqllite tools to view and edit the database by hand. Realm uses a proprietary format but they have a browser available for free on the Mac App Store to view and edit the database.

Out of the box Realm is much easier to get your head around than CoreData. CoreData manages objects explicitly in a ManagedObjectContext which you have to save to persist any changes whereas Realm persists all changes immediately within write blocks. To use CoreData you need a deep understanding of the API which is spread across a number of related classes. You can almost jump straight in with Realm. A major advantage I’ve found is that because Realm’s changes persist immediately, if your app crashes or you quit the simulator, you can inspect the database to see how it looks. Using CoreData, simply stopping the emulator without first saving the context, means you lose the database state at that point. This is almost enough on its own to make me stick with Realm. It may be less efficient and you could just save context on every change in CoreData but it feels like you are working against the API when you start doing things like this. It is worth remembering that Realm blocks when writing and access will cause a thread exception if not executed on the main thread.

Creating a schema differs too, using CoreData you build a model in XCode which generates the classes used to instatntiate the data into objects. Again, Realm is simpler in that you just have to inherit from Object and mark properties that you want to store as @objc dynamic. There are a number of functions you can override to help customise the way your objects persist etc. I like the visual repesentation of the model in XCode and it is arguably easier to work with one-to-many and many-to-many relationships with the XCode model editor than it is to use the LinkingObjects() functionality in Realm.

I think of a Realm class as a table definition and you can easily get a live result set by calling realm.objects(MyObject.self) which will continue to fire as rows are added, deleted or updated. You can add predicates to the results set so that you get pre-filtered and sorted results or you can map them to an array. In CoreData you can do similar things but again the API in Realm is simpler.

CoreData allows you to set how to deal with null references which is handy if you want deletions to cascade and not leave your database full of nils or references to objects that no longer exist. This is supposed to be coming in a new release but until then I have written a Cascading Deletion API for Realm which I will publish in due course. In conclusion, having been through the hard graft of learning enough about CoreData to use it, I was reluctant to switch to anything else but the relative simplicity of Realm and the fact that it is just that bit more friendly when repeatedly launching and quitting the simulator means I’d recommend using Realm over CoreData.

This article was originally posted on Medium, October 31st 2017

FIRST.