Android: 2.33 is still alive

Google Android

According to the last statistics from Google, version 2.33 of Android, is still taking more then 20% of the overall Android market.

These are still bad news to us developers who are still tied up into all kind of backward compatibility libraries, as if the sheer amount of devices in the market is not bad enough…

Google claimed in the past that they will solve this problem, then again, they claimed that they are not evil

My guess? It will be a long time before we can put these version to bed. And the dream of google updating the old versions? not going to happen. Sometimes, not even on it’s on devices.

Updating android UI from a background thread / timer

Like many OSes the Android OS doesn’t like the UI thread to be interfered from the outside. Many times, you need to update the main UI content with a timer/thread data.

Here is how:

  1. Create a Handler object (Note – the object might leak in certain circumstances – you might want to make it a static one.) like so : Handler handler;
  2. overwrite the handleMessage with the function you want updating the UI. You can use the Message object to pass some variables (you can, of course, extend this class):

    handler=new Handler()
    public void handleMessage(Message msg)
  3. You then call the handler.sendEmptyMessage(0); or equivalent from your thread / timer (there are several options there).


Handler class and memory leaks:

Since the handler instance is holding a reference to its creating\using class (be it an activity or a service class) the class will not be garbage collected till the handler itself can be collected (which will happen only when its run out of messages to process) this might poses a leak where a certain service or activity are not collected since the handler still has a reference to it.

To bypass this you can declare a static handler with a weak reference. Or, you can call the Handler.removeMessages() (there are more methods like this) when your activity is paused.

Closing Android socket

Assume we have a Socket that is connected to a server. Usually, we will use a secondary thread to read from the socket in a blocking connection.

If the user want to terminate the connection, in Java, we can call socket.close(). But not in Android (well, we can, but it will do nothing). While the thread is still alive and waiting, close() will not be executed and the connection will remain active. So, what can be done?

One way is to terminate the thread. This is obviously not a very good way, and denied the thread from executing its final code correctly.

The second and the right one, is simply to call Socket.shutdownInput() method. This will create a disconnection for the waiting thread, the thread will die according to plan and your application will run just fine!

Main differences between Android and iOS development

If you want to develop, or hire a developer(ahhhm…) to develop mobile application, these are the two big choices. Other options are: Nokia Symbian, Windows mobile, the RIM blackberry and some other platform that are not used by the major public.

For the sake of this document, I’ll focus only on the first two, which are the dominant ones at the moment. I will go point by point, specifying the differences between these two.

Why developing an application?

Before reading more, do you even need an application? If what you want can be achieve with a web site, you might want to stick to that, and wave the application. If what you need is an information page, web page will do the trick, however, there are many reasons to build a custom application:

  1. Information control – if you have a lot of information on a site (Facebook, anyone?) most devices will have a hard time rendering heavy web content.
  2. Usefulness. if you want to use the phone additional capabilities.
  3. Speed – apps will run faster and performs better.
  4. User access -the user will access application more – that’s obvious.
  5. Special GUI features – This is one of the main reasons to have an app – you want to enable the users to interact in an easy, fun, and fast way.
  6. Real world applications that can not be done on a web page, and there are many examples of this – server controllers, diet calculators, camera viewers, security monitors and so on.
  7. Marketing value – it looks¬† much more professional to have your client downloads your application and have your icon on there desktop. many banks and internet provider do just that, even they can saddle for a web page. The application gives a certain “extra” touch.

If you answered yes to one of the above, you need an application.



Both iOS and Android have an open market where the users can select and install programs, either free or paid for. In both cases you must register in order to publish your application to the public. In both cases payed application will require extra setup. Company account will take longer to set up, in both. However, apple  setup usually takes longer, in both scenarios. You can have an already registered developer post your application for you (especially if this is a free one) however, it will appear under his account.


iPhone uses Objective C which is horrible (sorry, but it is true), crippled language, that in spite of what some people say is not really object oriented. However, you can add C++ code to apple project very easily, which xCode supports fully. However – the C++ code can not be used for apple library calls or OS calls, but you can create you own classes. Apple uses Xcode as development IDE, and, apple development can be done only on Apple computers (if not considering some third party tools). Apple have only one product, iPhone (not referring to the ipod) and if the iOS version is right, the application will run – as long as the iOS installed is higher or equal to the application requirement.

The Android on the other hand, uses Java which is 100% object oriented, uses eclipse as the IDE, that can be installed on any Major OS – Windows, Linux and Mac (yes, even Mac). However, Java is Java, and it does not output machine code, so it might take a longer to load since it does need second compiling. The Java platform was selected in order to support a wide range of phones, and it does.

giving these differences, Apple application might be more expensive to develop.


Both OS limit the permissions a developer can have, But in a very, very different way. on Apple, the iOS will enable you to access the internet, create a local private DB and files, get the GPS location (the user have to approve this) access to the contact list (user have to approve this), send (through the regular SMS UI) but not receive a text message and that’s about all. If you see application that can do more, it is running on a jail broken device, in which you can do whatever you want, but we are not referring to these. for most applications these limitation are OK, and they can execute well. on Android, you have to define permissions when writing the application. The user will see them when he or she installs the application and can decide then if he wants to install it or not. If the developer didn’t ask for a certain permission – he won’t be getting it later on. In Android, developer have to ask for permission to do almost anything, including accessing the internet. However, he can also get access to GPS data (same as iPhone) SMS data (not applicable on iPhone) Calls data (not applicable on iPhone), can start services at boot time (not applicable on iPhone) and change many system aspects (not applicable on iPhone). The beauty of it all – the user view all of these permissions at install time. if he doesn’t approve, he can wave installing this application. If he choose to install it, he agree to give that application the permissions it asked for, and he will not be bothered with them later on.


To deploy an apple iOS application, you must have an apple ID. You must code sign your application with apple and post it to the app store (there are some cases that you can distribute them yourself, but only for a small user group). In Android, you can send your application by mail, have it on a web site (many vendors do) without any contact with Google. to publish to Google market, you do need to have an account. The signing process however, is much simpler, as the signing up process.


On Apple, every application submitted to the app store is going through a ratification process, in which the application is reviewed be apple. The amount of time taking to do that varies, and only after the application was approved it will go to the store. This process is done for every application, and will be done repeatably for every update this application may have. On Android, the application will be submitted automatically. if the users won’t like it, they will just remove it…

Developing Android applications

First thing – get eclipse. Some people recommend the J2EE – I don’t. the regular java version works great for me. Eclipse doesn’t have an installer. That’s not a problem, just extract it where you can find it, say, c:\program files.

Next thing – you go to the android website and download the sdk.

Download the ADT Plugin

  1. Start Eclipse, then select Help > Install New Software.
  2. Click Add, in the top-right corner.
  3. In the Add Repository dialog that appears, enter “ADT Plugin” for the Name and the following URL for the Location:
  4. Click OK.
  5. mark all the options
  6. wait a very long time.

Next thing, you need to enable the ADT Plugin. to do that:

  1. Start eclipse
  2. Select Window > Preferences… to open the Preferences panel (Mac OS X: Eclipse > Preferences).
  3. Select Android from the left panel.
  4. For the SDK Location in the main panel, click Browse… and locate your downloaded SDK directory.
  5. Click Apply, then OK.

Note: there are a lot of stuff to download, in Gb! this will take a while.