An Android app to send prayers to Jerusalem

I have just finished a two-week project building an Android app called @TheKotel – Prayers to Jerusalem.

Now, anyone who knows me even slightly might think this is a bit weird, and believe me, i had a long conversation with myself about it before deciding to take on the work. These are the reasons that i did.

  1. I think it’s a nice idea. Putting thoughts into words and feeling that you’ve offloaded them somewhere is sometimes all people need to feel better.
  2. I saw a video of Alon printing the prayers and cutting them up and taking them to the wall. It made a personal connection for me.
  3. There’s already a successful iPhone app with over 10,000 downloads, so i saw this is definitely something that people want, which is all good publicity for me.
  4. Alon raised money from the people who already use the iPhone app to pay for the development of the Android app.
  5. I saw it as an opportunity to learn a bit more about Android development, try out PhoneGap and Sencha Touch (which i dropped when i found i wasn’t happy with the quality).
  6. I had saved up enough money in the back that i could offer this more-or-less as a gift, not expecting much money for it but instead doing it for reputation and for another Android app in my portfolio.

The concept is very simple. You type your prayer on a piece of paper (or pray out loud with Android’s speech-to-text feature) and press “Amen” and the prayer gets sent to Alon in Israel.

Combined with all the prayers that get sent via twitter and the iPhone app, Alon prints out thousands at a time, cuts them into little slips, rolls them up tight and takes them to the Western-Wall, or The Kotel, the remains of the Second Temple in Jerusalem.

The app is free, and the service is totally free, but donations are gratefully accepted. There is also a Connect screen giving options to share the app with friends and feel connected to the Western-Wall and Jerusalem. We also included some background information about the Wall and how the service got started, as well as some personal messages from a few supporters who helped to raise funds.

Best of all, there’s the gallery where you can see where the prayers are going. I really like this image of Alon putting the prayers in the Wall.

I am very pleased with the final result. It’s nice and fast, good native Android experience, and i think people are going to love it! I enjoyed coming back to Android development, say what you want about Java, but i like it!

If you can bear to listen to me talk about this anymore, Alon asked me to record a video in my “enchanting” British accent, heheh! :)

Device graphics were generated with Device frame generator and released under CC BY 3.0 license.


Speak the phone’s language

I have long had a prejudice against tools that help you to write apps for mobile phones, especially the ones that claim you can write an app once and deploy it to multiple different platforms. My argument was that iPhone, Blackberry, Android, Windows Phone, etc, all have different user bases who expect different things. How can you write one app that works well across all platforms?

I recognised this as a prejudice, and realised that i hadn’t actually tried out the things that i was criticising. After watching a talk by coder, hacker and lecturer Syd Lawrence about PhoneGap and Sencha Touch, i realised that the time had come to test my assumptions.

Syd Lawrence – Mr Mobbles Magical Emporium from Event Handler on Vimeo.

An opportunity came along to develop an Android version of an app that already exists for iPhone. It’s quite a simple app, and on Monday last week i made a start.

I downloaded PhoneGap and installed the library into a new Android application. It provides you a very fast way to get up and running with an HTML5 app that runs locally on the phone. There are numerous javascript functions which translate into the phone’s native language to access things like the camera, GPS, accelerometer. You can also write native code and expose it to your javascript, for example i wrote a little bit of Java code to hide the soft keyboard, which i could call from javascript at the appropriate time.

To style the app, i used Sencha Touch which is an extension of Ext.js. It’s a very nice way of declaring components in javascript that look visually somewhat like a native app. I got the basic functionality together quite quickly: tabs, network connectivity with JSONP, a scrolling gallery of pictures.

It was nice to use tools i am familiar with: jQuery and CSS3. You can run your app in a browser as you are building it, and periodically just check it looks okay on a phone.

Progress was fast. I encountered a few obstacles, most notably cross-site-scripting limitations, and limitations of the pre-release Sencha Touch version 2 which meant i had to go back to the slower and older 1.1. But i managed to overcome every obstacle and within 4 days i had a basic functioning app.

All was great apart from one thing: performance. On my Android tablet the app took 3 seconds to load. On my entry-level phone it took 7 seconds initialising PhoneGap, Sencha Touch and jQuery. Just to load a page that does basically nothing until you start typing in it. I was also disappointed by the refresh when you rotate the phone’s orientation and it jerkily redraws the screen. It’s great as a proof-of-concept prototype, but it’s not something i’d be happy to release and put my name to it.

So on Friday i thought to myself, you know what? I’m going to see what it would take to rewrite this as a native Android app in Java. I spent a good deal of the weekend working on it and by Monday i had got it to approximately the same point as the PhoneGap/Sencha Touch version. I gave my client the option which to continue with, and together we chose to go ahead with the native app. We lost the ability to deploy to multiple platforms, which was something we were hoping for, but in return, we get a far more responsive, native look and feel high quality app that we can both be proud of.

There is a place for Sencha Touch: if i’m writing a mobile friendly version of a website i’ll definitely give it another try. But for an app that has been downloaded and installed, i feel that the users are justified in expecting something better. And to achieve the quality expected, at least for Android, you have to speak to the phone it its native language.

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?