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.

Buffer 2.0.1 for Android

Thanks to everyone who gave feedback about the Buffer for Android new release two days ago. We were very happy to receive so much positive feedback.

I know that we had a couple of problems. The two that stood out the most were the time zone issues (already fixed) and the shortening of URLs.

I am happy to say that URL shortening is coming in the very next release. 2.0.1 should be coming to the marketplace within the next 12 hours.

Update: Buffer 2.0.1 is now available! :)

Here’s a sneak preview for you; URL shortening comes at around 0:40.

In addition, we’ve paid some attention to the styling, going back to standard Android styles in many cases rather than trying to override it with green, which didn’t really work too well. Tom has also come up trumps with some new icons for us!

Here’s a comparison between 2.0 and 2.0.1 – i think it’s starting to look really stylish now!

Update: Buffer 2.0.1 is now available! :)

New Buffer for Android – a couple of tips

I have spent the last 5 weeks working on the all-new Buffer for Android. I’ve learnt a lot about Android and Java, and it has been great fun. I am really happy with version 2.0. It was very exciting to release it to the world last night.

We’ve had a lot of feedback, most of it very positive, thank you to everyone who has tried it and given feedback. There are a few things that i want to mention here.

Time zone issues

At the moment, the API is reporting the time in GMT rather than your local time. This is a mistake from us, and we should have caught that, so sorry about that. I am sure Joel or Tom can get it fixed very soon, and you won’t need to update the Android app, it will just start working for you automatically.

Rest assured that your updates will still be sent according to your schedule, whether you add them through the Android app or through the web. The web will show the correct times for you.

Update: Tom has since fixed this issue! :)

No default profile selected

It is possible that you might have no profile selected. You’ll get the message “Please select at least one profile to post from”. I realise this could be annoying. I will make a fix so that if you only have one profile, that one will get selected automatically.

Update: This is fixed in version 2.0.1 which is now available. I’ll keep the following workaround here because it might still be useful.

In the meantime there is a workaround you can use. Go to your Buffer profile settings and click “add default”.

Having done that, go into Buffer on your phone, use the menu to choose Sign out and then sign in again. From now on it will select your profile by default.

Refresh interval

To speed things up on your phone, i have added some caching so that it doesn’t continually have to connect to the internet. The cache lasts for 2 hours, or until you add or edit updates from your phone, at which point it fetches again from the Buffer API.

If you add or reorder updates from another device, or in the web app, they might not necessarily be shown in your Android app, due to this caching. You can always force a refresh by choosing the Refresh option from the menu.

Short URLs

We are currently not providing an option to shorten URLs within the Android app. We plan to add this in a future release but right now you might see that a long URL means you haven’t enough characters to write everything you want to say.

As a workaround, if you add the update to your Buffer, you’ll find that it does shorten the URL for you. You can then go into the app and edit the update to add your comment. (A long-press on the update will give you the option to edit, copy text or delete.)

Update: Dan Monzelowsky suggests sharing first to an app called Abbrevator! to get a short link, and then sharing from there to Buffer.

Update 2: Version 2.0.1 now shortens URLs for you and it’s available in the marketplace now! :)

Anything else?

If you have any other questions, feel free to ask. We’re eager for feedback and suggestions so don’t hesitate. If you have any other tricks/workarounds for using version 2.0 please share them too! :)

Exposing my ignorance

I have been encouraging my apprentice Rohit to blog about ignorance. It’s great to talk about what you know, and what you can do well, but for people to really trust you it’s important also to be honest about what you don’t know yet, and what you’re looking to learn.

As software crafters learning is part of what we do. There is always more to learn; it never stops. Personally i really enjoy learning. I love the feeling of new information going in and being absorbed.

Since i asked Ro to blog about exposing ignorance, i thought i should do the same. It’s good to start with a review of where you are now.

Where i am now

It’s fair to say my strongest language is Ruby. I’ve been programming in Ruby for about 5 years, i’ve seen my style grow and change a lot. I feel very confident in domain modelling and object orientation using Ruby.

I’m pretty confident with behaviour driven development for Ruby, using Cucumber and Rspec. I know a lot about Rails and a fair amount about Sinatra. I am comfortable using MySQL, PostgreSQL and MongoDB.

Exposing my ignorance

My biggest weakness at the moment is in having only one strong language. And here is where i expose my ignorance. I know a bit about a few other languages, but i’m not where i want to be. I feel embarrassed when people talk about Java, Haskell, Scala, Io, and i am unable to contribute due to my lack of knowledge.

Confronting my ignorance

Since thinking about this blog post, i have already begun confronting my ignorance: my first step was to contact Joel Gascoigne who develops Buffer – a simple tool for scheduling tweets. I wanted an easier way to use Buffer on my phone, so i offered to make an Android app. I saw this as a pet project to get me learning a bit more about Android development in Java.

The app is open source; you can check it out on A simple working version is now available in the Android Market: Buffer for Android.

We have a few ideas for moving the app forward, but for now i’m happy that we’ve got something out there that works, and it has given me the confidence to develop more Android apps.

My next tactic will be to study the book Seven Languages in Seven Weeks: A pragmatic guide to learning programming languages, by Bruce A. Tate. This is an intensive study of Ruby, Io, Prolog, Scala, Erlang, Clojure and Haskell. By learning how to solve a non-trivial problem in each of these languages, we learn the unique strengths and weaknesses of each language.

I’m looking for other people to study along with me, so if you’re interested, let me know!

Once i’ve studied those seven languages, i want to learn some Python. I’ve been hearing a lot about Python lately, and it seems like a language i really want to know. I already have the book Learning Python by Mark Lutz and i look forward to getting to that.

So that’s me: i have listed my strengths, exposed my ignorance and outlined how i am confronting it to improve myself and learn more. What about you?

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?