Two days ago Google launched its new web browser, called Google Chrome. Quickly lots of people downloaded it to have a try and see how it worked. After some testing time I can say that it does run fast. With high probability, the reason is the new browser engine it uses, launching each website and tab like a new process and in a smart and easy way.

But after testing it I thought “Ok but, will Google provide a Chrome version for mobile devices?”. And surprisingly I got an answer from Sergey Brin, Google co-founder, who talked about this in an interview at the Chrome launch event. In the event he said that Chrome will make its way to Android, the company’s mobile phone operating system and software suite.

Brin also said that both Android and Chrome have been developed separately but that now the two projects are public and nearing their first final releases, it’s probably that Android’s browser “is going to pick up a lot of the Chrome stack”, pointing to JavaScript improvements as one area. Chrome and Android’s current browser both already employ WebKit, an open-source project for the process of interpreting the HTML code that makes up a Web page and rendering it on a screen, what makes them get closer.

With this on-working state browser and the current mobile browsers, we start to have the chance to choose a web browser for our mobile device, although in some cases it depends on the O.S. our device has. Below you can find a little table with the current mobile web browsers, the O.S. they support and the development state.

I wish all these browsers were cross platform and then we could forget about our device O.S. and choose the one we like most even if we change our phone.

Via MobileCrunch

Adam Gowdiak announced last Monday a set of 14 security vulnerabilites in JME platform for Nokia S40. Gowdiak, a Polish researcher from Security Explorations, his own start-up, mentioned that with these bugs would allow an attacker making phone calls from the phone, sending text messages , recording audio or video, access any file on a Nokia 40 model phone, obtain read and write access to the phone’s contact list, access the phone’s SIM card, and more.

Gowdiak has only disclosed part of the gathered information, asking for 20.000 € to Nokia and SUN Microsystems for the rest of the information.

I don’t want to evaluate or give my opinion about the business model of Gowdiak’s start-up.  But I think that publicly disclosing part of the information is not the best strategy to obtain such benefits. You better not try to scare big companies like Nokia or Sun.

I hope this vulnerabilities will be fixed soon, for the good of S40 platform.

Link InfoWorld , JavaHispano

First of all, let me explain what LWUIT is and what it means for mobile java developers.

What’s LWUIT?

According to its creators, “LWUIT is a UI library that is bundled together with applications and helps content developers in creating compelling and consistent Java ME applications. LWUIT supports visual components and other UI goodies such as theming, transitions, animation and more”.

Why is LWUIT important for mobile java developers?

JME has got a very limited set of user interface controls. Moreover, the results are always very poor. If you want something nice you have to use low level APIs in order to do so, which is very frustrating and costly. LWUIT adopts a SWING like approach, with better results. This way, mobile java developers can obtain much better user interfaces for their applications.

There are other similar technologies like J2ME Polish with similar approaches, with the difference of SUN being sponsor of LWUIT.

Now LWUIT has open sourced its source code under a GPLv2 with Classpath Exception license, allowing  commercial developments on top of this API. Now, you’ll be able to find out how this API works internally and improve it at your convenience. Don’t forget to publish your code modifications (you have to do it since the license is GPLv2).

Very Good news.

Link LWUIT Home Page

Jarpa is a newborn baby which seeks packaging Flash Lite into Java ME. It still lacks of documentation, just some on Google groups. As the authors said in their website, ” Jarpa allows Java ME and Flash Lite Developers extend their mobile applications like in Flyer Framework or Janus but with the widespread acceptance of Java ME and Flash Lite mobile devices.”

Good Luck, Jarpa!

More Info Jarpa – Jarpa on Google Code

When it comes to develop Java ME applications, every developer knows how problematic is to provide a consistent user expierence accross a set of different devices. Each manufacturer has different implementations of the standard.

On Sun’s words, “Due to implementation differences in fonts, layout, menus, etc. the same application may look and behave very differently on different devices. In addition much of the advanced UI functionality is not accessible in LCDUI and requires the developer to write very low level ‘paint’ type code.”

Very clear.

For overcoming this annoyance, many developers implement their own UI code or make use of some UI frameworks like J2ME Polish. We have talked about it.

Now, Sun comes to rescue with Lightweight UI Toolkit, promising “look and behave the same on all devices using a programming paradigm similar to Swing”. This is what all we were waiting for.

The toolkit includes not only UI controls, but other advanced theming, transitions, animations, etc.

By now, only what they name “early access library binaries” are available with a Sun License Agreement (SLA), what enables using the library for free in commercial applications. Source code will be soon available with a GPLv2 license.

Will this UI Toolkit become a de facto standard for solving – at least, helping to solve – fragmentation in JME?

I have not tested it yet, but this enters number one in my to-do list.

Via MobilePhoneDevelopment
Link LightweightUIToolkit

“The full web on your phone, fast and free”. This is the answer to the “What’s TeaShark?” question on TeaShark website.

The first beta of TeaShark has just been released. It is JME-based browser targetting MIDP2.0, that relies on a proxy for rendering. The render engine is based on WebKit3 (the last release of the most popular browser rendering engine).

Some included features are: tabbed browsing, bookmarks management, browsing session recording, autocomplete in text boxes,…

We’ll have to keep an eye on the evolution of this new actor on mobile browser arena.

Via XatakaMovil
Link TeaShark

OK, so you are a Java ME developer, don’t you? and you are tired of having to manage several hundred of pdfs with the official specs of every JME device in the market, isn’t it? Here is the solution.

Sun microsystem maintains a device library database with all the information JME developers should need regarding JME devices. The database contains this information.

• Manufacturer
• Device Model
• Wireless Technology
• Band Frequency
• Java ME Software supported
• Screen Features including size and colour depth
• LINK TO THE OFFICIAL SPECIFICATION DATASHEET

And you can filter the list (it’s 36 pages long) by Java software. That means platform, technology, JSR, etc.

I have already bookmarked it. What are you waiting for?

Link JME Device Matrix

Eric Klein, Sun’s Vice President of Java Marketing, announced last week plans to implement an iPhone version of the Java platform. Following Sun’s announcement of the iPhone SDK, and taking advantage of the new open iPhone platform, Sun plans to implement a port of the Java Micro Edition (JME) for the iPhone. This version will use as many native functionality as possible, according to Mr. Klein announcement.  This way, some of the already available JME games will be available in Apple’s little wonder.

Apple will have something to say about this. Such Java port could only be viable through iTunes store deployment, at no cost. I don’t see customers paying for a new platform to run games and applications on top of, mainly because games and applications will be also charged. Seriously, the scenario is not the best for Sun. Java games work because JME is included in most mobile phones by default. Most people obtain Java games through SMS premium downloading. Personally, I don’t see those people installing the Java Platform by themselves in their mobile phones.

Maybe this announcement could lead to an agreement between Apple and Sun. It will depend on Apple, but I’m not sure that Apple wants another platform for the iPhone, now the official SDK has been launched.

Via InfoWorld 

Some time ago, Sun Microsystems divided their JAVA Blogs in a series of different technology focused blogs. I specially like the Java Mobility Techntips blog, for obvious reasons. This blog publishes different articles related to JME technology written by mobile specialists, most of then involved in JME standardization bodies, which gives them great credibility.

One of the last articles talks about Ultra-low bandwith communication with JME and SUN SPOT Technology. This technology can be compared with ZigBee, as long as it implements the same standard but only in its lower levels. The upper layers are not included, but it is essentially the same technological concept. What I find most interesting of this article is that it shows up that JME is more than mobile phones, presenting innovative applications to the technology.

Discover this exciting technology with this interesting article. Oh, It contains Java Code. Sorry.

Link JME Mobility Techtips Article

S60 Blog have published a deep analysis of the new JME features about to be included in S60 3rd FP2. Here is a brief summary of the most important ones, under my point of view.

• Nokia IAPInfo API
• Device dedicated Media keys (Play/Pause/Stop) access as normal key events
• Control over End call key (Red call key) behavior for application’s lifecycle
• Enabling device theme background for Canvases for custom component usage
• Prevention of screen saver via Nokia UI API
• Access to device IMEI, network access type (gprs / csd etc.), network id, network signal level, battery level, country code, date and time formats via system properties
• LCDUI Canvas Graphics scaling (introduced originally in 3rd ed) enhanced for orientation switching devices
• New threading system. Java threas are native from now on.

The most important change is under the hood. Nokia has changed the virtual machine architecture. I suspect that the reason why is to adapt the virtual machine to eSWT architecture. The new architecture also provides more memory for application development.

The change in the threading system is also significatn, as long as a native implementation provides a faster and better performing thread architecture.

Great news for S60 JME developers!!!! I’m looking forward to get a S60 3rd ED FP2 device to test the new features!

Link S60 blog