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.

Perst has certified an object oriented embedded database for Android. SQLite is already on the device, so why would you want to use something else?

Why use Perst in software for Android? Because Perst helps developers create small-footprint embedded Java applications that are fast, reliable, and cost-effective to develop and maintain. Perst can do this because it is:

Object-oriented. Perst stores data directly in Java objects, eliminating the translation required for storage in relational and object-relational databases. This boosts run-time performance.

Compact. Perst’s core consists of only five thousand lines of code. The small footprint imposes minimal demands on system resources.

Fast. In McObject’s TestIndex benchmark, Perst displays one of its strongest features: its significant performance advantage over Android database alternatives.

Reliable. Perst supports transactions with the ACID (Atomic, Consistent, Isolated and Durable) properties, and requires no end-user administration.

Rich in development tools. The Perst API is flexible and easy-to-use. The breadth of Perst’s specialized collection classes is unparalleled. These include a classic B-Tree implementation; R-tree indexes for spatial data representation; database containers optimized for memory-only access, and much more.

McObject also provides TestIndex, an Android-ready database benchmark application that measures performance using both Perst on Android, as well as Android’s bundled SQLite database system. You can download TestIndex with complete source code, no registration required.

SiFR, a provider of GPS-powered location platforms, announced that

It will rapidly implement key end-to-end location-awareness features needed to enable mobile devices powered by the Android(TM) platform to provide an optimal location awareness experience for consumers.

SiRF is actively working on the Android platform to include some of the more innovative features of Secure User Plane Location (SUPL), a standards-based protocol that allows a mobile handset client to communicate with a SUPL Location Platform (SLP), including transport layer security (TLS) for location privacy and multiple session capabilities to provide the most compelling user experience. SiRF is also implementing support for Android-based assisted GPS (A-GPS) handsets, including mobile station based (MSB) and mobile station assisted (MSA) positioning methods to facilitate the Android platform passing Open Mobile Alliance (OMA) and 3GPP conformance testing for third-party certification.

Location is huge, and it appears that 2008 is going to be a break out year for location-aware services and applications.

We also heard about a prototype for Android using the HTC Qtek 9090.

Winstron, a Chinese company, is showing their Android phone at CES:

The GW4 is reportedly currently using Linux right now, but should be running Android within a few months.

More info at ZapNat.

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.

Nikita Ivanov writes about grid computing, which you normally associate with big iron. However, Nikita has written about grid computing with Android, and how, with power mobile phones, the largest grid out there could be the cell phone market:

I heard this idea probably 3-4 years ago when somebody mentioned to me that the biggest grid in existence is the grid comprised of all the cell phones out there. Think about it: every cell phone acts as a grid node, it has certain (albeit minimal) processing power and can easily communicate with any other cell phone in the world peer-to-peer (well, in practical sense, almost easy). And there is a special class of grid tasks that fits this type of grid perfectly: hyper-parallel grid tasks - the tasks that can easily split into thousands or even tens of thousand small micro-jobs where each such micro-job can take 2-3 seconds to get delivered onto processing device and spend another 5-10 seconds on it to get processed and send optional result back.

Now, back 3-4 years ago there were several obvious problems in this picture:

• Phones were hopelessly underpowered and worked performed by a grid of hundreds of cell phones could easily be done by a single workstation
  • Not so today. Phones are quickly getting more and more powerful and there is a class of tasks that can fit naturally into this profile (like human image recognition, for example).
• Connectivity was so slow that it basically negated the whole parallelization effect as grid would have been spending all its time in communication
  • Not so today. 3G phones are (finally) getting to US and within 2-3 year will dominate the phone market. With 3G connectivity – the problem is basically solved as you are getting your office type of connectivity on your cell phone.
• Phones had proprietary system APIs and development of the uniform grid middleware was very hard if not impossible all together.
  • Not so today – and that’s the key.

Can you feel your battery sucking away as it tries to find aliens?

Simon Judge points to the LiPS and Androis/OHA Faq, which outlines the similarities (unity) and differences (open vs. ad-hoc standards) between the Linux Phone Standards, and the Open Handset Alliance.

The Open Handset Alliance, a group of more than 30 technology and mobile companies, is developing Android: the first complete, open, and free mobile platform. On Monday 17th December we’ll be hosting Dick Wall from Google’s HQ in California for a special session about the platform. Dick will provide a technical overview of the Android architecture with an emphasis on developing real-world applications.

You will need a wireless enabled laptop to take part in this event. Refreshments will be provided, but places are strictly limited.

Reserve your seat here.

Over on the Google Developer Podcast we have released a new episode where we chat with Dianne Hackborn and Jason Parks of Android.

As always, it is always nice to hear real people talk about technology, and this is a great example. You get to hear about their past at Be and PalmSource, and how it has affected their work on Android. You really get a feel for how this is a next generation platform based on the experience of people who have done this before, on many platforms (e.g. from Windows Mobile, to Danger, to Palm).

What will you learn on this podcast?

• Some history behind the project
• The high level architecture of Android. For example, how Linux processes handle the VM and manage security (the VM doesn’t handle it)
• Details on the Dalvik VM and how it is optimized for small devices
• The architecture: From Intents to Views to Permissions and more
• How XML is slow, but the tools convert the XML to a nicer format for you
• The tooling and steps for building an application on Android
• How so many objects have a URL, and how the environment is like a mini-SOA (Services across processes instead of across the network)
• Thoughts on how you program for small devices, and things to watch out for if you move from the desktop
• The control, or lack of control that you have over the application lifecycle
• “Everything you do drains the battery”
• The thread story: they exist, you don’t have to deal with them if you don’t want too, and the UI
• Using XMPP for messaging

You can download the episode directly, or subscribe to the show (click here for iTunes one-click subscribe).