iCloud in your iOS Apps – Part 2: Key/Value Storage

In this part I’ll show you how to store and retrieve data using the NSUbiquitousKeyValueStore singleton, and how to receive the relevant notification so that your app can react if data has changed in iCloud.

Watch the whole series

Enjoy!

Watch the full course in one convenient playlist:
Catch this episode on my iOS Dev Diary Podcast:

iCloud in your iOS Apps – Part 1: Setup

In this 5-part series I’ll show you how to use iCloud in your iOS Apps. We’ll discuss the whole picture, starting with how to setup Xcode and your app, including App ID and Provisioning Profiles and I’ll demonstrate how to use all three flavours of iCloud:

  • Key Value Storage
  • Document Storage
  • and iCloud with Core Data

Setup and Prep Work

In this part I’ll explain how to create an App ID, a Developer Provisioning Profile and how to import it into Xcode. We’ll also discuss what else needs to be setup in Xcode to make your app work with iCloud, no matter which flavour you want to use.

Watch the whole series

Enjoy!

Watch the full course in one convenient playlist:
Catch this episode on my iOS Dev Diary Podcast:

How to check if the Main Window in your Mac App was closed

As is customary with other parts of Mac and iOS, the Main Window (or in fact any NSWindow) conforms to the NSWindowDelegate protocol. Sadly this isn’t mentioned in the class reference for NSWindow and you’ll have to guess.

The drill is the same:

  • hook up your window to a class as The Delegate
  • have the class conform to the protocol
  • implement the method you want to watch

In this example we’d like to see if our Main Window is being closed and react accordingly (for example, by closing down our super simple one window app). We’ll use AppDelegate as our Window Delegate:

Now that we’re conforming to the protocol, let’s listen to the following:

The if statement is optional, but in essence we’re asking “is the window that’s being closed self.window” which AppDelegate already has a reference to. If that’s the case, then we go ahead and save our Managed Object Context and quit the app.

If your class is the NSWindow delegate for more than one window, give each an identifier and query it accordingly.

All that remains to be done is to hook up our window to AppDelegate as a delegate:

Screen Shot 2014-05-09 at 16.59.52

How to dismiss the keyboard from a UITextField in iOS

In this episode I’ll show you how to dismiss the iOS Keyboard, which is commonly brought up by a UITextField – but doesn’t want to leave easy once summoned.

It’s easy to overlook a step in this procedure, so I thought a screencast is in order. We’re discussing two dismissal options here:

  • when the DONE button is pressed
  • and when users tap outside the textfield

The latter option isn’t built into iOS, but users have come to rely on this behaviour. I’m using Xcode 5.1.1 and iOS 7.1 in this demo.

Happy hacking!

Steps in a nutshell

The trick is to implement a delegate method from the UITextField Protocol named textFieldShouldReturn. In it we need to tell the text field to resign its first responder status, giving up its “focus” so to speak.

Here’s the method:

We can use this method to utilise the actual text value of the input.

For this to work, the text field needs to know that your class is the delegate. Either hook it up to the orange square in Interface Builder and select delegate, or declare it in code:

To make the keyboard go away when someone taps outside of it, drag out a huge button over the area that is not covered by the keyboard. Hook it up to a method and simply call the textFieldShouldReturn method to it. Even as of iOS 11, that’s the only way to make it work.

Watch the full course in one convenient playlist:
Catch this episode on my iOS Dev Diary Podcast:

What is Cocoa error 134140

This error can happen if you have several Core Data Model Versions and no Mapping Model. In a nutshell Core Data is telling you that it cannot infer your changes automatically when you add these options to the NSPersistentStoreCoordinator:

If you get this error you need to provide a Core Data Mapping Model. Note that in Xocde 4.x said file must for heavens sake not be in a group or subfolder, otherwise the universe as we know it will seize to exist.

How to avoid Redefinition of 'Category' as different kind of symbol error in Xcode

I got a weird error in Xcode 5.1 today while developing a Mac App which serves as a data entry tool for an iOS app: Redefinition of ‘Category’ as different kind of symbol. The weird thing is that the Mac App builds and runs fine, but when I import the model over to iOS I get an error at compile time:

Screen Shot 2014-05-08 at 19.09.19

The puzzle’s solution lies in something called “Namespacing”. Not that I even remotely care or pretend to understand this, but in a nutshell it means that the name Category is reserved and already defined in /usr/include/objc/runtime.h:

What that file is or where it comes from will forever remain a mystery to me, just like why it’s not a problem in a Mac App. I could probably try to figure this out for the rest of my days but really: life’s too short as it is. Let’s just

  • rename the Category entity
  • regenerate all NSManangedObject sub classes
  • remember Category as an evil string for the future

and be done with it. Note that you must rename the Entity as well as the Class it creates, and for good measure re-create all your NSManagedObject subclasses:

Screen Shot 2014-05-08 at 19.27.39

I guess that’s why at the beginning of a new Xcode project we have the option to prefix all our classes (which would undoubtedly avoid such problems in the future).

For those who care: