Universal Links – A Few Things to be Prepared for

I recently had the opportunity to work for a client who wanted to develop what they termed “app indexing”. What they meant by this was that they wanted their users to be directed into a specific screen of their iPhone app when they tapped on a particular Google search result. Put differently, they wanted the user to feel as if Google had returned search results specifically for their iPhone app.

They also wanted to be able to send out links via email, SMS or other marketing channels. If the app was installed, opening such a link on their phone would result in the user being taken to the relevant points in the iPhone app. If the app wasn’t installed then they would just be taken to the mobile website.

The way this is achieved is through what Apple refer to as “Universal Links”. In this post I’m going to discuss how we implemented Universal Links at a client of ours, some of the obstacles we faced, and how we overcame those obstacles.

Will Swift be the next king of server side development?

Swift throne

In June 2015, Apple announced at WWDC that they were open-sourcing the Swift language and its runtime libraries. On December 3rd that year they made good on their promise. In this post I’d like to talk about why this is significant, particularly for server-side developers.

iOS Developers and Designers: Stickin’ together is what good waffles do!

We’ve all heard developers say it: “I’m a terrible drawer” or “I’ve got no design skills”. Perhaps we’re even guilty of saying it ourselves – I know I am. But after attending this year’s Swipe Conference I now subscribe to the opinion that this is no longer acceptable. We are all responsible for the design of the app we are building; developer, designer, tester, or producer: every member of the team is accountable for helping shape the app’s design and interactions.

New iOS Developers Shouldn’t Use Interface Builder

When I first started learning Objective-C and the iOS SDK 2.x a few years ago, one thing that I constantly struggled to get my head around was Interface Builder.  More specifically, why should I use it and how it could possibly benefit my iOS development – given that I could code a UI programmatically, and know exactly how it all worked? A colleague of mine even wrote a blog entry that mirrored my exact feelings towards Interface Builder back then.

Well over the past 6-12 months my attitude towards Interface Builder has changed. There are two reasons for this. Firstly, it’s now nicely integrated into XCode 4. Prior to that, who wanted to have 2 different apps running (XCode and Interface Builder) with popup windows spamming your desktop? That was a deal-breaker for me. Secondly, I’m now a more experienced developer. After using Interface Builder on a couple of projects, I am confident to say I am now more efficient as a developer when using Interface Builder. However, that wasn’t always the case, which leads me to my key message here:

If you’re new to iOS development, don’t touch Interface Builder until you are capable of building UIs programatically.

Continuous Deployment of iOS Apps with Jenkins and TestFlight

I thought it was about time I should put together a simple guide on using Jenkins to build your iOS application – and for those of us that use the awesome testflightapp.com website for managing our iOS app distribution for testing, I have included details on creating a Jenkins job to publish the latest successful artifact to testflightapp.com.

How to bridge Ruby and AppleScript

Not that long ago I gave a demo in which I showed how it was possible to control iTunes from my laptop using native Ruby code.

This was all possible because of a great little gem called rb-appscript.

rb-appscript is a really neat Ruby to AppleScript bridge that gives you the power to effortlessly control any AppleScript aware applications from within your very own Ruby applications.

Launching iTunes and the DVD Player via irb

Assuming you have already installed the rb-appscript gem open up a Terminal shell and lauch irb. What we are going to do is in a few lines of code open up iTunes from ruby.
>> require 'appscript'
=> true (notice above we don't need to prefix the gem with rb-)
>> it = Appscript.app('iTunes')
>> it.run

Now how easy was that! iTunes just started up as soon as we ran it.run. Obviously if you already had iTunes running you would be disappointed because nothing would have happened.
You can use the above code for any application you could easily have just done
>> Appscript.app('Dvd Player').run
If you wanted to launch the dvd player.

Let’s tell iTunes what track we want to play

In the following example I am going to show you how you can retrieve a list of tracks from your Music library and tell iTunes to play our selection.
>> require 'appscript'
=> true (notice above we dont need to prefix the gem with rb-)
>> it = Appscript.app('iTunes')
>> it.run

Print out our tracks we have available to us
>> track_count = 0
>> it.playlists["Music"].tracks.get.each do | track |
?> puts "#{track_count += 1}. #{track.artist.get} - #{track.name.get}"
>> end

Ok play the 3rd track
Magic happens the song starts playing!

Script Editor + ASTranslate is your friend

Now the examples I have given you are very basic however if you want to do more then you should launch Script Editor and load the application dictionary that gives you access to all commands and properties you can change for that application.

ASTranslate is a great developer tool that allows you to write normal AppleScript commands and it will attempt to translate this into the rb-appscript equivalent!  So if you come across any cool AppleScripts out there you may be lucky and be able to translate them into ruby code!

I was amazed at how easy it was for me to command iTunes to do what I wanted it to do all from within my ruby application.

Useful references


Run-loops vs. Threads in Cocoa

As a relative newby to the world of Cocoa programming (on the iPhone in particular), I have spent some time trying to understand if and when you’d use a run-loop instead of launching a separate thread. I was unable to find any definitive answer on the web, so ended up joining the dots myself. What follows is my understanding of when you’d want to use one or the other. Cocoa experts are welcome to comment if I’ve got it wrong.

The Problem

Touches aren’t the only source of input to an iPhone application. For example, another source can be a socket – sometime you want to listen to a socket for data. But you don’t want the UI to lock up whilst it’s listening – you still want input from the user to be dealt with promptly. Similarly, you might want events to be triggered automatically at certain time intervals, but without locking up the application in the interim.

Coming from other UI frameworks, you might think that the way to deal with this is to to use a separate thread. That way, the thread can block on the socket or sleep for a particular time interval. However, as we all know, the introduction of multiple threads immediately introduces a bunch of potential defects that are difficult to reproduce and fix.

The Solution

Enter run loops. Or more specifically, the run loop – each iPhone application has one by default and for our purposes, this is all we need.

So what exactly is a run loop?

Well, first consider this assertion:the vast majority of the time that your Cocoa application is running, it’s doing nothing. More specifically, it’s waiting for input. However, as soon as you touch the screen, an event gets triggered, which may in turn result in some of your code being executed. If some data comes into a socket, or a timer fires, the same applies.

The key things is that once this code has been executed, the application goes back to waiting for input. Furthermore, in many cases the execution time of your code will be very small relative to the time the application spends waiting for input.

I think of run loops as a mechanism that exploits this fact.

A run loop is essentially an event-processing loop running on a single thread. You register potential input sources on it, pointing it to the code that it should execute whenever input is available on those sources.

Then when input comes into a particular source, the run loop will execute the appropriate code, then go back to waiting for input to come in again to any of it’s registered sources. If input comes into a registered source whilst the run-loop is executing another piece of code, it’ll finish executing the code before it handles the new input.

The upside of this is that whilst you mightn’t know exactly what order things are going to come in, at least you know that they’ll be processed one after the other instead of in parallel. This means that you avoid all of those nasty multi-threading issues that were described earlier. And that’s why run loops are useful.

Run loop scheduling in action

By default, all touch events received by an iPhone application are queued for processing by the application’s main run loop, so there’s nothing special you need to do for UI components. However, other sources of input require additional coding.

To schedule an NSInputStream on a run loop, you’d do something like this:

[iStream setDelegate:self];
[iStream scheduleInRunLoop:[NSRunLoop currentRunLoop]

This code sets it up so that whenever input is available on ‘iStream’, a ‘stream:handleEvent’ message will be sent to ‘self’. Note that the stream could be from any sort of source, including a socket.

Another object that can be scheduled on a run loop is a timer. For example:

[NSTimer scheduledTimerWithTimeInterval:2.0
userInfo: nil

will schedule a timer on the current run loop to send a ‘doStuff’ message to ‘self’ every two seconds.

When not to use a run loop

So when wouldn’t you use a run loop? Well, if you had some event-handling code that was going to take a long time to execute (for example, performing some CPU-intensive calculation), then everything else in the event-handling queue won’t get handled until it’s finished. This would cause your application to become unresponsive until the processing has finished. In that sort of scenario, you might want to consider using a separate thread to do the processing.

However, for the vast majority of cases, our code for handling events – be they from the screen, sockets or timers – takes a very short time to execute. And that’s why it’s easier (and safer) to just use the main run loop to handle those events.

The trade-offs

The only downside to using a run loop instead of a thread is that instead of just whacking a thread around a whole section of code that you know will block in one or more places, you have to go to each potential blocking point, register the source on the run loop, and implement a callback to process events that are generated from that source.

Whilst this may seem like some effort, it pales in comparison to the pain that can result from poorly-considered threading. So next time you’re tempted to use a thread to read from a blocking input source, consider taking the time to use a run loop. It could well save you a lot of time in the long run.

Tiger + Rails + Leopard = Ouch

Leopard and Rails

After having gone through the pain of installing Ruby on Rails on my MacBook Pro running Tiger (OS X 10.4) I was pleased to see that Leopard (OS X 10.5) ships with Rails ‘pre-installed’ and ready to go.

So, after I upgraded my installation on Friday night I was perplexed when trying to run my Rails apps. Why was it broken?

In the end, it turns out there were several problems.