Airlan San Juan's Blog

J2ME Archives

My Ode to Opera Mini 4

The Beta version of Opera Mini 4 released today, and I gave it a test drive.

First of all, let me say that I've always liked this Java ME mobile browser, mainly because it gave you full web pages at an amazing speed, so much so that the native browser on my smartphone has very rarely been taken out for a ride on the old WWW.

Personally, I love the idea of a fast, nimble application for the masses, a no-nonsense, beautifully optimized and crafted piece of software whose function defines its form. If Apple's iPhone Safari is a tawdry, dressed-up dandy who prances about in voluminous costumes, then Opera Mini is a quiet, earnest, and honest young man who dresses plain, but works hard and fast and gets the job done.

Perhaps many people share my opinion, because Opera Mini is only a year and a half old, but it has already accumulated some really amazing statistics.

• It has more than 15 million user downloads.
• It has served more than 3 billion web pages.
• It is the most popular mobile browser by far, and it will remain so for the foreseeable future.
• It has a larger marketshare than some desktop browsers like Mozilla, and even some major desktop browsers like Safari in certain areas of the world.

I singled it out early last year, then named it as one of the Top 10 Java killer applications a few months later.

However, I was never that satisfied with the look and feel of pages rendered by Opera Mini, and the lack of a virtual mouse was glaring when compared to the bulkier and slower, but more full-featured native mobile browsers. So, I downloaded the new Opera Mini 4, and was instantly floored by the advances made since version 3 just a few months back, and by the fact that not all of the new features for version 4 made it to this beta version, so we're in for more good surprises later on.

I'll hasten to add though, that even with all the new advances, this mobile browser is still blazingly fast, mainly because the server-processed pages coming in are but a fraction of the size of full html pages.

But it's the new features that look to make my mobile web browsing much better.

First, like some native mobile browsers, Opera Mini now sports a virtual mouse that can be moved using my Nokia 9300's joystick. I noticed that I barely used it anyways when testing, but it's good to know that it's there when you need it.

Second, the pages rendered were significantly closer to the original than the previous Opera Mini browsers. For example, images were not stacked on top of text content, but were aligned correctly within the full context of the page. The screenshot below shows the BD-J reviews index page, where the images are right justified and the text content aligned in order along the left side. Clicking on the boxed text magnifies that area for close-up reading, as seen on the next screenshot.

Third, as can be seen in the screenshot above, Opera Mini clearly highlights in a bluish tinted transparent box any links in the page as you scroll close to them. This is one of the best new features among the lot, as it makes easy navigation a cinch compared to the older Opera Mini, which had a much less visible link highlighting scheme.

Obviously, the Opera Mini might not compare favorably in terms of rendering to some high-end browsers running exclusively on more powerful mobile devices, but that is mainly because this gem was crafted such that the varying versions would work in as wide a range of devices as possible with minimal changes, and some of these devices are magnitudes less capable than the higher-end smartphones. Indeed, the fact that the Opera Mini has improved so much and gone so far in so short a time is a testament to the dedication and innovation of its creators. Since feature phones have on the whole gotten more powerful and capable as time passes, it would not surprise me at all if this application gains so many features that it may even threaten the survival of the bulkier native browsers.

For those who'd like a taste of this new beta version without the need for a mobile device, Opera provides a nifty Java SE simulator, but I felt running it on my actual phone showed its capabilities better than the somewhat diminutive screen of the simulated cellphone. In addition, because of the large screen size of my Nokia 9300, I had no need for the magnification "tricks" used in the demo, which has a much smaller screen size.

Here's a screencast of the Opera Mini 4 running on the simulator, courtesy of Screencast-o-Matic, a very useful and really cool applet-based screenshot service.

For those with an itch to lambast the perhaps Java ME-less iPhone a la Hinkmond Wong, here's an interesting vignette from the Opera people comparing their gem of a browser to the iPhone (I know, don't ask me why they're comparing software to hardware, I don't have the latest flash and could not see the film). Opera Mini is free and works with most cell devices, while the iPhone - well, it's expensive, closed and proprietary, over-hyped, and comes with the horribly crappy Safari browser (who even my Mac friends have abandoned for Firefox).

Are Java desktop developers giving Java a bad name?

Unfortunately, I'm not kidding. When dealing with antagonistic parties, most recently in the Blu-ray arena, I noticed that their examples of bad Java applications almost always revolves around bad experiences with either Java desktop applications or applets.

We all know why applets got such bad reputations, but there really is no good excuse for Swing and the like to continue to give a sour aftertaste to users. I myself use Netbeans regularly, and although it has improved by quite a lot, there are still times when the thing slows to a horrid crawl when I use anything smaller than a 1 GB, 1.8 GHz box.

I deal with Java ME on almost a daily basis, and although the target of these applications are devices several times less powerful than desktops, I have yet to find a user who has complained as vociferously about them. Is this because user expectations for these smaller devices are less than their expectations for the performance of desktop applications, or is it because developers targeting more powerful machines have become unconcerned about code optimization, something that is foremost in the minds of smalljava developers?

BD-Java's Liar's Dice in Pirates of the Caribbean: Dead Man's Chest

There are only very few mass produced consumer products that can lay claim to being true works of art, and Disney's two new entries to the Blu-ray arena, Pirates of the Caribbean: The Curse of the Black Pearl, and Pirates of the Caribbean: Dead Man's Chest, may represent the best that high-definition discs today can offer, and as such can be said to have crossed the line into true art.

The care and love that went into the production of these discs are lovingly apparent in the beautifully rendered cover art and outer cardboard sleeve. It may be mere marketing fluff, but the inclusion of cardboard sleeves, and the use of artwork on the disc itself (which Sony in particular seems to have eschewed for its blu-ray offerings), give some weight and majesty to the actual product, kindling in the user a sense of heightened anticipation.

Each title is composed of two discs. A BD-50 disc that contains the movie itself and a BD-25 disc that contains all the extras. That's 75 GB of pure entertainment folks! :-)

For the full review, click here.

Fast-loading "Consumer JRE" == CDC?

The current Java.net poll asks people what was the most important announcement from the JavaOne 2007 general sessions, and the runaway winner of the poll seems to be the hints that Sun intends to introduce a Fast-loading "Consumer JRE". Now, wouldn't it be funny if this is based on Java ME's CDC?

As Sun's Hinkmond Wong notes, Java ME's CDC is:

If this were the case, then this putative resurgence in Java desktop development will be driven by Java's continuing explosive success in the small java arena.

The highlights of the Java TV sessions

Before I lay me down to sleep, here are some of the top items I thought were discussed in the Java Entertainment sessions (Blu-ray's BD-J and OCAP/cable Java):

• OCAP development (developing Xlet apps for cable) is just as interesting as Blu-ray BD-J development, albeit perhaps less "glamorous", but probably more lucrative in the short-term.
  
  
• If you can develop BD-J apps, then it is but a short step to OCAP development. That is, you can leverage your skill in either field to encompass the other as well.
  
  
• Because of their experience with constrained environments, Java ME developers can more easily jump to "Entertainment Java".
  
  
• The studios (and Sun) are pushing strongly to make the BD-J specs publicly available to developers. The BDA is, in the words of one attendee, "stupid".
  
  
• The cable industry is starting to roll out Java-enabled set-top boxes (OCAP and OnRamp) in massive numbers this year.
  
  
• Everyone agrees JavaTV did not pan out the way they thought it would years ago, but because of the convergence of several factors, they believe that this time "it's the real deal, Bill".
  
  
• There have been 200 Blu-ray titles so far, but only 6 or so have been authored using BD-J. Sun and the studios would like to reverse this ratio.
  
  
• Development of BD-J authored discs take longer to do, but the studios believe the benefits outweigh the costs, and that more sophisticated tools coming will significantly improve the process.
  
  
• There is a definite lack of easily accessible tools and documentation on both BD-J and OCAP application development.
  
  
• JavaFX mobile is the solution to world hunger and wars. Ok, maybe not, but I am becoming more convinced it will be very beneficial to the easier development of more powerful and artistically elegant SmallJava apps.
  
  
• Cable wants You. Blu-ray wants You. Don't ever believe serious Java is only for serverside or desktop applications.
  
  
• Bill Foote is a pretty funny guy. Bill Sheppard looks like that actor in "While You were Sleeping" with Sandra Bullock. Congrats to the Sun Team (and to the guest speakers) for a GREAT TV track!

Let your Java app "feel the rain" on its skin

Your journey begins with the task of gently introducing your Java applications to the realities of the physical world, an area that normally exists beyond the confines of the limited and rather myopic worldview of the typical Java midlet.

In this paradigm that is exemplified by the new Sun SPOTs, a midlet without a way to "feel the rain" on its skin, is like a gourmet diner who is finally allowed access to a connoiseur's nirvana, only to find out that he has a cold and cannot taste any of the offerings placed before him.

As one singer put it in more elegant fashion:

Feel the rain on your skin
No one else can feel it for you
Only you can let it in
No one else, no one else
Can speak the words on your lips
Drench yourself in words unspoken
Live your life with arms wide open
Today is where your book begins
The rest is still unwritten

- Natasha Bedingfield

You will help write this book, and your Java applications will finally be able to "feel" things that they could not have done otherwise.

As a first step, we'll allow our new midlet to sense temperature and light.

The first thing you need to do is to create a Midlet skeleton from the demo applications that are included in the Sun SPOT kit. It is ok to start from scratch if you want, but why struggle when someone else has already made the path for you easier? I used the BuiltInSensorsDemo demo application and closely studied the source of the BuiltInSensorsDemo class. A quick look at the short source code will immediately assuage any fears by mobile developers that the Midlets here are vastly different than those in mobile devices.

For example, the same life cycle templates are in there:

    protected void startApp() throws MIDletStateChangeException { 
        try {
            run();
        } catch (IOException ex) { //A problem in reading the sensors. 
            ex.printStackTrace();
        }
    }


    protected void pauseApp() { 
    }


    protected void destroyApp(boolean arg0) throws MIDletStateChangeException { 
    }

The one big difference of course if that this Midlet uses some quite unusual libraries.

import com.sun.spot.sensorboard.EDemoBoard;
import com.sun.spot.sensorboard.io.IScalarInput;
import com.sun.spot.sensorboard.io.ITemperatureInput;
import com.sun.spot.sensorboard.peripheral.ITriColorLED;
import com.sun.spot.sensorboard.peripheral.ISwitch;
import com.sun.spot.sensorboard.peripheral.ILightSensor; 
import com.sun.spot.sensorboard.peripheral.LEDColor;
import com.sun.spot.util.Utils;
import java.io.IOException;

import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;

The easiest way to get started is to simply copy that demo application folder, modify the contents and rename the folder, then open the lot using Netbeans. In this case, I simply copied the entire BuiltInSensorsDemo folder and renamed the new folder to "PickyMidlet". I then changed several things in the folder to reflect the new name and make sure it compiles and deploys correctly. In the project.xml file in the nbproject folder, rename the BuiltInSensorsDemo to PickyMidlet. I also changed the name in the build.xml file to reflect the change in nomenclature. FInally, in the resources/META-INF/manifest.mf file, change the name of the midlet to reflect the new name.

Now, open Netbeans 5.0 and go on over to where you have your "PickyMidlet" folder. Open the project and Netbeans will show the new project in the left hand pane.

Now, safely rename the original midlet to the new PickyMidlet name via Netbeans' refactoring. You can obviously leave the same name, but just for the sake of differentiation it would probably be a good idea to change the name.

Set PickyMidlet as the main project and then clean and build the project. You should be able to compile the project with no problems as this is based completely as of this point to the old demo Midlet.

The original midlet cleverly uses various LED lights to convey changes in movement, temperature, and light intensity to outside observers. However, I could do without the blinking lights and so I modified the original code to make it simpler for demonstration purposes. I also personalized the Midlet by having it respond to variations in temperature as a person might. As you can see from the code sample below, getting values from the sensor boards are easy and simple to do.

You can click here to continue reading the guide to this simple procedure.

Postcards from the edge of Javaland

I could hear the crickets chirping, or at least the hum of the air conditioner fans as they strove to cool the bodies of several hundred enthusiastic and jumpy Java developers crammed into an auditorium of Google.com's New York City office. They were all here to listen to Rod Johnson talk about the Spring Framework, and I had just asked whether anyone knew about BD-Java after the host had graciously allowed audience members to ask general questions.

Granted that I was in a roomful of server-side jockeys who may not know, or care, that Java exists beyond the confines of a Tomcat or Weblogic server, but the profound silence that greeted my query was surprising anyways to a Pervasive Java enthusiast like myself, who lives and breathes CLDC and CDC and all the other acronyms that have cropped up in MicroJavaland.

So, why the recent excitement on my part? Well, quite a lot of new developments have occurred since Sun and some big CE companies had touted BD-Java as the next big thing during the last couple of JavaOne conferences.

For one thing, more and more Blu-ray titles have been released and authored using BD-Java. The relatively primitive and amateurish BD-J game in Speed in late 2006 has given way to the polished and engaging interactive features in Disney's Chicken Little and Digital Leisure's Dragon's Lair this year. Going forward, BD-J will show up in some interesting titles coming in late Spring, including Disney's Pirates of The Caribbean: The Curse of the Black Pearl, where it will power an interactive in-movie feature that presents facts on-screen about the legends and lore of pirates, as well as in Pirates of the Caribbean: Dead Man's Chest, which features Liar's Dice, a single-player game shot in live-action HD video.

The picture quality in Dragon's Lair (Blu-ray) is strikingly brilliant and often stunning. © Digital Leisure Inc.

The Playstation 3 has also started shipping worldwide, and it has, as promised, tilted the balance strongly away from a competing format called HD-DVD towards the Blu-ray high-definition disc format. HD-DVD is backed by Toshiba, Universal, and Microsoft, and is authored using a Javascript/XML framework called HDi. The Playstation 3, and Blu-ray players from Samsung, Panasonic, Pioneer, Phillips, Sony, and others, are capable of running BD-J apps (called Xlets from the Personal Basis Profile) instead. Although hardware sales of players for HD-DVD and the much more expensive Blu-ray players were neck and neck throughout the latter part of 2006 (48% Blu-ray versus 52% HD-DVD), there were reports that HD-DVD titles were outselling Blu-ray titles by significant margins, due mainly to the fact that it had a three-month lead, and early adopters of the HD discs were leaning more towards the former format. However, this lead by the HD-DVD camp has quickly evaporated in 2007, and BD titles currently outsell HD-DVD titles every week by commanding ratios of at least 2:1, and sometimes by up to 5:1. Casino Royale (Blu-ray) also became the first HD disc to break the Top 10 ranking of DVDs in Amazon.com (it peaked at #6) and the first HD disc to ship 100,000 copies (and sell roughly 50% of that its first week), which helped the 9-month old Blu-ray format beat standard DVD in this important milestone (it took the DVD version of Air Force One 11 months to reach the same level).

BD-J has also joined the ranks of MIDP apps ("Midlets") and perhaps Applets as one of the few technology buzzwords that have started to become common terms for the everyday consumer. I am a member of various Audio-Visual discussion forums, and regular threads discussing the merits and problems afflicting BD-J have been cropping up like wild toadstools lately. I must admit that it gladdens my JavaHeart to see regular joes pontificating like hardened coders on BD-J and other Java ME subjects. They may not know exactly what BD-J is, but by golly it better not stand in the way of them watching their favorite movies in glorious high-definition.

This is not to say that there are no problems with the current situation, because there are quite a few. From a developer's perspective, the major problem is that it is not at all easy to dive into the world of BD-J coding because of several factors. First, although BD-Java is based on MHP/GEM/Havi/JavaTV APIs that are freely available for inspection around the web, and are even the main subjects of several books, including Interactive TV Standards: A Guide to MHP, OCAP, and JavaTV by Morris and Smith-Chaigneau, and HAVi Example By Example: Java Programming for Home Entertainment Devices by Gibbs et al, the Blu-ray specific API information must be leased from the BDA (Blu-ray Disc Association). In addition, the current slew of authoring tools for BD-J retails at prices in the higher five figures, princely sums that are quite beyond the reach of individual developers. For a more detailed look at problems facing first-time developers to BD-J, David Foster of Digital Leisure Inc., the producers of Dragon's Lair (Blu-ray), has given an interesting account of his personal experiences with the intricacies of this new CDC technology.

There are also problems cropping up on the consumer side of things, mainly because of the seemingly glacial pace that hardware manufacturers have taken in implementing the various advanced BD profiles (BD-Video 1.1 and BD-Live) into their players. Because such key features as network connection, PIP (Picture-in-Picture), and local (persistent) storage were not made mandatory from the very beginning, the result is that many current Blu-ray players may lack the capability to use more advanced BD-J features in the future. This is an extremely hot topic among A/V enthusiasts right now because there are rumors that some studios have delayed the release of Blu-ray versions of their titles because they are waiting for these features to become mandatory.

Notwithstanding these problems though, the future of BD-J looks bright, and there are several major efforts to keep it in the spotlight. This year's JavaOne conference will feature a special track of sessions and events targeting developers interested in gaining an understanding of digital television software technologies and markets, and a Java SIG group focusing on TV and blu-ray Java called Blu-Dahlia was started by Bill Foote and Bill Sheppard of Sun Microsystems.

Java developers sure do like making things from scratch

You'd think that after 10 years - an entire DECADE mind you - that Java developers would have a treasure trove of pre-built components that they could use to quickly cobble together their otherwise home-brewed apps.

Alas, perhaps there are just tons of examples of this in the bigger world of Java SE and JEE, but at least in the world of small Java, trying to code some of the simplest functionalities can cause some people who are stingy about buying books to go into a real google frenzy.

Take this MIDP app that I recently started coding as a side hobby. I needed to have the thing talking to Java servlets on the server, and I figure this'll be a cinch. As a Java developer, my first impulse was to simply use some code from a book, and admittedly, the code snippets to do POSTs that I found are pretty straightforward:

 try {
         hc=(HttpConnection)Connector.open (targetUrl,Connector.READ_WRITE);		 
         hc.setRequestMethod (HttpConnection.POST);
	 hc.setRequestProperty("User-Agent", "Profile/MIDP-2.0 Configuration/CLDC-1.0");
	 c.setRequestProperty("Content-Language", "en-CA");
		 
         dos=hc.openDataOutputStream();
         byte [] req_body=theData.getBytes();
         int size=req_body.length;

         for (int i=0;i < size;i++) {
                dos.writeByte (req_body[i]);
         }
         
         dos.flush();
         
         // receive response
         dis=new DataInputStream(hc.openInputStream());
    
         int ch;
         while ((ch=dis.read()) !=-1) {
                 b.append((char)ch);
         }              
    } finally {    
              if (hc !=null) hc.close();
              if (dis !=null) dis.close();
              if (dos !=null) dos.close();
      }

But then I have to worry about session management (where parsing requests and response headers becomes a fulltime job) and all the other tiny details that are needed to make it into a robust functioning unit (saving multiple sessions to the RMS for example), and I got to wondering why some good soul who had done this before hadn't simply packaged the entire functionality into a nice, shiny new component that I could plug into my Midlet suite and thence say et voila!

Given such a huge library of Java ME components, even relative newbies should be able to assemble together a functioning suite in no time flat. Imagine some newcomer to the world of Java who starts up Netbeans Mobility, uses the really cool Midlet Visual Mobile designer tool to quickly create the needed MIDP forms by dragging and dropping screen commands, list items, textfields and whatnot, then imports pre-built components into the Midlet suite, again by dragging and dropping instead of going to the source.

Sound good, right? I did my googly thing but the sites I found were sorely lacking in actual meat. So, if anybody knows of any places for Java ME developers to acquire basic components such as these, please feel free to tell me, and everyone else here. If there aren't any such places, perhaps I could add it to the To-Do list of the Java ME group that was set up for just such problems?

Java powers the Web 2.01

Why is it I have the feeling this Web 2.0 is just for the cool kids, and not for bookish nerds like me who wouldn't know how to strike the pose if my life depended on it? Granted, I cut my teeth on just plain HTML, when having attributes like align and valign on table tags was the height of coding wizardry, but I'm entitled to date the prom queen too, aren't I?

Let me explain.

Take that perennial underdog - also known as Java on the Desktop. Just when Evans Data pronounces that Java Swing has become the dominant GUI toolkit in America.....just when Java desktop browser penetration has really started to go into overdrive....and just when Java desktop apps like Azureus and others start winning accolades and awards left and right, along comes this thing called AJAX to pull the rug out from under it.

You'll have to pardon my confusion, but when I was a young lad in the Philippines, AJAX meant that bar of soap you used for washing your dirty dishes.

But I digress.

One of the ideas that I've recently been absolutely fascinated with is the rise of pervasive or ubiquitous computing, which is why we started a virtual JUG here at Java.net called JavaMeCDC-Group. C'mon over and join if you like good reads, because the hidden focus of the JUG is on the use and promotion of Java as the "glue" that holds together a world that is fast becoming the computer. Sun was wrong. The network isn't the computer - the network is just the veins and nerves that tie the actual construct together and move the flow of information.

Welcome to the coming singularity.

If the Web 2.0 deals with energizing the PC experience for people, then the Web 2.01 deals with something that I think will be much greater - empowering people to become more aware of their near-environment and the world in a way that transcends the limitations of our everyday human senses. Sure, when you sit in front of your PC and call up your newsreader you are in a sense attached to the wider world out there, but just imagine a world where people are constantly aware of the world around them - a world without borders (ok, stop me before I go-Neo and start flying like superman).

But there are many problems with Java (and specifically Java ME) as that glue right now.

First of all, it takes real programming know-how to create Java ME applications. The great thing about HTML was that it allowed lazy knuckleheads like me to create cool web sites using nothing more than a text editor and some jumbled tags.

Secondly, the ability of people to take advantage of all the available Java ME application offerings out there is limited. They are commonly herded into "Shopping" sites by the operators, where the available apps are strictly controlled, or if they manage to make it out into the WAP world, they encounter strangely confusing sites which urge them to download JARS (heaven forbid!) and Java JADs (whatever for???).

Thirdly, there is currently a dearth of content available that would entice most people to take the trouble to jump into the data plan jungle offered by carriers. Not everyone out there is a bejeweled fanatic, and not everyone is enchanted by the thought of blasting critters with mini-guns on tiny LCD screens.

A rose by any other name is still a rose.

But perhaps some companies and organizations offer a way out of this conundrum. They all sport cool Web 2.0 monikers like Plusmo, and BluePulse, LiteFeed, and Widsets - but they all pretty much do the same thing, which is to enhance the experience of consumers when it comes to the smaller mobile world.

People initially download a Java ME client, usually via a link delivered to their devices using SMS. They can then use this client to seamlessly download mini-applications called "widgets" on demand, and synchronize the client with the server (which, almost like Opera Mini, has become tightly-integrated with the client app). Each lightweight widget performs a specific function, whether it be a weather widget that gives the current weather, or one that shows RSS news feeds from the BBC. More interestingly, the framework allows common people with some basic knowledge to wrap their web content into widgets and deploy them quickly using standard templates! I created one for my former Java Kecil 2x blog and deployed it onto my Nokia 9300 in about 3-4 minutes using the Widset templates.

The very new Nokia Widset in particular bears special mention because of the nice user-interface that it sports. The pic below shows how the server state (as depicted on the Mac desktop) is perfectly synchronised with the mini Java apps deployed on my Nokia 9300 smartphone.

As the browser-based Web 2.0 revolution marches on, events are taking place on a potentially grander scale in the small devices arena that are mirroring events in the PC world. But in this case, the oft-used mantra "Java Everywhere" could actually be descriptive of the platform's essential role as the glue upon which the entire framework flourishes.

You might call this the rise of the mobile widgets, but you might also think of it as the coming of the Mini Application Portals, or perhaps the Mobile Application Portals, which is abbreviated in the same way.

Either way, welcome to the Web 2.01, my friend!

This work is licensed under a Creative Commons License.