As my project to migrate EP Mobile from Android to iOS progresses, there might be some of you who are interested in some of the obstacles that I have had to deal with. These obstacles are numerous and non-trivial. The programming languages (Java vs Objective-C) are completely different. The programming IDEs (Eclipse vs Xcode) are also very different. In this post though I’d like to concentrate on differences in the user interfaces of the two systems.
While superfically similar, Android and iOS approach user interface design very differently. Android uses XML files that layout all the user elements (check boxes, labels, text boxes, buttons) in text. Although there are some rather primitive WYSIWYG tools to design your user interface, I have found these to be relatively useless. Almost all the design is done by editing the XML files. iOS on the other hand has a very robust gui-based design editor in Xcode which makes it very easy to layout your user elements visually. There may be underlying XML files used to achieve this, but the programmer never needs to edit these directly. Score one for Xcode and iOS!
Unfortunately, beyond the design tools, there are a number of negatives and limitations in the iOS user interface widgets. Instead of drop down lists that take very little space, there is a huge Picker element that looks like part of a slot machine. There are no radio buttons! In there place are segmented controls and other workarounds. But why, Apple, why no radio buttons?
To illustrate some of the issues in porting the user interface, I’ll use the Cycle Length Calculator module of EP Mobile. It was the first module I designed when I started working on the program, and it is the simplest module. The user inputs a cycle length or heart rate, and the calculator converts it to the opposite units. The calculation itself is trivial and is the same for cycle length and heart rate: just divide into 60,000. Only the units change. Here is the Android version:
Admittedly it is not the most beautiful user interface, but it does the job. The user selects whether he or she is entering a cycle length or heart rate, clicks the Calculate button, and the result appears. The code behind this is very simple, just having to look out for illegal inputs (like text or zero). The radio buttons are used to toggle between cycle length and heart rate. I like how the program icon and the title of the module appear at the top. The Android keyboard appears automatically when you touch the text field and and disappears when you are done automatically. You use the back button on your phone to get back to the EP Mobile main menu.
Here is the iOS version of the same module. There are several differences and I have to admit it does look a little prettier. First off, I changed the title of the module to CL/HR Converter. This may seem like a better title anyway, but the real reason I changed it was that, with the big back button at the left of the title bar and the large default font, I had to make the title shorter to fit. I have had to do that with a lot of the module titles. Accordingly there are a lot more abbreviations in the module titles, but I’m sure most EP types will figure them out. Next, instead of the radio buttons there is what Apple calls a “segmented control” to select between CL and HR. This looks nice, but takes up a lot of space. There is no way to make it vertical, so again cycle length and heart rate are abbreviated, and, most importantly, once you get beyond 2 options, you really can’t use this in lieu of radio buttons. Otherwise the buttons and text boxes look good. Somewhat amazing to me is that fact that, while as in Android the on-screen keyboard appears when you touch the text field, you actually have to use programming code to make it disappear! This is an example of the frustrating combination of polish and rough edges that is the iOS programming experience at present.
Pushing the back button at the top gets you to the EP Mobile main menu:
If you are familiar with the Android version, the ability to group lists allows me to take away one layer of menus, at the expense of a longer list of modules on the main menu. In general I am trying to take advantage of the different user elements available on iOS vs Android rather than hammer a square peg into a round hole. The conversion is coming along. I hope the iOS version of EP Mobile will be available on the iTunes App Store soon.