Daniel Rocha's Forum Nokia Blog

Is the Java Community Process hindering innovation in Java ME?

Fri, 29 Aug 2008 20:37:57 +0000

Specifying new APIs and functionalities through the JCP seems a good idea at a first glance, right? This limits fragmentation in the Java platform, ensures the APIs are agreed upon by a number of stakeholders, and limits the adoption of proprietary APIs by manufacturers, making them resort to the "official" APIs defined by the JSR expert groups.

In the desktop and server environments, this seems to be working wonderfully well: new features are added and released aggressively, keeping Java at pace with or ahead of the most modern development technologies and other languages.

But what has it done for mobile development?

Granted, MIDP 2.0 was a great thing and optional APIs based on it were created and adopted very fast by just about everybody. This opened new doors for the development of sophisticated Java ME applications using Bluetooth, file system, multimedia, location, web services, the works. However, this process seems to have stopped circa 2004.

Take Nokia 3250 for example: launched in 2005, it had a nice API package for that time, and i liked it. Now look at the Nokia N96: latest of the latest from Nokia, has dozens of new hardware and native C++ functionalities, three new runtimes (Python, WRT and Flash 3). What is new on it's Java? MIDP 2.1 (zzz), eSWT (not a JSR) and IAP UI (proprietary). The core runtime support is the same as a 2.5 year old device. Where is the innovation?

In 2 and a half years, we saw the rise of two entirely new platforms: Android and iPhone, dozen new runtimes for mobiles (Python, Flash, WRT, WidSets) and .NET Compact Framework becoming a serious contender. What have we seen in Java ME? MIDP3 has been in the works since 2004!

4 years is enough time for many new platforms and runtimes to emerge, but not enough for finishing a spec? This is my question to you: is Java ME lagging behind as an innovation platform because of JCP?

Your opinions are eagerly awaited.

[]s
Daniel

Which technology should I use for development? Round 1: Java

Tue, 27 May 2008 18:29:05 +0000

If I had just made a dollar each time I heard this question... *sigh*.

With the availability of so many different development technologies in Nokia's platforms today, sometimes is hard to decide which of them we should use to build our application, isn't it? There's Java, Symbian C++, Open C, Flash Lite, WidSets, WRT Widgets, Python, and the list is still growing.

This is good news for developers, since not everybody has the same technical background nor is developing the same kinds of applications; this means at least one of the technologies will fit our experience and purpose like a glove, and we are going to use it. On the other side, this may confuse newcomers to the wonderful but fragmented mobile software world. Usually it goes like this:

Question: "I want to write an application that opens a file and sends it out to a web server. What should I use to create it?"
Answer 1: "Java ME, FileConnection API"
Answer 2: "Don't bother, use C++ or you will get a lot of security prompts."
Answer 3: "Why use C++ when you can do the same with Python? C++ is way too hard!"
Answer 4: "Python does not run on S40, use Java."
Answer 5: "Do you really need all that jazz? Why don't you go with Flash Lite and use server-based persistence? Your application will look great!"
Answer 6: "Flash Lite is too fragmented. Use Java, but beware of the MIDlet signing issues or your app's user experience will be crap!"

Go check the Discussion Boards. It is crowded with examples of conversations like the one above. Having answered this question so many times before, I decided to summarize my answers in this blog, in the hopes of helping developers decide what use from the growing technology options pool offered in mobile devices these days. Please keep in mind that the following are my opinions on the subject; yours may differ and even prove mine wrong, but that's the beauty of interacting with people within a community. As the number of technologies it too big for a single post, I will continue my analysis in the upcoming posts. I will start off with the most popular mobile developmentp platform, Java ME.

Technology: Java

Good for:

Productivity applications - Examples: sports trackers, expense control apps, Personal Information Management (calendar, phonebook, etc.).
Games - Both casual and complex.
Enterprise applications - These don't require fancy user interfaces. Using LCDUI and the standard packages can go a long way pretty fast.
Rapid prototyping and proof-of-concept applications.
Network applications - RSS readers, weather services, blogging applications, mobile versions of Web applications.
Creating truly portable apps

Why?

Java and its mobile version are very simple to use and learn - An experienced programmer, even coming from other C/C++-based languages, can get a pretty good working knowledge of how everything works in a matter of weeks and start producing applications quickly. This leads to faster time-to-market for Java ME apps.
Applications are generally portable between S60 and S40 platforms - Although there are some differences in implementation, supported packages, audio/video formats and so on, those are few in number and thus easier to work around. You don't need to entirely rewrite your application so it will run on N95 instead of 6131: a few runtime checks and versioning tools will be enough.
Game API combined with optional packages makes it a killer for game development
Straightforward network API makes it easy to communicate with web services - The GCF (Generic Connection Framework) is a simple and unified way of using the network on Java ME applications. Once you learn how to do one kind of connection, you will have learned them all.

Bad for:

Accessing device resources - Examples: SMS Inbox, file system, gallery, hardware.
Multimedia applications - Examples: Video streaming players, audio and video recorders, camera applications.
Performance-intensive applications - Scientific computing, image processors, video decoders, sound processors.

Why?

Java's functionalities depend on Java Community Process process: if there's no official, industry-standard API for what you want to do, you are out of luck. Example: accessing SMS inbox.
Mobile Media API implementation is (too) highly modular, a lot of runtime checks are needed. Also, most functionality is implemented on the native side and then made available to Java's virtual machine, such as the camera access. This may have a serious impact on performance.
Fine-grained control over video, audio and camera is generally not available. Although JSR 234 (Advanced Multimedia Supplements) tackles some of these issues, it still can't be compared to what's available on other technologies, and its device availability is still low.
Access to the file system is provided by FileConnection API, but it's somewhat restricted and requires the midlet to be signed, otherwise multiple security prompts will be displayed, taking your user to tears (believe me). The signing process itself costs money and has some bureaucracy, so be prepared.

As I said before, these are my opinions on the technologies. It does not mean that X is better than Z, and Z should be thrown into the dirt and kicked in the head, like XML in the funny The Parable of the Languages. If you get your requirements right, it's very likely that your question of "what to use" will answer itself. Need to access the Inbox? Down with Java. Need portability? Down with Python and C++. Fancy UI? Flash. Requirements management is a science, not an art, so when you get it right from the start, the development technology to use will pop up naturally.

Next time I will cover the darling of all Internet programmers, now getting much of the attention on S60 platform: Python.

See you!

Want a sexy UI in your Java MIDlet? It's now possible with LWTUI! (with video)

Wed, 14 May 2008 22:23:39 +0000

Sexy UIs are all the rage today, right? FlashLite apps, WRT Widgets, WidSets, all of them have distinctive user experiences which differ greatly from the way we interact with native S40 and S60 applications. More colors, more animations, better usability, all making up a great way for developers to differentiate their applications and make them more attractive to the end user.

In Java MIDlets however, you are stuck with a very poor UI toolkit, the LCDUI, which has very few components and few options on how to alter their appearance; most of the time you're giving hints to the underlying implementation regarding the way you want the components to be displayed. Even if you do so, however, there's still a big chance your hints will be ignored and the UI will be rendered differently on each device. This can be a pain if you are developing for many different phones, with different screen sizes, input methods and form factors. Actually, to be fair, this can be a pain even if your target is a single device.

To circumvent these challenges, developers had either to developer their own UI toolkits, based on raw Canvasses, or use a 3rd. party toolkit such as J2ME Polish, which is great but requires a paid license to develop commercial applications, and this can be an unbearable cost to a small developer.

Searching the web and some mailing lists, I found this very interesting project, called LTWUI (Lightweight UI Toolkit), which is a cross-device UI toolkit created to provide developers with the possibility of developing compelling user interfaces without writing painful low-level Canvas code. It's based on Swing programming paradigm and it's key functionalities are:

LWTUI demo midlet running on E61i

Swing Like MVC
Layouts
PLAF & Themes
Fonts
Touch Screen
Animations & Transitions
Rich widgets
3D Integration
Painters
Modal Dialogs
External Tools
I18N/L10N

It's still in Early Access release but you can go to the project page and download it so you can play around with the toolkit and run its demos on emulators and real devices. The great thing is that the library is released under the Sun Licensing Agreement (SLA) which makes it usable by commercial applications without having to pay any fee.

I ran the LWTUIDemo midlet on my Nokia E61i and N95 and it worked beautifully. It's a bit slow though, but nothing that compromises the user experience. I recorded a video of LWTUI running on my N95, so you can see what's up for use in your Java apps; I guarantee you will enjoy it.

Last but not least, the project is open source, so you can contribute to it, just go to the project page for more details on how to participate.

Here's the video, enjoy it:

[]s
Daniel

A little bit of hot Java

Fri, 11 Apr 2008 16:36:34 +0000

Pretty interesting document posted by Aleksi Uotila on the S60 Java blog, containing a PDF document about S60 3.2's eSWT plug-in for Java applications. I have been using this toolkit's desktop version for years and I must say I have never looked back to Swing or AWT, so I really hope there's more development on this side for mobile devices, since innovation on Java platform has been a bit slow these days, partly due to the JCP process and everything.

Here are some screenshots of how eSWT apps look like:

Direct link to the article here.

******************************************

After Carbide.j's demise, I have been working hard to get used to the other toolsets in the market. Adaptation to NetBeans Mobility Pack was pretty swift, but I can't say the same about EclipseME, since I had many conflicts with my version of Eclipse, but thanks to Leisti's article on Wikipedia I finally got what works with what then my setup is now running smoothly, and I'm a big fan of C-like macro preprocessing, which helps a lot in reducing the problems of device fragmentation. EclipseME, as well as NetBeans, have this feature and I love it, specially when dealing with "new" APIs not available across S40 and S60 (Location API, do you hear me?) and also with the (too) highly modular Mobile Media API.

<code>
// #ifdef DEBUG
System.out.println("Some debug output");
// #endif
...
</code>

******************************************

Speaking of fragmentation, the other day I was checking my GMail account and I came across an ad for Tira Jump 2008. For those who don't know it, Jump is a tool to facilitate application deployment across mobile devices, so you don't have to do it manually. I saw a presentation by these guys at JavaOne 2005 and was pretty impressed when they created a MIDlet game which could run on 120 devices almost automatically. Today they claim support to 1200 device models, which is quite a number! They have a free version of the tool that you can use to test the product and deploy your midlet in up to 12 different models. I'll give it a try later.

******************************************

Why so much JAVA? I'm writing some chapters of an upcoming Java book for a well-known editor, so I have been thinking in Java instead of Portuguese for the past two weeks, and it's been fun.

Speaking of Portuguese, my native language, the "hot java" joke never made any sense to us, since we don't call our coffee "Java", but I nevertheless inserted throughout the post just to please our English-speaking readers :)