Tag Archives: j2me

Know all about your app: Flurry analytics

Flurry, an early developer of mobile mail client for J2me seems to be reborn as a great analytic tools. This tool is available for four platforms: J2ME, iPhone, Android and Blackberry.

I’ve tested the J2me and iPhone version, and it’s one of the best tool I’ve found so far. Before, I’ve used “mobileZoo” from Stephane, and do the job, but started to be slow.

Flurry follow the same principle: you get stats about your users, their mobile, where do they come from, but give you much more details:

  • session length,
  • http usage (number of requests, time spent/request, data downloaded and received)…
  • number of canvas displayed
  • etc…

One of the coolest feature, is the notion of “events”. You can track events within your app (with a maximum of 100 events).
In J2ME, adding events is dead simple: whe you upload your jar file, flurry introspect it and you can select which procedure you want to track. If your binary is obfuscated, you can send the mapping file generated by the obfuscator. And then, by miracle, all calls to a specfific function are send back to the server.

Here is an exemple of two events that I’ve added in the 8Motions app:

Want to know if this feature is used or not in your app? Want to know the user path within it, want to track error generated…All of this is possible quite easily.

What is missing: the good thing for J2ME is it’s not a library, but it’s also a bad thing. I can not regenerate a new binary without manual interaction with Flurry. I would like to see a lib, like the iPhone version, that could be embeeded n my J2me app during the build process. Also, this could be used to add more details to event reporting, like additional parameters (this s what is done in iPhone version).

But it’s a very good product, and I strongly recomment any serious developper to check Flurry !

What future for J2ME?

Waow, what a big year, with several new platforms (Androïd, iPhone, JavaFX) , the move of Symbian to OpenSource?

Everybody these days is talking only of OpenOS (which in fact are not so open, but anyway) and the reborn of mobile applications.

So what happens to j2me, which is still the most important technology to deploy applications onhundreds of millions of handsets

The good thing, thanks to the push of these OpenOS is that application are now seen as a viable alternative to browser only, and a viable revenue stream.

But J2me seems to be out of the race. Why:

  • Where’s the AppStore? Still none of the MIDP2 handset have a good equivalent of the AppStore, an easy to use discovery and download mechanism. And even worst, once downloaded, the application are usually hidden in one of the numerous sub menus of the phone. And there is NO WAY to create your own AppStore in J2me using standard API.

  • MIDP3 is too late: MIDP3 phones, which should have been an answer to many of the MIDP2 lacks (background processing, multitasking, improved UI, etc…) is late. No phone hit yet the market, and even, MIDP3 as a standard is already below the market. MIDP3 is two years too late.
  • Why JavaFX? Sun introduced JavaFX trying to compete with Adobe AIR, and Silverlight. Mistake.  As I already explained (“JavaFX, the missed opportunity of Sun“), they are not good at this. Why Sun did not invest instead to provide an embeed VM into iPhone for instance?
  • Fragmentation: one of the biggest historical issue of J2me. Something that new platform don’t have yet, due to their short life. But when we will have tenth of manufacturers doing Androïd phones, I guess that there will be fragmentation too.

So this seems to be a pessimistic article about J2me, especially regarding the fact that I invested so much in this technology (I’ve been in MIDP2 expert group, as well as MIDP3 one). Again, J2me is still the leading technlogy in terms of installed base, but in  term of usage and application, the gap is not as big. So the game is quite open, iPhone/Androïd deployment will increase this year, and I am sure that others technology will emerge.

Reblog this post [with Zemanta]