Mobile app development and the DRY principle

I want to ask: what do people think of applications that generate code for Android, iPhone and Blackberry applications? The sort of “write it once, run it everywhere” dream. I’m talking about things like Titanium, PhoneGap and Rhodes.

I’m particularly interested in hearing from people who have developed for at least one mobile platform. See, when i first came across PhoneGap i was extremely excited! I thought it was an extremely good idea: it conformed to the DRY – Don’t Repeat Yourself – principle, and meant you only had to learn one framework and suddenly you could build applications that could run on multiple devices.

Since then, i have had a little dip into Android development using Java, and i’ve spent a week intensively teaching myself iPhone development using Objective-C. I’m no longer at all convinced that these DRY frameworks are such a good idea.

I’m an Android user and i don’t really have much experience with iPhones, so learning iPhone development means also learning the standard ways in which people expect iPhone applications to behave. And i realise that they are quite different from the ways in which Android applications are expected to behave.

For example: application settings. The standard behaviour in Android applications is to press the Menu button and choose a Settings option. In iPhone applications you generally press a little icon which causes the view to flip over to another view containing Settings.

Another example: application feedback. An iPhone application often pops up an alert with an OK button, but Android applications pop up a little message towards the bottom of the screen which fades away after a second or two and does not prevent you from doing anything else whilst it’s there. Alternatively, a background task may put a message into the notifications bar at the top of the Android screen.

Android users are used to the ‘long press’ to get further options. I don’t think that concept even exists for iPhone. Button sizes and styles are different. Android has tab bars at the top, iPhone puts them at the bottom. Android uses the physical ‘Back’ button but iPhone needs a button in a task bar on the application screen. I could probably go on if i spent more time thinking about it.

The point is, Android and iPhone have different user bases with different expectations. How do you cater for both in one development environment without reducing both to something kinda clunky and not very satisfactory for either? I imagine the interface differences between Windows Mobile, Palm, Symbian and Blackberry are even more pronounced than those between Android and iPhone.

I should look into Rhodes, PhoneGap and Titanium and see how they deal with these very different paradigms. But right now i’m very interested in hearing from people with more experience. At the moment, if i wanted to write something for iPhone and Android i’m thinking i would probably go WET – Write Everything Twice. What’s your take on it?

Advertisements

4 comments on “Mobile app development and the DRY principle

  1. PhoneGap, Rhodes and Titanium face an uncertain future at the moment since the whole Apple/Adobe saga. Apple are much more in favour of native written apps (Objective-C and the iPhone SDK) rather then the frameworks which compile to iPhone binaries. I don’t think there is any resolution on this issue yet, and have heard reports of people having problems getting there apps in the AppStore (http://bit.ly/S61At).

    I would at this time write everything twice, which is a huge shame, but future-proof, rather then investing time in an app that you may never be able to deploy.

    Interesting blog post :)

  2. Pingback: Tweets that mention Mobile app development and the DRY principle « aimee daniells -- Topsy.com

  3. “Long press” and the menu button (without any UI indicating that the menu button is appropriate) are my 2 pet hates about the Android interface. I’ve often had to Google to find out how to do things, like setting a static IP.

    Surely life would be easier if the status bar indicated an icon when the menu button was wired up to some code?

    I really hope now that Google has hired Matias Duarte, they will start to improve things.

    For balance, notification are perfect on Android but horrid on the iPhone.

    In a perfect world, I’d be happy coding in Titanium and, when appropriate, branching the code or using a different screen layout depending on the OS to meet the user’s expectation – that’s how you write iPhone and iPad universal apps.

    In Titanium, the toolbar and back buttons work exactly how you expect on both platforms and I’d avoid any UI that didn’t have a visual indicator. Far easier than writing code twice or more.

    However, as we know Apple forbids using cross-platform development tools, so that path is potentially unwise. So I’m writing code twice, rather than writing more apps.

  4. Thanks Mike, your experiences and insights are hugely valuable. And thanks to you and Richard for both bringing up the thing about native written apps. I wasn’t sure what the deal is with that, so it’s useful to hear from people with more knowledge.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s