UIImagePickerController has plenty of issues. One of the first to be widely discussed was its memory leak which shows itself when you try to access the PhotoLibrary on the simulator. Fortunately, this leak is limited to the Simulator and does not show up on Device.

There is, however, another more serious problem with the image picker on device [1], which shows up when repeatedly capturing images from the camera. If your application uses the camera, you have a choice. You can either hold open an instance of UIImagePickerController all the time, or you can release the controller when you are done using it, and instantiate it next time you want to use it. Surely the latter is better - you should only hold resources open when you need them.

Fig 1. Memory trace of repeated image captures on device

Figure 1, above, shows the problem with that approach when we moved to the device. We experienced frequent crashes in an application that involved many image captures. We eventually narrowed the problem down to repeatedly capturing images, where the application released the UIImagePickerController after every capture. After 7 or 8 (never more) image captures, the application would either exit, or crash. The trace above shows the memory allocation spiking up during every image capture - and never dropping back down after the 7th image capture. The activity spinner froze, and the device locked up requiring a reset. The freeze occurred inside the UIImagePickerController code, not in application code. We also noted a memory leak from core code that was detected between the 3rd and 4th image capture, which is shown in the trace above

Having identified a means of reliably reproducing the crash [2], and noting that it was occurring within Apple code, not our own, we tried holding open a UIImagePickerController for the lifetime of the application. We have not since experienced a crash. Airsource therefore recommends that developers using UIImagePickerController use a singleton instance over the life of the application [3] rather than creating on demand and then releasing.

[1] All tests run on an iPhone 2G 8GB running OS 2.1
[2] We validated the test by running it against a 3rd party application called Phanfare which is also dedicated to image capture. We were able to reliably cause Phanfare to crash, by taking a photo, selecting Use Photo, selecting Cancel, and then repeating.
[3] Airsource only ran the test in camera capture mode. According to a post at iPhoneDevSDK.com, the same crash can be experienced in PhotoLibrary mode, albeit with a higher threshold number of image captures.

The standard image capture in API in the iPhone SDK is the UIImagePickerController. There is much discussion on the web about how this can be customized via subclassing, both from the viewpoint of technical feasibility, and from the viewpoint of being allowed onto the AppStore. It is generally accepted that going direct to private frameworks is unacceptable, even though this arguably can give a better user experienced. Phanfare had their app pulled from their AppStore for using the PhotoLibrary private framework, and returned with a new version that instead customizes the UIImagePickerController experience.

I took an in-depth look at the view structure that the standard UIImagePickerController creates. The first is obtained by looking at self.view and is not particularly interesting. It consists of a UITransitionController and a UINavigationController and is clearly the meta-system for switching between the capture and preview screens.

The second view hierarchy is created by PLCameraController, and can be obtained by implementing willShowViewController in the UINavigationControllerDelegate. The first callback to this comes when UIImagePickerController wants to display a PLCameraController. The view hierarchy is much more interesting:

Several of these classes are undocumented, but that doesn’t prevent us from manipulating them with standard APIs. Experimentation showed that the UIImageView highlighted in red is the important one - it’s the camera preview pane. You can remove every other view, and just retain this one, and you will get a full-screen camera view. You can also move the TPPushButton (which represents the cancel button) out of the hierarchy and place it elsewhere on the screen. Doing the same with the TPCameraPushButton causes a crash when you activate the button, because the PLCameraController tries to modify the buttons, and fails because the view structure has changed.

You can also add further views (as Phanfare did) to overlay extra details. Clearly there is yet more scope for customizing other aspects of the hierarchy - this requires more experimentation, and we’ll report on this as we learn more.

The subtitle for this article should probably be “Why the iPhone is Swallowable”. I’m here at the Software Development Best Practices expo in Boston. Joel Spolsky introduced us all, just a moment ago, to a new concept in design - how swallowable a device is. Admittedly he applied this to the notion of an iPod - and the new series of Macbooks - which having no seams look like they should be easily swallowable, but a design principle should be applicable across the board, right?

On a more serious note, Joel discussed a couple of interesting theories about how to make a great product, be it software or anything else. He started by talking about Control/Helplessness with obvious applicability to the Microsoft/Apple products, followed by a long section on Aesthetics. His point was that while there may be no sensible business rationale to creating an entire new manufacturing process for the Macbook just to lose a seam or two, we don’t let software engineers do design. Engineers think that artists can just paint over all their ugliness, whereas in reality the engineering decisions need to be shaped and guided by the overall design vision.

The second theory was about designing with a Culture Code viewpoint. SUVs are perceived as safe, despite the converse beng true, because they are soft (off-road suspension), with big armchairs inside instead of racing Recaro seats, and because the seating position is high up. Finally, and this was the crucial point, they have plenty of cupholders, allowing the driver to get a warm milky drink in a soft comfortable environment - in other words (according to Joel), selling the driver on a breast-feeding type experience. And, of course, breast-feeding equals a safe, comfortable environment.

I am now waiting for the first iPod-clone manufacturer to misunderstand the message and produce an something shaped like a breast.

Yesterday at CTIA Wireless IT and Entertaiment Yahoo! announced their contribution to the mobile platform wars in the form of an XML-based language named BluePrint. BluePrint allows the generation of mobile applications for Windows Mobile and S60, as well as widgets that run inside the Yahoo! Go environment. Yahoo! has provided us an overview here.

The quest for “write once, run anywhere” continues. Unfortunately, after many years of bitter experience working in the mobile space, I have come to realise that the goal of a single environment that will give you a good quality application experience on all platforms is doomed to failure. Every mobile device has its fair share of idiosyncracies and unique advantages and features. A “cross-platform” toolkit like BluePrint is unfortunately doomed to deliver you a mobile experience that, although workable, is going to be too slow, too bloated, too limiting and too disconnected from the device it is running on. If you really want to produce a great mobile application you need to develop it with an appreciation for the underlying platform and not just opt for the lowest common denominator.

My current favourite example is the iPhone/iTouch development environment. Apple has put the brakes on Flash content and Java content, not because they want to spoil Adobe and Sun’s party, but because they know that the only way they will encourage the development of great quality applications is by forcing developers to appreciate the API and the platform they have assembled. Allowing cross-platform content on would result in a very bland and dysfunctional collection of applications. Pushing developers into Objective-C and the Touch environment forces them to rethink their application approaches rather than just cranking the handle on the last Java app they wrote.

We will run BluePrint through the wringer in due course; before we even embark on that particular expedition, though, I feel I know what is coming.

I’ve recently been playing with Wordpress for the iPod Touch and iPhone. It’s a very simple application which allows you to write posts while you’re on the go, and post them to your blog over whichever network connection is most convenient.

My impressions so far are that it seems to work pretty much as advertised. You can review blog posts written by others, change their status or edit them, and add new posts. You can even attach photos that may be on your device - although there isn’t really any way to take photos from the touch, so iPhone users will be the only ones to really benefit.

Overall - very simple and does what it says on the tin. It doesn’t solve your bad iPod typing (if you have fat fingers like me you might be struggling to write longer posts without them reading like Klingon) but it does give you another way of getting your musings up on a blog from your cafe of choice.

Overall, I’d give it 3/5.

SSH is undoubtedly a useful tool and the iPhone and iPod Touch are great portable ways of connecting to networks; put both together you can be a sysadmin on the move! So what are the options for this? The Apple AppStore has a few SSH clients, I decided to take three - SSH, iSSH and TouchTerm - out for a spin.

SSH

First up is SSH, marketing at $3.99 (£2.39). Opening the program greets you with a screen where you can type in an address to connect to in the form user@hostname:port (the address is added to a list on the first screen so you don’t have to type it next time). Once this has been entered you’re presented with a password entry screen, although you have to press the password entry box to get a keyboard.

If this is successful you get a retro green monospace on black terminal, with a white command line bar at its bottom. This white command line is the only way you can send commands over ssh, you press it to bring up a keyboard with which you type your command and press ‘Send’. This command is then echoed to the terminal and executed. Basic shell commands work well, but once you want to use
some basic programs such as less, more or man problems start to show.

Navigation is the main problem with these programs through this client, I’m used to using the arrow and return keys to navigate them (I know there are other ways, but these are the ones I remember). The client has no emulation of arrow keys, so we lose that form of navigation and there is no return key on the keyboard. After looking up some of the other navigation commands available for these programs I was able to navigate them quite successfully, but the process of touch command bar->type command->send for every bit of navigation felt very tedious.

Another basic command I tried and expected to work was top, but alas SSH fails again and produced this output:

which is hardly usable. You can try and scroll the output, using screen swipes, but each time top refreshes your scrolling is lost.

As arrow keys are not implemented command line history is harder, meaning you have to type in commands to access your history, which is annoying and slow if you are using SSH’s input method.

The client allows you to use control commands using the ^ key, so Ctrl-C becomes ^c. This works and is functional, but to reach the ^ key you have to go through two keyboards, which is annoying. Why can’t there be a Ctrl button on the screen ready for me to use whichever keyboard I’m in?

iSSH

Disappointed with SSH I went on to try iSSH (marketing at $4.99 or £2.99). When you start it up for the first time you must add a connection configuration. This is a form where you fill in a name for the configuration, the hostname and at your choice a username and command to execute on connection.

With a configuration now saved I could choose to connect to it. This dropped me into a terminal where ssh asked me for a password, the bottom half of the screen is filled with a keyboard which types directly into the console. The terminal used is much better than the one SSH used, it has a gray monospace font on a black background, and it supports colours which makes using such a small screen more bearable.

There is a bar above the terminal which contains buttons for the Ctrl, Alt, Esc, Tab, F# and Shift keys (which can be used in combination), along with a keyboard toggle and exit. This allows you to use niceties such as tab complete on the command line, a great time saver when using the iPhone’s user input. Being able to toggle the keyboard is rather useful if you wish to read a file using less; you can invoke less then hide the keyboard giving the whole screen to the file which you can navigate using the emulated arrow keys.

Seeing that SSH had been so abysmal when I tried to run top I tried to run top on iSSH, which produced this result:

Hurrah! top is usable using iSSH. Running more, less and man was also successful using iSSH, which gives access to arrow keys through swiping the left 2/3 of the screen, and the keyboard has a return key (the right 1/3 of the screen is reserved for scrolling). This means you can also use the arrow key
emulation to scroll the command line history.

Tilting the device the appropriate way will change the display from portrait to landscape, which is a neat feature, especially useful if you’re reading files as you have width in the screen.

Multiple sessions are supported by iSSH, after you’ve hit the exit button your session doesn’t disconnect, you’re dropped into a list of open sessions, from which you can choose which session to see on the screen or you can go back to the main opening screen to connect to a new session. Within your sessions you can swipe horizontally to move to different sessions, like one does on the iPhone’s main menu screen; this usually works well but sometimes it gets tangled up with scrolling swipes which ends up with you in the wrong session and scrolled up too far.

TouchTerm

TouchTerm is the cheapest of this bunch at $2.99 (£1.79), and is based OpenSSH and OpenSSL. The opening screen allows you to connect to servers and manage your connections. You can connect as a ‘One-Time Connection’ or you can save a connection profile for future use (these profiles can also be edited in the future if you want).

There is a settings page which allows you to configure how text is entered, the display and security. One of the choices under text entry is whether or not to enter code directly into the terminal, if you choose not to all the text you enter goes into a text box before it’s echoed to the terminal. There are numerous display settings, among which are colours for the cursor, foreground and background, as well as the font size. For security you can set options for how keys are kept and whether or not to save passwords.

Once you’ve chosen a connection to make and you’ve connected with the server you are presented with a white text entry box where you enter your password, below which is the standard terminal foo@bar.com's password: prompt. The password letters are echoed for a few seconds in the textbox before turning into a *, helping you know if you’ve mistyped on the onscreen keyboard.

Above the terminal is a bar with some extra buttons, ‘Clear’, ‘Ctrl’, ‘Tab’ ‘Esc’, a button for starting arrow key emulation and one to go to the settings page. The arrow key emulation is rather neat, it overlays four translucent arrow keys above the terminal, which makes things such as accessing command line history navigation rather nice.

The terminal emulator used doesn’t seem to support terminal colours, so running e.g. ls --color doesn’t work, even though you can set colours for the foreground and background, rather annoying.

Running standard programs using TouchTerm is successful although it does feel a bit sluggish. top for instance displays quite well, but when interacting with TouchTerm’s controls there is a delay between pressing/swiping/whatever and the action taking place. Running less works, however there’s a second or two delay for the cursor to jump to the bottom of the screen after you’ve navigated, which makes the experience feel clunky.

TouchTerm can be used in both portrait and landscape modes and the keyboard can be hidden/unhidden by just tapping a couple of times on the emulated terminal. Scrolling is done with swipes of the screen, but this allows you to scroll off the edge of the terminal emulator giving you an ugly gray background, however once you’ve released your swipe the terminal will reposition so that it’s edges and the screen’s edges match.

Conclusion

Comparison chart of the clients:

In terms of functionality iSSH and TouchTerm beat SSH hands down. Depending on what the user is looking for in their ssh client will decide on if they prefer iSSH or TouchTerm. The former has the feature of multiple sessions and supports terminal colours properly, while the latter seems slightly more user friendly with the font size configuration and profile editing. Both make ssh usable on the iPhone.

UPDATE
Added review of TouchTerm and updated the review of
iSSH to cover version 1.1 (from 1.0).