Moving to Android from J2ME [closed]

Question

Coming from J2ME programming are there any similarities that would make it easy to adapt to Android API. Or is Android API completely different from the J2ME way of programming mobile apps.

Answer 1

Well, you may not actually need to adapt.

There is a good chance that a J2ME stack will become available for Android before long since Android is not supposed to become as restrictive of third-party runtimes as the iPhone.

I know one guy who has been working on just that: http://justanapplication.wordpress.com/

Now, of course, that doesn't mean you shouldn't have a look at the Android APIs and application lifecycle.

Answer 2

A good start would be to watch the Android architecture videos and look at some of the documentation.

http://www.youtube.com/view_play_list?p=586D322B5E2764CF http://code.google.com/android/what-is-android.html

Google is very good about documenting. From what I've heard Android very very similar to J2ME in its goals. It may be slightly different in programming style and structure but if you have J2ME experience you should be more then ready to move on to Android.

Good Luck!!!

Answer 3

Actually the Android API is much more powerful than the J2ME.

It is much easier to create an application for the Android.

Using the J2ME you are limited to simple forms due to the absent of swing-like libraries (though now there exists a library called LWUIT, avoiding the need to recreate from scratch a swing-like library).

In Android you will be able to create complex form very quickly, and software package for the android SDK is easy to install (while in J2ME you have to install the wireless development toolkit from sun, or install one of Nokia's, Samsung's or SonyEricsson's... it gets a bit confusing sometimes).

The things I had to change when switching from j2me to android were:

1/ The font and graphics class is easier to use on j2me. The API is more thorough on Android, but also more complicated.

2/ If you are used to the database storage of j2me (RecordStore), well you can forget it in Android. You will have to use a SQL-like databased, so be prepared to rethink your data model.

Answer 4

I've also found the path from Java ME to Android to be pretty simple. Here are a few things I've noticed:

1. There is ONE ui draw thread in Android. You have to be aware of the difference between calling postInvalidate and invalidate on Views to force them to update.

2. The actual bit-wise graphic manipulation is very similar. I was able to port large amounts of custom J2ME draw code by writing a few shims for drawRect and drawImage.

3. Android's UI library is much more extensive, much less useless, and much more complicated than Java ME's

4. Threadwise, you have to be much more careful about thread saftey with Android. In Java ME you can get away with not making methods synchronous or variables volatile most of the time. Not so in Android.

I will say, on the whole, that Android's UI library fails a critical test. I call this the "roll my own" test.

Your UI library fails this test if it takes me longer to complete a detailed task task (say, changing the background on one individual menu item) than it would take me two write my own Menu from scratch. Android fails the "roll your own" test by a factor of 3 or 4. In fact, if you look, the majority of the questions on this website are "How do I make the Android UI toolkit do my bidding?" questions.

Android is an amazing platform and it has been worth every frustrating moment I've sunk into it. It is, however, a young platform, and needs some serious work in times to come.