Tag Archives: ios

Opinion

CameraGPS debrief

As happy as I am with the way that my new app, CameraGPS, a GPS logger application for people who want to geotag their photographs, came out I can’t say that it’s exactly as I envisioned it at the start of the process.

The idea was something like this: many of the GPS logger apps in the App Store require you to either use iTunes file sharing (who connects their iPhone’s to iTunes any more?) or mail yourself the exported document or sign up to some third party fitness or trekking website. Mailing yourself stuff just didn’t feel very slick and I didn’t want to record my trails for fitness purposes.

I felt that there must be a better way. The better way, I thought, was to use iCloud to share the files between iOS and a Mac. This would require writing a recorder app for iPhone and an “exporter” app for the Mac.

It didn’t work out that way in the end. Here’s why.

You see all kinds of horror stories from people who have had to deal with iCloud. Most of those stories come from people who used the Core Data syncing, while there are a few apps that successfully use the document syncing model, not least some of Apple’s own. Using the document storage I figured that, worst case, if something gets screwed up it would only affect a single trail. Using Core Data syncing, an error could mean corrupting the whole database.

So this became the plan: record each GPS trail into a separate document. Because I wanted to “random access” parts of each trail and because I didn’t want to have to load the whole trail into memory all the time, I decided to use Core Data to manage the document. On iOS this is called UIManagedDocument.

The first and most obvious fail here is with UIManagedDocument’s cross platform capabilities. Or rather the lack of them. Unless you count iPhone to iPad as cross platform it just doesn’t work. There is a class on the Mac called NSPersistentDocument that is also a Core Data store and looks on the surface to do exactly the same thing… but it’s in a different format. On iOS it’s a “package” which includes a Core Data store. On the Mac it’s just the store. Mike Abdullah has written an open source component that attempts to be bridge the gap but — as we’ll see shorty — I didn’t get to the point where I was able to test it in anger.

But let’s take a step backwards. Let’s assume that all we need is to move data between iPhone and iPad. Then what?

Well, technically it works — in the sense that documents transfer between machines — just not in a way that would make sense to ship.

To make sense of why it doesn’t work let’s take a quick diversion to look at the format of a UIManagedDocument. As hinted above, it’s not a file. Rather it’s a “package” which a number of files within.

An important file is called DocumentMetadata.plist. This tells you about the rest of the package and is created when the document is. There’s little in here that needs to be changed after document creation. The interesting stuff is all stored in a SQLite file, which is stored in a folder.

When files are stored in iCloud you can’t just use NSFileManager to poke around and see what’s there. Instead you create a query using NSMetadataQuery — which supports both a predicate and a sort descriptor — and listen for updates. Updates come in two parts, the initial state and then changes to that state.

After a few false starts I ended up using KVO to populate a table view showing the current list of documents. This worked nicely, showing the full list, updating automatically when changes arrived over the network.

But, and it’s a big but, what if you want to sort the list. Pretty basic requirement, no?

One of the fun things about NSMetadataQuery is that it can only look for files. Folders are “invisible.”

Most of Apple’s documentation — where there is any — suggests searching for the DocumentMetadata.plist. Which makes sense but with two significant drawbacks: every file that you’re looking for now has exactly the same name; and the modification date is the creation date of the document rather than the time of the last update.

This means that you can’t sort the documents alphabetically or by modification date using only the metadata predicate. To get the names you need to listen for updates, copy them elsewhere and then butcher the file name, that is removing the last component and possibly the file extension.

To get the last modification date you probably need to open the document and do a Core Data query. This sounds pretty straight-forward but, again, there are difficulties. Remember that NSMetadataQuery tells us what’s available in iCloud rather than what has been downloaded onto the current device. Just because the query tells us the file is in iCloud doesn’t mean that you can open it immediately.

UIDocument helps us a bit here: if you ask to open a document it will download it if necessary. However there’s a big difference between opening a local file and downloading one over the network and then opening it. Also remember, at this point we’re not opening it as the result of a user request. We’re just trying to find the last modification date so that we can sort the list of documents conveniently.

None of this, of course, is impossible. It’s just a lot of faff for something that pretty much every app that wants to use UIDocument must have to go through.

Okay, so we get all that done. We’re good to go now, right? Not quite.

Part of the idea of using a UIDocument was that it would appear as a, well, document. But that whole thing about what NSMetatadataQuery “sees” comes back to haunt us.

The short, weird version is that if you configure the application to look for DocumentMetadata.plist, then that’s what is seen in the Settings app. Not very helpful as all the documents will all have the same name.

On the other hand you can configure the app to “know” about the document type. This means that the Settings app understands that they’re document and displays them with the correct “file” name. Unfortunately then the app can’t see the documents properly. Specifically, you can search for the document by name — which is nice — but you can’t actually open it. It’s odd and I’m not entirely sure what goes wrong, but when you call openWithCompletionHandler: it never actually calls the completion handler and the document never becomes available for use. (I initially thought that I just wasn’t being patient enough. I later accidentally left the app running for over two hours and the completion handler still never ran. That convinced me that it wasn’t a patience thing.)

I convinced myself that this couldn’t possibly be how it was supposed to work. My question on Stack Overflow didn’t get any answers and a reply to another, similar question said that the behaviour was “by design.”

I think it’s just broken and that no one is really using it. Either that or there’s a secret handshake that you have to give to the right person at WWDC.

So what’s shipping? Pretty much none of the above. I read about the new iOS 7 methods of Core Data – iCloud syncing and liked what I saw. Additionally iOS 7 comes with a few more APIs with better error handling hooks. This made me happier shipping with Core Data syncing. Just using “raw” Core Data meant that I could simplify a lot of code, use NSFetchedResultController and remove a bunch of the more fragile iCloud code (mostly NSMetadataQuery). While I was quite pleased with the KVO code I wrote, having far less code overall is a much bigger win.

And, in case you were wondering, I also de-scoped the Mac app and integrated Dropbox support instead.

But the bottom line is that this is all a lot harder than it should be. My concerns originally were around error conditions — something that has been very weak in iCloud since it’s introduction in iOS 5 — but it quickly morphed into questions about how it’s all supposed to work at all.

I once quipped on Twitter that you can tell which APIs are the ones Apple uses themselves as they’re the well designed ones. I think it’s pretty clear that Apple don’t use UIManagedDocument.

Programming

NSFetchedResultsController and iCloud

This took me a while to figure out so I thought it was worth blogging about. The short version: I’m using Core Data with iCloud syncing and it works… mostly. When starting up for the first time – when there is already data in iCloud –  none of the data appears in a table view, but restarting the app correctly displays it.

I know what you’re thinking: you’re not merging the updates into the right managed object context. Nope. Sorry. Thinking that was the problem is probably why it took me quite so long to track the real problem down!

So, what does the problem look like?

I set up my Core Data stack in the app delegate. Part of that includes connecting to iCloud:

    NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:@"XXX.sqlite"];
    NSDictionary *options = @{
                              NSMigratePersistentStoresAutomaticallyOption: @YES,
                              NSInferMappingModelAutomaticallyOption: @YES,
                              NSPersistentStoreUbiquitousContentNameKey : @"XXX"
                              };

    NSError *error = nil;
    _persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
    if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
                                                   configuration:nil
                                                             URL:storeURL
                                                         options:options
                                                           error:&error]) {

The app delegate passes the managed object context through to the main view controller which then uses it to create a NSFetchedResultsController:

    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    // Edit the entity name as appropriate.
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"XXX" inManagedObjectContext:self.managedObjectContext];
    [fetchRequest setEntity:entity];

    // Set the batch size to a suitable number.
    [fetchRequest setFetchBatchSize:20];

    // Edit the sort key as appropriate.
    NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"someTimestamp" ascending:NO];
    NSArray *sortDescriptors = @[sortDescriptor];

    [fetchRequest setSortDescriptors:sortDescriptors];

    // Edit the section name key path and cache name if appropriate.
    // nil for section name key path means "no sections".
    NSFetchedResultsController *aFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest
                                                                                                managedObjectContext:self.managedObjectContext
                                                                                                  sectionNameKeyPath:nil
                                                                                                           cacheName:@"Master"];
    aFetchedResultsController.delegate = self;
    self.fetchedResultsController = aFetchedResultsController;

	NSError *error = nil;
	if (![self.fetchedResultsController performFetch:&error]) {
        // Replace this implementation with code to handle the error appropriately.
        // abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
	    NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
	    abort();
	}

(Again, this is pretty much Apple-standard boilerplate code –  nothing clever going on here.)

But what I found was that when there was already data in iCloud, the records did not automatically appear in the main view controller.

Eventually I found that this was not a threading issue – merging the changes into one context and trying to read them from another – by adding an explicit fetch request on a “debug” button. Doing this I could see the new data, even though the fetched result controller could not.

In my app delegate I listened for a number of notifications: NSPersistentStoreDidImportUbiquitousContentChangesNotification and NSPersistentStoreCoordinatorStoresWillChangeNotification. My expectation was that NSPersistentStoreCoordinatorStoresWillChangeNotification would fire before switching from the fallback store to the “real” one and NSPersistentStoreDidImportUbiquitousContentChangesNotification would fire when the new data was available.

I was half right. NSPersistentStoreCoordinatorStoresWillChangeNotification fired on a background thread, so I used GCD to ping it onto the main thread and reset the context.

But NSPersistentStoreDidImportUbiquitousContentChangesNotification didn’t fire at all. I guess the objects didn’t change as such, they just became available, which feels like a slightly false distinction to me.

So my next guess was to fire the fetch request again. The data was visible in the main threads context so surely this would find the data?

Nope. (And don’t call me Shirley.)

I was getting pretty lost at this point so I ended up just semi-randomly stopping the code and looking around in the debugger.

And, long story short, I realised that fetch requests have a reference to the persistent store in them – check out the affectedStores method. This meant that the NSFetchedResultsController was happily, and correctly, reporting on the empty and no longer used fallback store and completely ignoring the new and fully populated iCloud store.

The simple solution was to listen for the NSPersistentStoreCoordinatorStoresDidChangeNotification and create a completely new fetch request.

- (void)storesDidChange:(NSNotification*)notification {
    self.fetchedResultsController = nil;
    [NSFetchedResultsController deleteCacheWithName:@"Master"];
    [self.tableView reloadData];
}

(I did think of just adding the new persistent store to the old fetch request but I wasn’t sure that this would create the refresh anyway and, given the frequency with which this is likely to happen, I thought it would be cleaner just to start from scratch.)

These weird problems almost always boil down to just a couple of lines of code. This time was no exception.

Opinion

Which Tablet?

I was recently asked to recommend a tablet. I thought my reply might be generally useful, so below is a lightly edited version of what I wrote.

The machine I’d recommend depends. It depends mostly on how much you want to pay and what it might used for. The good news is that, by and large, you get what you pay for. (Corollary: don’t get any of the really cheap ones. Argos, for example, do a really cheap one. Avoid it.)

The main ones I’d consider are:

Kindle Fire HD 7″ £119

By far the cheapest but very much tied to Amazon — indeed it’s pretty much sold at cost with the expectation that you’ll spend more money with Amazon later on. That means there are fewer apps (games), you can’t download/rent movies from iTunes, etc. But if you just want to surf the web, check email, etc. and play some big names games it would be fine. Probably worth spending the extra £10 to get the version without adverts (“special offers”) though.

Google Nexus 7 £199

Nicer hardware than the Kindle but mostly what you get is access to the Google App Store, which has far more apps, lots of which are free or very cheap. It runs Android, which is the main competitor to Apple and is generally considered to be pretty good, though I’ve not used it much myself. It’s also not tied just to Amazon (though you still can’t get iTunes) but you can get most of the Amazon stuff. Like the Amazon one, it’s cheap because Google expect to make money from you in other ways.

Apple iPad Mini £249

Better hardware than either of the previous two (metal rather than plastic case) but, arguably, a worse screen than the Nexus (physically bigger but fewer pixels).

iPad gives you all the iPhone and iPad software — which is typically better than Android. Also gives access to iTunes for music, movies and TV shows. The iPad software is often considered to be bit easier and less confusing than Android and you’d get stuff like FaceTime and iMessage (free text messages with other Apple users) which you can’t get on Android.

iPad mini with Retina display £319

As above but with a far nicer screen and is about four times quicker. It will probably last longer as it’s more future proof (but that’s obviously speculation at this point). Possibly hard to get hold of right now as it literally just came out and it “supply constrained.”

Apple iPad Air £399

As above but with a 10″ screen rather than 8″. I have an older versions of this, though the mini didn’t exist when I got mine…

(The prices above are “retail” prices. Some of the links go to the same product but for a lower price.)

It’s also worth noting that you can get more expensive versions of all of them that come with more space and/or cellular radios (so you can access the Internet when you’re out of the range of a friendly WiFI network).

It’s even harder to give general advice about this than the tablets themselves. In general, the more you want to download movies and large, complex games, the more capacity you’ll need. If you mostly surf the web or read books even the smallest versions should be okay. (Indeed, that’s what I use.)

The 3G/4G question is tricky. Me, I get the cellular radio because I do travel with my iPad and I have a Pay As You GO SIM which means I don’t pay a penny in months that I don’t use it. But it does cost more. You might prefer to spend the extra to get a larger storage capacity.

When I first got an iPad, it was because users of one of my apps were asking for a version that used the iPad’s bigger screen. I was skeptical that I would actually use it. These days I probably use it more than my Mac. I guess what I’m saying is that it’s worth getting the right product rather than just the cheapest.

Opinion

Notes on iOS 7

I’ve been using iOS 7 for a while now — for a couple of months on my iPad and about half that on my iPhone — so thought it was worth a quick summary of my experience. I’m certainly not going into the depth that Arstechnica have; I’ll do it all in a few bullet points.

The good

  • Control Center. Switch on and off BlueTooth and WiFi without having to go into Settings. I’ve been wanting this since iPhone OS 1 so this is more than welcome!
  • The look. It is controversial and it does take a bit of getting used to but overall I like it and it works well
  • I didn’t find the new look to be as jarring as I thought it would be based on what I saw in the screenshots
  • The “Today” view in Notification Center. All your notifications and stuff that’s happening shortly in one place. Felt like nice PowerPoint (Keynote, I suppose) material when I first saw it but I actually find it quite useful
  • The “back swipe” gesture in navigation views that goes back to the previous screen. I noticed how useful it was when I started trying it in apps that don’t support it. Tweetbot I’m looking at you!

The bad

  • Some of the animations look cool the first two times you see them, then they get really annoying as they take too long. Let me tap the frickin’ icons already!
  • Some “old” apps do look pretty bad. Hopefully they’ll get updated soon

The ugly

  • Glitchy, especially the iPad version. Nothing that makes it unusable but lots of little details — such as the keyboard not working on the iPad lock screen sometimes — that makes me a little surprised that they released it when they did
  • As a developer I’m not sure what I think about the auto-update feature for apps. I think I already get pretty high adoption when a new release comes out. However I’ve also had some rough x.0 releases that I’ve been happy have not been adopted super-quickly

Yes, there’s a lot of other stuff but these are the things that I can remember! However, as I said last year, some of the best features are those that blend into the background so much that you forget about them…

Opinion

Familiarity Breeds Contempt

This week I did a presentation at the London iPhone Developer Group meeting. Given my experience with using lots of APIs, I thought it might be a good, if dry, topic. I tried to spice it up by complaining about lots of them and trying to condense that negativity into some useful lessons to take away.

Most of the other discussions of this subject that I’ve seen focus on designing libraries but I thought the same lessons could be applied to all kinds of interfaces, from Objective C libraries to REST API’s for connecting to web services. (I don’t mean to suggest that the focus of the two articles I link to is wrong. They’re both very much worth reading.)

You can see a PDF of the slides here (though they might not make much sense without what I was saying at the time), but the gist is as follows:

  • Design your APIs around use-cases. Many appear to be designed around “how can I made the data I have available.” This is the wrong way round
  • Clients need to access data in a predictable, reliable way. Being clever accepting any old junk and trying to do the right thing is often not the right thing to do
  • Communicate how it works and how it’s going to change clearly. Examples and sample code are always useful
  • Think about error cases. “Something went wrong” is not a good error message
  • Think about the devices that people are likely to be accessing your service from. Mobile apps have latency, bandwidth and CPU constraints that desktop computers and other servers do not. The iPad 4 has more resources to throw at a problem than an iPhone 3GS. Your code might need to work on both
  • Be consistent. Make your API look like other, similar APIs and use the patterns of the technology you’re using. That means delegates and return codes for Objective C, inheritance and exceptions for C#
  • And, most importantly, use your own API. Don’t keep special “secret sauce” for your self. How else are you going to know whether it works than by actually using it?

Ideally I’d end a presentation (or blog post) with salient advice on the best way to do something. This is an exception. I don’t think there’s a one-size-fits-all solution and I’m generally weary of Best Practice guides.

So I’ll end by noting that poor APIs result in poor applications. It’s worth investing the time and energy in doing it well. Your users and your future self will thank you.

Opinion

No Massive Google Play Privacy Issue

If you follow any iOS technology blogs you might have seen this recent scandal:

If you bought the app on Google Play (even if you cancelled the order) I have your email address, your suburb, and in many instances your full name.

This, they say, is bad because this is not what happens with Apple’s App Store.

However, I don’t think Google are doing anything weird here, and I say this as someone who is not a fan of Android. The commercial relationship between developers and Apple is different from the relationship between Google and developers ((Please let me know if I have any of this wrong. I don’t develop Android software but this is my understanding of how it all works.)).

In Apple’s case, the developer has a single customer (Apple). You licence your code to Apple and Apple sells your app. The end users relationship is with Apple, not the developer. You get royalties, much in the same way that you get royalties when you publish a book. I’m still waiting for my million dollar advance from Apple, but the principle is the same.

Google plays a different role. They’re just an intermediary. The customers buys the app directly from the developer (using Google Wallet). This is why the developer has access to email, location, etc.

Saying that this is a privacy issue is like paying for a latte with a credit card and complaining that Starbucks now has your Amex number and name. Of course they do.

There are always stories of disreputable restaurants skimming credit cards and defrauding consumers. The trick, insofar as there is one, is not to eat at those restaurants. Similarly, if you think a developer is likely to use your data in an underhand manner, don’t download their software. It’s that simple.

Should Google be more upfront about who gets what details? Possibly. It never hurts to be open and honest — dare I say, not evil — about privacy matters. But I don’t think what they’re doing is inherently bad.