Core Data Migrations – Woes…

So thankfully I won’t go into a misogynistic blog post a la frustrated Mark Zuckerberg in the movie “The Social Network”, but sometimes you just need to blog to let your technical frustrations out!

I’m doing some complicated Core Data migrations where the lightweight ones won’t work.  I’m migrating from one Core Data model to a completely different one, and I’m trying to map those properties over.

I’ve already discovered a wealth of information either through google, trial and error, and a bit of both, which I will share once I’ve got the entire migration code running.

I just have to say here however… I think it’s probably best to avoid these Xcode tools like a mapping model.  Because they’re buggy as hell.  For example, if you define a mapping model and provide source and destination models, but then change either of those source or destination models, the Mapping Model will no longer work, and even if you re-select the source and destination, it doesn’t matter:  You’ve just killed your Mapping Model.  Is there any info about this?  No.  Just “could not find a suitable mapping model”.


I’ve been trying to debug something for 3 HOURS because all you get is an EXC_BAD_ACCESS crash, and ZERO information as to what it’s all about, and NSZombies do nothing.

So I’m sitting here, taking shots into the dark and hope I discover something.

I question whether I should just give up on TOOLS, which are supposed to make your life easier, and just write the whole heavyweight migration in code.  If I had started on that 3 hours ago, I’d probably be done.  My data model is like 8 entity types.

Is it just me or is the quality of Apple’s tools getting worse?  It’s like they produce stuff that’s 80% good.  But it’s a tool chain, so 0.8 * 0.8 = 0.64.  So you see where this is going…


Nostalgia for old iOS

This sounds silly, but I kind of miss iOS development in the days before iOS 7. I kind of have this feeling the entire ecosystem has become less stable, less reliable, not as clear in its vision, and basically less easy than it used to be.

Don’t believe me?  Just look at all the different ways Apple has tried to solve Autorotation.  That API has just changed so many times.

The thing that actually inspired this post is actually not related to nostalgia because it’s an issue that has always been less than straightforward.  All I want to do is tell my navigation bar that the back button should have no text (just the arrow).

There are all sorts of posts on this, but none of them actually work.  Change the title of the back button in viewWillAppear: ??  Nope.  Override the navigationItem variable and set its back button to an item with no title?  Nope….

Just sometimes simple things in iOS are annoyingly not that way.

Developing for iCloud sucks

iCloud is the thorn in Apple’s side.  They have been trying to get this right forever.  Maybe it works now from an end-user perspective, but as a developer, what a rough, confusing implementation.

I have to say, when you work with the Dropbox API, it is intuitive, it is easy, it is straightforward. Perhaps you have to write a lot of boilerplate code, but then again, do you?  It manages files.  This name, that path, that revision number, that modifiedDate.  You sort out the rest.  How hard can that be?

I’m currently writing a sync engine that allows users to decide which cloud service they want to use to backup their data.  So of course it would make sense to have one common API that wraps the various services.

It went so smoothly with Dropbox.  The only difficulty I had was realizing that the serialization of date strings sometimes results in small differences in the Date that emerges, meaning I had to write a .isTheSameAs(other: Date) method, which checks to see if they are within X seconds of each other, then call those ‘the same’.

Then I moved on to iCloud.  What a clusterf•ck.  Talk about over-engineering and complete inflexibility.  I just want a list of files that are in the cloud.  No, Apple has to distinguish whether you have them locally or not, and gives them a different URL.  And all sorts of other weird stuff.

So I tried to find a framework that makes iCloud a little more user-friendly, called iCloudDocumentSync which I found to be pretty straightforward, all things considered.  And yet, it’s still a pain.  Because iCloud uses multiple URLs to represent the same document.  In the end, I have to sync the entire iCloud folder’s contents before I can start working with these with a common URL.  (Sure I could extract the file name I need).  Moreover, iCloud uses a thread to open each document, so if I want to batch download a lot of data, suddenly I have a thread explosion.  Now I have to deal with managing that.

All in all it’s just been a pain to work with it.  It seems opaque in its verbosity.  Meaning, the person who talks a lot doesn’t get listened to and understood.  There are so many callbacks and all sorts of weird things going on, it’s very annoying.  Just because they’re trying to save the developer time, they’ve implemented something weird and unwieldy if you don’t use it according to their use case.  I personally just use a UIDocument as a means to save data.  I don’t work with UIDocuments because my app’s data model uses the data, but not the file.  This just seems silly with iCloud.

Alamofire and nostalgic feelings for AFNetworking

So, in the Swift world, I presume a lot of people prefer to remain “Swifty”.  That is, why would you opt for old Objective-C libraries?  Out with the old, in with the new!

So, we adopt Alamofire.  Is it just me, or is this library a bit unwieldy?   I think it has a lot to do with Swift shorthand and often not knowing just what types are actually being passed around, especially given autocomplete.

On top of that, just when you get your head around a specific release, they make a new major release, breaking old APIs.  And if I’m going to have to keep updating my code to stay current because “out with the old, in with the new”, why don’t I just stay with AFNetworking?  I mean come on.  It’s networking.  For the mostpart it’s just “give me that data at that URL.  Here’s my auth info.”  Done.  Or “here’s some data for you.  Here’s my auth info.”  Done.

Anyway, it’s a rant.  I just don’t find Alamofire all that sexy.  It reminds me of dealing with civil servants.  The creators imagined this bureaucratic utopia that functions perfectly as long as everyone understands it.  Furthermore, we must not only understand it, but are fully on board with its vision.  Meanwhile, we the people are busy trying to write our own apps, and couldn’t really care less.  We just want to get data and post data and not have to deal with too much crap in the middle.

(Go ahead, snarky programmer.  Now tell me off, tell me to just use this, that, or the other.  Reject my feedback.  It’s fine.  All I’m saying is that AFNetworking seemed a lot easier to use.)

Today was the first day that Test Driven Development actually justified its existence

I’ve been making apps since iOS 2.2.  People tell me I’m good at it.  Meh.  There’s always a bigger fish.  I love what I do, so chances are I’m not horrible at what I do.

Today was the first day where I used Test Driven Development to actually develop code.  Don’t get me wrong; it’s not like I don’t write unit tests.  I do.  But what I’m referring to right now is where you actually are given the start and passing conditions of a test before there is any code written at all.  In my field of work, this never happens.  The design is ALWAYS a moving target.  Nothing in the startup world is ever known in advance, so although you could write unit tests, it doesn’t always make sense.

I’ve recently been working on the implementation of the rules of Canadian Ice Hockey.  (Don’t ask.)  The sport itself seems pretty straightforward.  Put the puck in the net.  Goal.  Increase Score.  No way!  There are a lot of complicated rules surrounding penalties, but thankfully there is a referee’s handbook that goes over all the complicated scenarios and tells you what the result should be.

Perfect for TDD.  I literally wrote all the unit tests before I wrote the code that would produce the expected results.  I love it because I have to be honest; the solver code I wrote just “feels bad”.  I’m not even certain how parts of it work, and I only wrote it this past week.

What unit tests tell me is: It doesn’t matter!  As long as the tests pass, the code does what it’s supposed to do.  Very satisfying.


What I miss about Objective-C

Don’t get me wrong; I love Swift and it’s my preferred language.  It really didn’t take long to love it.

That being said, I really miss the idea of protected and private declarations, and creating Category Headers to expose private API’s.

It’s like giving a class “special permission” to interact with the private API’s of a different class, if there are a few classes that operate more closely, but still limiting the exposure of some properties to objects that aren’t coupled as tightly.

In Swift you just expose them all and write comments I guess.  Perhaps I’ll figure that out when I become more experienced with Swift.

How Swiftly I began to love Swift…

So, my last post was a little nasty.  Written like a conservative populist, which politically I’m not, but I admit I had my reservations about learning Swift then, and I stand by that opinion at that time.  I’ll be brief this time.   I’ve now had a chance to really do some work with Swift and I have to say overall I quite like it, and never expected that to happen so quickly.  Why the change of heart, you might ask?

  • I guess I don’t like learning from books, but I like learning by doing.  I find a lot of tutorials out there on the internet kind of superficial and boring.  I joined a project where there was already enough Swift code but not too much.  I had the opportunity to contribute based on some code I could already work from.
  • I really do like a lot of the features, such as enums (and being able to use string types)
  • The syntax is pretty good.  It does make for readable, type-safe code.
  • I’m surprised at how quickly one can just start writing useful code
  • Since Swift 3, there really is no reason to say no to it.  Previously it all felt “too new” and not finished.  The compiler warnings were a total disaster. For a strictly typed language, having poor compiler warnings was the most discouraging aspect to it. (Hence the rant about German bureaucrats who aren’t helpful but just say no)
  • I’m sure other reasons here as well

Now, it’s not like I’ve become blindly religious.  Sometimes I don’t like to the strictly typed language, but I suspect my frustration comes from the typical approach of “well, in Objective-C, I could just…” and not yet knowing the equivalent approach in Swift.

But all in all, I think it’s pretty easy to get up and running and to start writing Swift code that is useful and readable.  I’ve seen some library code that tells me I still have a lot to learn, but for now I think it’s kind of a “no turning back” situation.

I’ve already basically done all the types of things I’ve done in objective-C, and find that I really didn’t use KVO that much anymore anyway, so I don’t miss it.

I thought I’d just round off that last angry post with something nice.