I installed the beta release of Opera Mini 4 on a K-JAM Pocket PC Phone Edition (Windows Mobile 5) this evening. I downloaded to a PC and copied the files over to the K-JAM using ActiveSync. Opera Mini is a Java Midlet. So, I used the Midlet Manager to fire up Opera Mini. It went through a lengthy but simple configuration and used my WiFi connection (I don’t have a SIM in the K-JAM) to get to the Interent.
I visited a couple of sites that are not formatted for mobile devices and found that Opera did a pretty good job of rendering the pages to fit both the portrait and landscape screen modes. It got a bit grumpy when I turned off WiFi and didn’t want to surf the net after turning WiFi back on. I had to shut down the Midlet manager and fire it up again to let Opera figure out how to get back to the web.
My main beef is not with Opera but with the general state of Java apps on mobile devices. They always look out of place and don’t conform to the Windows Mobile interface conventions I’m used to.
That said, Opera Mini adds enough value (browsing non-mobile friendly sites on a Windows Mobile device) that I’m keeping it on the K-JAM for a while to test drive it a bit more. I might even install it on the Dash to see how it looks on a smartphone.
Comments
9 responses to “Opera Mini 4 Beta on a Windows Mobile Pocket PC”
Werner… That’s it exactly. The midlet itself should not be re-written to conform with individual UIs. It can only run how it is told to run by the VM on the target device.
If there is anything to be done to change the way the app is presented its the VM that has to change.
Better VMs would be a good thing.
But as there is no market in 3rd party VMs on windows mobile then there seems little chance of this happening.
Werner: My point of view is fine and in line with most users. End-users have an expectation for an experience in line with the rest of whatever system they are using. If the UI looks like a Java Midlet environment from the start, then no problem. But, if the phone’s UI is a Windows Mobile one or a Palm OS one, or some Linux GUI, then, the rest of the apps should look and feel like that system. Java midlets break this experience and therefore break the UI contract with the end-user.
wrong point of view, the midlets are mainly for handheld phones, and the ui standards they basically implement are strongly derived from them. Midlets mostly look out of place on organizers, and even more so on windows mobile devices, they look pretty fine on most symbian based phones if you ask me.
The midlet api is rather platform agnostic in this regard, it has an abstracted ui api, which defines, control1, control2, label 1 etc…
nothing fancy in regarding where the control button has to be set where the command button etc… The midlet engine itself is responsible for the correct layout.
So who is at fault here, mostly the maker of the winces device midlet engine who just implemented the entire control rendering as a symbian clone (probably to gather the rather big symbian phone market) and didnt even give a next thought on user interface conventions on windows mobile! Or Microsoft who would have loved to taken over java and now is trying to kill it and has been trying for years, because the takeover failed?
The midlet api itself is rather innocent in this regard, it is limited on what you can do, especially in the ui area and rightfully so, because the implementors knew that different devices have different ui conventions.
Opera mini from what I could see in the ui area is using the standard midlet api, they didnt revert to any vendor specific extensions.
psionandy: What I am saying is that I expect serious developers to make a serious effort in adopting defined platform interface standards. I.e., abstract the engine from the GUI.
Todd…
So what you are saying, is that you want platform independent software, that has to be re-written for each platform in order to keep consistent with all of the other software on that platform.
A kind of write once, then write again and again kind of approach?
Lawrence: Thanks for taking the time to visit this blog and post your tip. I did not notice the “overview” mode. Will definitely try it out.
Hi, and thanks for trying out Opera Mini on your Pocket PC phone. The screenshot you posted shows the webpage in SSR (small screen rendering) or “fit-to-width” mode. Have you tried out Opera Mini 4 beta’s overview mode yet? To see what it looks like, view the demo video here: http://www.operamini.com/beta/demo/
psionandy: The original point of Java was write once-run anywhere (I went to the very first JavaOne conference excited about that aspect). Its aim is not to be non-standard. The original thinking probably was that it would define the GUI standard. However, the reality is that Java apps GUIs have never evolved much past the mid-1990s look-and-feel. So, most (not all) Java apps I see tend to diverge too much from the underlying OS whether it is Windows, Linux, Mac OS, or some portable platforms. I expect the apps I use to conform to the conventions of the underlying platform. And, I suspect a lot of other end users do to. We don’t want to have switch gears for each app we use.
Isn’t the point of Java Apps that they don’t conform to windows mobile interface conventions…
If you want a platform independent bit of software, it can’t be tied to the standards of one of the types of device that it will be running on.
Not sure how lengthy your configuration was, btw. Mine was just a straight install, and a couple of attempts to find the ‘best’ connection settings.