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”.

Ugh.

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…

Regular Expressions on iOS

I’ve decided to take on the masochistic task of getting my hands dirty with NSRegularExpression. Here are some of my thoughts and findings:

– Regex is voodoo. What’s worse, it’s not even standardized. So all the tutorials on the web are not platform agnostic. I could use a recipe to match the things I’m interested in, but when creating an instance of NSRegularExpression on iOS, it fails as “invalid pattern”.
– Because of this, you WILL become a test driven developer. 🙂
– Start with a simple regex pattern that detects PARTS of what you’re looking to match, then add complexity. This way you can see what part of your pattern is failing.
– Don’t use the Number Sign # as a matchable character. It is protected but not documented! Use \u0023 instead. e.g. “\\b
– When you map/inspect your NSTextCheckingResult objects, it should have the same number of ranges as you have capture groups. You use these to get more specific about which capture groups were involved in the match. (Provides more granularity/control). The NSTextCheckingResult.range represents the range in the text associated with that one result!
– NSRegularExpression really doesn’t deal well with the hash symbol (sharps).

I ultimately reached a solution, but it never felt entirely ‘correct’ despite finding a way to produce the correct results.

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.

Autolayout and Self-sizing UITableViewCell

I’m not going to lie.  Autolayout is a massive pain.  But.  Ultimately it’s very powerful and you’re best to just go through the pain and learn it.

Even so, you should also get a bit familiar with it, then learn about the concept of self-sizing table view cells.  It’s quite important.  Basically, as long as there is a clearly defined way for a UITableViewCell to determine its own height via the auto-layout constraints, dynamic table view cells are pretty easy.

Unfortunately, there is a lot to learn:

This series

Then this

or even Apple

Quick Reference:

How to make sure a UITableViewCell autosizes when you have a label that you want to wrap around onto multiple lines.

1. Pin the Label at top left, bottom, right.

2. Edit the right constraint to be “Greater than or Equal to”, and then set the constant to be the right-most you want to allow that (probably view margin).

3. Set that right-most constraint’s priority to 750 (high), then set (on the Label!) it’s content compression resistance priority to 749.

Should be fine now.

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.)

iCloud Drive – What a disaster!

So, I’ve been working on a new version of my app Songbook Simple and I want to improve some of the file sync code.  Up until now I’ve been supporting Dropbox, with the original idea that a user can edit and modify all his/her songs from the convenience of their desktop, and it would just sync on the device.  This *has* worked, and *still* works, though it always seemed like a quick and dirty solution to me.

Enter Apple TV.  I thought it would be fun to make Songbook Simple Apple Tv compatible, but in order to do that, one basically has to support iCloud for syncing data.  As the Apple TV won’t be an editor, but just a viewer, we need to get data from somewhere, and I’m not so sure Apple TV is entirely Dropbox friendly yet.

So, I’m trying to implement iCloud support in Songbook.  I followed the excellent 4 part tutorial series written by Ray Wenderlich himself.   It all seemed to work brilliantly.  Files were syncing across iOS devices.

But wait.  Now what about using my Mac to edit files?  Well, turns out this is where iCloud Drive is a complete and utter disaster.  On icloud.com, there is no folder associated with Songbook.  On iOS, the iCloud Drive app DOES show my app folder and its contents.  On OSX, in the iCloud Drive folder, you don’t see anything associated with Songbook.  So my user workflow, namely, editing songs on your Desktop, is broken.

I’m all for “Automagic” for the sake of better User Experience, but if it’s “Autobroken”, then get rid of your magic because you’re killing us.

In order to restore the ability to edit the contents of my SongbookSimple folder, I had to open a terminal window, and do the following:

cd ~/Desktop
ln -s ~/Library/Mobile\ Documents/iCloud~com~softwarebarn~SongbookSimple/Documents/

Then, from Finder, navigate to the Desktop, then either move that Alias that just got made (called Documents) to somewhere better, or simply drag it into my Finder’s sidebar.

Great feature, Apple!  All these years to mimic Dropbox and it’s still a failure.  Yes, I followed ALL the instructions, and spent 3 hours this morning making sure I didn’t miss any.

HSHTMLImageRenderer !

So with permission of my current client (for whom I wrote the original code), I’m able to open source this component for all to use. I’m delighted I can do that because I think this component can be of good use to people.

HSHTMLImageRenderer is a way to be able to render HTML offscreen to images that can be stored in a cache.  It’s useful when you have many layout elements whose content is a small bit HTML that could be complicated and unsuitable for a UILabel, and it’s not feasible to have numerous instances of UIWebView everywhere.

Have a look. It’s over on my github page.

“Invisible Container” – HSPassthroughView

I’d like to revisit an older post which deals with allowing subviews in a view hierarchy to be touchable, but making the parent view completely “non-interactive”.

Sometimes you need a ‘container view’ that can simplify Autolayout Constraint animations.  You want the view to be ‘invisible’ whilst allowing its subviews to behave normally. Being invisible, you may also want to tell it to inherit it’s superview’s color, so to reduce the need for layer blending (better performance)

I present the updated HSPassthroughView:

#import <UIKit/UIKit.h>

IB_DESIGNABLE
@interface HSPassthroughView : UIView

@property (nonatomic, assign) IBInspectable BOOL inheritsBackgroundColor;  // defaults to NO

@end

@implementation HSPassthroughView

- (UIView*)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
    UIView *view = [super hitTest:point withEvent:event];
    if (view == self)
    {
        NSLog(@"A view was asked for a view, but this is a QLPassthroughView.  If you see this message but expect a touch to be found, look here.");
        return nil;
    }   
    return view;  //ensure this view will never register a touch!
}
- (void)awakeFromNib
{   
    if (self.inheritsBackgroundColor && self.superview) {
        self.backgroundColor = self.superview.backgroundColor;
    }
}
- (void)willMoveToSuperview:(UIView *)newSuperview
{
    if (self.inheritsBackgroundColor) {
        self.backgroundColor = newSuperview.backgroundColor;
    }
    [super willMoveToSuperview:newSuperview];
}
@end

This helped solve a problem I had that was on StackOverflow.