Hmm, what if you could run a server on your mobile? Jetty, the lightweight Java HTTP server has been ported to Android as i-jetty.

You can use Jetty to run server logic and Servlets right on the phone itself.

For example, you could take a Web based application and deploy it on the phone, and have the phone’s browser talk locally. Jetty also supports Comet style Web development, so your little Web browser based application could get some PUSH.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="org.mortbay.ijetty">
    <application android:icon="@drawable/icon">
        <activity class=".IJetty" android:label="@string/app_name">
            <intent-filter>
                <action android:value="android.intent.action.MAIN" />
                <category android:value="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

When Ars Technica first took a look at the Android SDK they had a few complaints.

Luckily, they came back, and took a look at the most recent release and were able to see improvements:

One very noticeable change in the Android user interface is the addition of transition animations. The animations show up in many places throughout the system, generally when windows, dialogs, and menus appear. They are very subtle and add some additional elegance without becoming a distraction.

I tested several of the applications that come with the SDK, including the mapping program, the contact book, and the web browser. I also tested the experimental Google Talk chat integration feature. I was able to connect to Google Talk and receive messages, which are displayed as items on the notification panel. The performance and usability of the bundled applications is pretty decent.

Shai Almog has written about developing Android code tips using Netbeans, which offers his thoughts after porting the bean-properties project to the platform. bean-properties allows you to do things like:

Property<Integer> x = PropertyImpl.create()

First, one of my main problems with Android was the lack of some core Java SE classes that made compiling code to Android rather difficult.

This seemed like a huge porting problem until I realized: “Android is not Java…”. I then started placing the missing classes within my project in the java.* packages and javax.* packages and compiling my code against my own mockups. E.g. Android is missing java.awt.Graphics, which I don’t really need for the general functionality but I do need it for compilation. So I just created the java.awt.Graphics class and stub methods which allowed me to compile my code in a portable way.

I would appreciate something like “Android for MIDP developers” and “Android for Swing developers”, since the guys at Google seem to have changed so much in the naming convention area. So here is a basic cheat sheet for Swing/MIDP developers that I hope some people can build on:

View - Component for Swing or Item for MIDP developers. This is the basic visual element in Android.

Layout - Unlike Swing layouts or MIDP layouts the layout is usually a container, so you add View’s directly to the layout (a layout IS A View).

Adapter - this has no MIDP equivalent. This is closest to a Swing model with the addition of a renderer of sort. So in Android both concepts of a model and a renderer are unified. Android will ask the Adapter for a view which it uses to render the model information, it will then return the view to the Adapter for “recycling” which seems odd for Swing developers used to the renderer concept but it makes some sense.

I am at JavaPolis in Belgium, and Sun is taking the prime time of its keynote on JavaFX to talk about mobile. Tim Kramer started off with the usual “Java is on bazillions of devices” slides, and then talked a lot about how open sourcey they are.

It got interesting when Angela got up to give demos using NetBeans (Tim made a nice “Eclipse is painful” remark) that included a SVG Makeover of an app, and pointed to many other apps on the ME Application Developers community.

This page describes the “SVG GUI Makeover” of an existing lcdui.*-based application called “Local Business Search”. More information and the full source code of this application can be found
here as part of the Mobile Ajax Project

The Local Business Search application consists of three screens: The query screen, the result screen, and the map screen. The Yahoo! Local web service is used to search and retrieve business information that is then displayed in the application. We leave the underlying logic untouched but rework the application UI using SVG and JSR 226 technology.

With SVG and JSR 226 many improvements are possible. We can start by replacing the existing screens with SVG-based screens and add simple animations. Next, we can improve the usability by employing SVG techniques to create animated components such as scrolling lists and transitions. Finally, we can enhance the UI flow by utilizing overlays and transparency.

Not all of these have been implemented at this time. Currently, the code focuses on replacing the lcdui.*-based screens and using animations and a scrollable and zoomable list to improve the application UI and usability. These changes alone results in a dramatic improvement of the application and should give developers a good idea what is possible and how to get started in reworking their own content.

Additional changes and enhancements will be made over time.

Just when you think that maybe J2ME isn’t all that bad? Another new user account:

I’ve always read people rant about J2ME on the intarwebs but I never really knew why. Now I do. I had to create a J2ME phone application for a class this semester and it was quiet a learning experience. I was very pleased with J2ME and all the capability available in the different JSR’s. The application I made let’s the user query where other people are at, if they also have the application on their phones. It uses SMS messaging between phones, the Location API, XML parsing, and queries a REST service (Yahoo Maps image api). See image below.
Everything worked beautifully on the emulator, but going to the phone, Wow, that was frustrating. Number one is getting all the device permissions correct. Then, I had threading issues because there are about 5 different threads running in my application at any one time. Then when you add in the cryptic or non existant error codes on the phone, I never did get it working. But I think the instructor was pleased so that’s the important part.

Will I ever code another J2ME application? Not if I can help it… One good thing that came from it is I used Netbeans extensively and now I plan to use Netbeans as my primary IDE. I’ll also be looking at it for an RCP project I have in mind.

Nokia is beefing up their JVM in S60 and having it join the modern error by allowing for dynamic libraries:

Prior to 3rd Ed fp 2, S60 Java had traditional CLDC VM architecture where all API code (class files) were compiled into the virtual machine executable. Now the Java API implementation code is no longer in the VM executable but will be dynamically loaded when needed.

This means that Java apps should start up faster, and we also get access to more features, and we will get more and more over time.

Some will complain saying that “Java is meant to be portable”, but personally, I want to be able to get close to the metal from time to time, so give me the opportunity.

We also see Widgets: The S60 Web Run Time, what is it and how can I use it?.

( via Simon Judge )

Simon Judge is attempting to understand how Google Maps Mobile cell ID-based location actually works:

Hence, my best guess at how this all works is…

App sends IMEI and Cellid (if available) to Google
If IMEI is for operator with location service agreement then get position
else if Cellid available then look it up in Google cellid/position database
else tell the user their phone isn’t supported

He also notes that Java ME, in most cases, is unable to reliably retrieve a cell ID.

Richard Monson-Haefel, ex EJB author, current mobile analyst, thinks that Microsoft should love Android.

His reasoning is basically: Android will fragment the Java world.

I disagree. Java on the phone is already fragmented. J2ME isn’t ONE thing, it is broken. As he himself says, Sun is moving on to Java SE on the phone, which makes sense as we have the computing power now. The current batch of top phones are computers, so let’s utilize that power.

Android is hopefully going to open up the entire mobile market. I don’t know if this will help Windows Mobile. In some ways it should (open networks etc). I don’t think that Android is going to cause Java developers to jump over to Microsoft though. They now have a great platform that is going to push Mobile Java forward.

I wouldn’t be too happy Microsoft. Ed Burnette feels the same way too, and put out a rebuttal:

If Mr. Monson-Haefel had done a little research first before making blanket statements like this, he would know that Microsoft .NET Compact Framework is not the same as regular .NET. Compared to the desktop version, the Compact Framework has some things trimmed out and some other things added in that are specific to mobile devices. Sound familiar? Android takes the exact same approach.

There is still one overall “Java platform”, regardless of what the language on top is (Java, JRuby, Groovy, etc.) or the particular flavors of the API (ME, SE, EE, GWT, Android), how the code is compiled and run (JIT, AOT), or even what the bytecodes look like. The Java platform is much bigger than any one hardware platform or vendor.

Android represents an incredibly positive new injection of resources and excitement into the Java, Linux, and open source communities. It’s unfortunate that a respected analyst like Mr. Monson-Haefel fails to recognize this fact.

The new Google Maps with My Location product is an update to Google Maps for Mobile that has location information even if you don’t have GPS.

It uses information from cell towers a la Navizon on the iPhone.

As for privacy:

This approximation is anonymous, as Google does not gather any personally identifiable information or associate any location data with personally identifiable information as part of the My Location feature. The feature can also be easily disabled by anyone who prefers not to use it.

And more info:

If you have a GPS-enabled device, this blue dot corresponds to your GPS location. At times, or if you do not have a GPS-enabled phone, you might see the blue dot surrounded by a light blue circle (as shown on the right) to indicate uncertainty about your location.

Why the uncertainty? The My Location feature takes information broadcast from mobile towers near you to approximate your current location on the map - it’s not GPS, but it comes pretty close (approximately 1000m close, on average). We’re still in beta, but we’re excited to launch this feature and are constantly working to improve our coverage and accuracy.

The My Location feature is available for most web-enabled mobile phones, including Java, BlackBerry, Windows Mobile, and Nokia/Symbian devices.

Just press “0″.

The Masters of Doom is a great read. It details the rise of the two Johns of id Software. Man those guys worked hard. So, when you hear Carmack discuss gaming you have to listen.

GameDaily BIZ spoke to John Carmack at length about the new mobile studio, how id plans to attack the mobile space, Apple’s “horrible decisions,” overcoming the challenge of developing in Brew and Java for many handsets and more.

Everyone is jumping on his words about the iPhone and Apple, but there is a lot more to it, including his thoughts on the mobile gaming space in general:

There are a lot of reasons why mobile gaming is the way it is right now, and my initial assessment is probably shared by a lot of people. Most of the games are just crap; there are a lot of really bad things and shareware type games that people would give away for free on the PC. There aren’t nearly as many cases where you take a professional team of developers and try to do something really good. [That said,] you are also significantly hamstrung by the platform itself… the download limits, restrictions in the APIs, huge variability across the hardware platforms and the carriers. It’s an ugly market from a developer’s standpoint.

Consoles are clean and wonderful. You produce one title and it goes through one publisher and you sell millions of units if you’ve got a good title. In the mobile market, it’s ugly like a retail business. Domestically, you’ve got a handful of carriers and that’s reasonably clean, but then when you go into Europe or Asia, where half or more of your market is, you’re dealing with dozens and dozens of different [carriers] and it’s a model that’s not really comfortable for a lot of software developers. The tiny customization that you have to do means that the sort of hardcore technical programming winds up being not as relevant because you could do something that’s spectacularly clever on one platform and have it be something that doesn’t even work on a whole of other ones.

You have to approach it in a very different way, but I do think it’s clear that the games are getting a lot better. In the last couple years I’d like to think that we had something to do with that with Doom RPG and Orcs & Elves being critically acclaimed titles that sold really well. I know for a fact that we were instrumental in having Sprint raise their over-the-air download limit and to allow us to do a high-end Java version to make it look somewhat competitive with the Brew version. Initiatives and little things like this will allow games to improve a lot more over the coming years to the point where they won’t necessarily be an embarrassment to look at. You’ll be able to have games on the cell phone that look like games on other portable platforms like the DS and PSP. There’s no doubt that right now there are cell phone handsets that have all the hardware power necessary to be significantly better than the DS, but you don’t see that in the games themselves for all of these non-technical reasons.

When you look at the rise in casual gaming and merge that with the rise of the mobile, you have to think that it will be huge.