Tuesday, November 13, 2007

Android SDK is out - first impressions

After watching the video about the introduction of Android for developers, I'm convinced that the new phone will generally be as useful and user-friendly as e.g. the-also-newcomer iPhone. Well, it came as no surprise to me, I'm just expecting a lot of innovation from the new player in mobile space. I don't expect that the new platform will offer as many features as traditional Symbian-powered devices and I can even dare to say that it's not going to be as stable, either ... yet. However, I'm pretty sure that they will catch up soon and offer real alternatives for users, phone manufacturers, operators, etc.

What has totally escaped my attention, though, was that the programming language for this platform would be Java. Based on the fact that it's going to be a Linux-based OS I kind of anticipated that the programming language would be C/C++. I don't know the rationale behind this decision, but it will definitely give a boost to the otherwise stagnating JME programming environment.

I wonder, though, how Google is planning to solve the infamous Java fragmantation problem for mobile phones. What is that? Well, even though Java is a very popular and platform-independent (aka portable) programming language, it's just the set of Java core services that is available on every mobile device. The presence of additional features, such as advanced mobile graphics, security, etc. depend on phone manufacturers' decision, whether it's worth adding them. Which makes Java mobile applications market very fragmanted (some features are available, some are not) and development very frustrating. You know, I have heard an example that a mobile Java game programmer had to make 100(!) variants of his game "just" to be able to distribute it to as many phones as possible.

Another thing about mobile Java development is that most mobile phones are running on another operating system than Java. In fact, Java is not an operating system at all, even though there have been attempts to make Java-based mobile platforms, see e.g. SaveJe for more details. But Symbian OS is similar to Android platform in that they both have their native platform (Symbian OS and Linux, respectively) meaning that platform features are usually available in native programming language first and then some JNI layer added on the top and there you are, it's ready for Java programmers. So far so good. However, it introduces some latency in the equation as it requires some time to write features in native environment first and wrap it in the second round. Will Android suffer from the same problem?

My regular readers already know that I was involved in S60 Browser development and it was very challenging and I really liked it. For that reason, I'm happy to see that Google chose WebKit for their mobile browser (S60 Browser is also based on this rendering engine) and in the demonstration it worked well. I was wondering which display method they would choose for web pages:

  • S60 approach that displays the web page in its entirety without scaling
  • or iPhone approach that scales down the web page to so that it fits to display dimensions, though it's hardly readable, but lets the user zoom it very conveniently (e.g. by double-tapping on screen)
They actually chose both: they first display the page without scaling and then user can scale it down for better navigation. I'm pretty sure that Nokia has their own IPR on MiniMap (i.e. the zooming interface) so that might be one of the reasons why Google didn't choose that option. However, what surprised me that they use the same visual history for page navigation as in S60 Browser.

So these are my first impressions after spending half an hour with Android after midnight. I'm really keen to hear your comments - just as usual! :)

Tote

[Update]: I'm shocked, check this out: Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME. It basically says that Android phones will NOT be JME-powered, but you can write JSE programs to them. With Android, Google has introduced their own VM, Dalvik, which eventually does not make use of Java bytecode, but their own Dalvik format. It's all to get rid of Sun being involved in licensing.
It's another question how good or bad will it be to the community. It means a new variant on the horizon, a VM incapable of running so-far-standard Java bytecode, thus your midlets will have to be re-compiled. I can see why Google is happy to have their own solution to this problem, but I can also see why developers would be unhappy due to that they'll have to take just another Java variant into consideration. Even if their pockets will be full with (Google's) money.

6 comments:

Anonymous said...

As far as I'm aware, Sun's plans for JavaME are to eventually deprecate it in favour of full Java compatibility on mobile devices... pdu

Anonymous said...

What impressed me personally is the Google's dedication to the platform side. You know, the other mobile platforms try to do just about everything from the HW layers, to end-user apps. No surprise that it's difficult to be perfect in all the corners simultaneously. Google laser-sharp aimed at what constitutes exactly the platform - they targeted developers more, than manufacturers and even end-users. The HW and manufacturer's support is also needed, but without any HW yet they already won quite many developers heart and in the age of smartphones it means a lot.

jouni miettunen said...

I believe it was OPERA who first used the technique of scaling web pages to fit the device screen limits. Not iPhone, which was released couple years afterwards.

Gábor Török said...

You might be true. However, I was talking about mobile browsers using WebKit as rendering engine.

Prof Kiran Trivedi said...

Hi, I too visited the details of Android, At first impression it seems a change for mobile users but nothing new by them. simply a phone with few google products at the initial stage. People will not waste their time to learn again something based on java. Android will take few years to build a community like FN. The best part of Android is opensource. Nokia can also open upto some extent, as its finally a business winning race. The negative part of android is it looks like a computer kindda interface, they are not able to bit Nokia-symbian a truly mobile OS. Coding also seems a bit tedious task in android, while nokia's python for series 60 is open source and Rapid application development. I would like to say no need to worry Nokia developers just be careful of new comer, The market share, operator support, developers worldwide and great community of Forum nokia are the big PLUS for Nokia. I think android will take decade to reach here, and in this decade Nokia symbian will always be ahead of it. I would end up with an example -- The new android can be a threat for second and third position between iphone and gphone. Nokia still remains at the top. Let them fight...!!

Anonymous said...

I wrote about Android after 30 minutes of reading the pages and I'm totally unimpressed. The whole coding style seems totally messed up, there is no security etc. I personally think Android will be even worse than Symbian to code.

But we'll see if it'll change and be something more usable someday. I won't hold my breath, though.