The iOS Dev Diary

In this series I’ll show you how to create Popovers on iPad. They’re fairly easy to create once you get the hang of the inner workings of the UIPopoverController.

I’ll show you how to create basic Popover in code and in your Storyboard, and we’ll discuss how you can retrieve data from a Popover when it’s dismissed. We’ll do this with a simple UIDatePicker. In the last video I’ll demonstrate how you can pick images from the camera roll using the UImagePickerController with a Popover – which is how you’re meant to do it on iPad.

The series contains three videos in total:

Enjoy!

In this series I’ll show you how to create Popovers on iPad. They’re fairly easy to create once you get the hang of the inner workings of the UIPopoverController.

I’ll show you how to create basic Popover in code and in your Storyboard, and we’ll discuss how you can retrieve data from a Popover when it’s dismissed. We’ll do this with a simple UIDatePicker. In the last video I’ll demonstrate how you can pick images from the camera roll using the UImagePickerController with a Popover – which is how you’re meant to do it on iPad.

The series contains three videos in total:

Enjoy!

Sometimes it’s just easier to start from an existing Storyboard rather than build everything again from scratch. Especially so when you want to create an iPad version of your iPhone app.

When you change your deployment info to Universal, Xcode even offers to copy your existing storyboard for you. That’s really nice – but even though it behaves like an iPad storyboard, when you open it in Interface Builder it still looks like you’re creating an iPhone layout. This makes re-arranging things difficult.

Help it at hand with a simple tweak. Under the hood, a Storyboard is just an XML file and as such as a plethora of key/value pairs we can change by hand.

First, make sure you display your layouts in “3.5inch” mode. You can do that by clicking that little icon at the bottom of Interface Builder:

Next head over to the File Inspector and right-click your storyboard, then select “Open as Source Code”. This will display all that XML code.

In the second line of the document you’ll find a very long line – somewhere in it you’ll find something like this:

Simply change that line to

This will make Interface Builder display your storyboard with iPad characteristics. All we now have to do is to make it look like a Storyboard again rather than XML code – so head back and right-click on the file again, then select “Open as Interface Builder – iOS Storyboard”.

In this final part of the series I’ll let you in on a little secret that will help our app synchronise iCloud Core Data for the first time when it’s installed on another device.

Some devices it appears don’t display existing iCloud results upon first launch. To remedy this, I’ll show you how to re-fetch the Fetched Results Controller in your sample app.

Enjoy!

In this part we’ll talk about how to make your Core Data powered app work with iCloud. This involves adding an option to your persistent store coordinator which will allow Core Data to write log files to iCloud. When changes are detected, the local Core Data store can merge them using those log files.

Here are the iCloud methods I added to the MasterViewController. First the observers under viewDidLoad:

And here are the event handler methods:

Here’s the demo project that I’m building. Don’t forget to change the Bundle ID and your Team ID to make it work on your devices:

Enjoy creating some rad iCloud apps

Enjoy!

In this part I’ll show you how to use your app’s ubiquitous folder to store arbitrary files in a user’s iCloud store. We’re not going to cover the UIDocument class here because it adds a layer of complexity to an already difficult subject, and for simple files it’s just not necessary. We’ll also cover how to download new files if iCloud changes have been detected.

There are two code snippets I’m referencing here: one is the method to retrieve your iCloud Documents folder (don’t forget to make it public like I did). This one goes into the AppDelegate.m:

I’m also talking about the NSMetadataQuery which will detect changes in your iCloud Documents folder. This is a custom initialiser so you’ll need to create a property for it. Here’s the initialiser – in the video I’m using it in my ViewController class:

To kick this into action you’ll also need to add an observer under viewDidLoad:

Enjoy!

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.

Enjoy!

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:

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.

Enjoy!

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:

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!

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.

I’ve previously shown you how to populate an NSTableView using Bindings and an array controller. Today I’ll show you how to do it in code.

It’s relatively simple and very similar to powering a UITableView. The main difference is that in Cocoa we don’t have a controller object that comes bundled with our view, so we’ll have to create one manually (or use an existing class). Here are the steps:

In this example I’m using the numbers 1-10 in two arrays: as numbers, and as written out values – so that two columns of the table view can be populated with different items.

Next we’ll implement the following two methods: the first for returning the number of rows, and the second for returning the relevant data in each row:

Notice that in the second method we’re not referencing the columns with a number (like we do with rows). That’s because the user could reorder or remove columns. Instead we’re using the column identifier which you can set in IB.

If you want to react to user selections in your code you need to implement the NSTableViewDelegate Protocol and also connect your table view’s delegate to the above class. Then simply implement this method and you’re notified when a user clicks a row:

Unlike in iOS, we’re not directly passed the table view object – but we can grab it from the notification. Note that the log message will be off by one because the rows start at 0 rather than 1.

Here’s a demo project with the above steps implemented: