Maximiliano Firtman's Forum Nokia Blog

Localize me... even if I don't have a GPS

firt — Sat, 01 Dec 2007 20:24:29 +0200

Let's analyze many ways to get the user's geolocation.

Recently, Google updated its Google Maps Mobile application with a new "My Location" feature that works even without GPS. If you do not have a GPS-enabled phone, you might see a blue dot surrounded by a light blue circle over the map to indicate uncertainty about your location. Let's see how we can do this.

We all know that Location Based Services (LBS) are a great feature to add to many mobile applications. I want information based on my location. I don't want to receive restaurants from other city, I want to see weather, driving directions or traffic data from my geographical zone, I want to geotag my photos, and I want to know what other people think about the place where I am right now. I also want to socialize, play games, and organize meetings with people near me.

So, all we need is a GPS? The first answer seems to be "yes". The GPS is one of the best solutions to find the location of a user. The GPS (Global Position System) gives the developer the coordinates (Latitude and Longitude) of the user with some error (usually less than 100m) using satellites. And the AGPS (Assisted GPS) could be even better. The AGPS (if you have a Nokia N95, just update your firmware to get this feature) is a data-based feature to help the GPS to find faster the possition of the user. With AGPS in Nokia N95 now I can localize myself in less than 10 seconds outside and sometimes I can do it inside a building too.

We can query the (A)GPS from many platforms, like Java ME (Location API), GPS with Symbian C++ or Python and then search for information in our local database or remote server using the Internet connection of the phone. If we need information about the street, neighbourhood or any other data regarding the calculated coordinates we can use some inverse geocoding service: if I have some latitude and longitude, can you give me the street name and address?.

At this time only a few devices have GPS integrated, and less people have a bluetooth GPS connected to the mobile phone.
But, what happen with the millons of non-GPS devices?

Just look to these other solutions.

Solution 1

You can use the cell information of the phone to georeference the user. When you are connected to a mobile cell network you are in range of one or more towers. The range of the tower is called a cell. Since every cell has it owns range (100m, 500m, 1km for example) we really don't know exactly where the user is, but we know the zone with some error. Sometime this is enough useful to give the user the information. But, how can you use the cell to know latitude and longitude?

a) In Java ME there isn't any standard solution. You can query the CellID (Identification Number) using System.Properties("phone.cid") on some devices only. For example, this doesn't work in Series 40 devices. It only works in some Motorola or Sony Ericsson's phones.

b) In Symbian (Signed), you can get the Cell, Area and the Carrier (see this sample). With this combination you have a unique cell number in the world. You "only" need to convert this information in geographical information. How to do this? Here comes the difficult part. There isn't any direct way to make this conversion. You can use a Carrier API (if they have one), you can use some Open Source collection (like CellSpotting.com) or you can make your own one.

c) In dev cert Python, you can get this information. Just see this sample.

That's what Google is doing with its recently updated Google Maps My Location feature. If you don't have a GPS, you can still find your location using the Cell information. Google can compare your cell number with querys from other users having the same Cell and GPS, for example. So, Google is making its own cell-coordinates database (or buying it).

You can see a video of how Google Mobile Maps works here:

Solution 2

The mobile carriers should bring developers an API to know the coodinates of some user. Using three cells in range, the carrier can calculate where are the user and give the information to the developer through an API.

Solution 3

Use the IP address to find the location of the user. If the user is connected through WiFi (or 3G in some cases) you can try analize the IP address connected to the Internet. With the IP Address you can query some open database (like MaxMind or GeoIP) and then try to calculate where the user is with some error.

Solution 4

Ask the user! Don't be afraid to ask the user where is he or she! Your application can be smart and reduce the user's typing.

- If the user knows its position: The user can insert zip code, city name, neighbourhood name, address, street name. Just ask for one quick entry. You can query your database or some webservice.

- If the user doesn't know its position: The user can insert some information he is seeing, like a phone number found on a shop or some place name (parks, museums, stations).

Solution 5

Allow the user to select its current location from:
    - Home: ask the user where he/she lives when the application is installed and store this information.
    - Favorites places: query the Places database (GPS' devices) or make your own favorite places.
    - History: allow the user to select a recent place where he/she was. Order the list by frequency.

Visit this mobile Location design pattern in Little Springs Wiki.

Of course, you can make a mashup with all this solutions to develop some smarter way to get the user location.

Do you imagine any other way to get the location of a user? I'm waiting for suggestions.

Sun Open Sources Java ME under GPL

firt — Mon, 13 Nov 2006 05:09:59 +0200

I've received this information a few days ago, but I coudn't publish it until now. Sun Microsystems, Inc, the creator of Java technology today (Nov, 13) announced it is releasing its implementations of Java technology as free software under the GNU General Public License version two (GPLv2). Available today are a buildable implementation of Java ME (formerly J2ME) and the first pieces of source code for Java SE.

Available in the Java.net community is the source code for Sun's feature phone Java ME implementation with the Java ME testing and compatibility kit framework. Before the end of the year, Sun will release additional source code including its advanced operation system phone implementation and the framework for the Java Device Test Suite. Sun is also releasing as free software the javac compiler, JavaHelp and Java HotSpot technology, the heart of JVM and JRE for desktops.

In addition, an application developer project is available as part of the Mobile & Embedded community, with links to resources such as the NetBeans Mobility Pack.

Rich Green, execute vice president of Software at Sun said "By open sourcing Sun's implementation of Java technology, we will inspire a new phase of developer collaboration and innovation using the NetBeans IDE and expect the Java platform to be the foundation infrastructure for next generation Internet, desktop, mobile and enterprise applications".

More information on

www.sun.com/opensource/java

www.java.net

nb-openjdk.netbeans.org

What do you think?

Will this accelerate the development and evolution of the platform? Will this reduce fragmentation and drive down development costs throughtout the Java ME ecosystem as Sun is claiming? Will this modify your Java ME developer life?

The future of Java ME

firt — Fri, 29 Sep 2006 04:12:18 +0300

Everyone who worked with Java ME a couple of years ago (for 'J2ME' fans, this is the new name of the platform), should feel very confortable with the platform today. That is because Java ME didn't evolve too much in the last years.

We are at a time of great changes in this area. Mobile hardware capacity has grown in the last years, and people are updating their mobile phones more frequently. That's the cause of the need of evolution in Java ME and, for that, JCP (Java Community Process) is working on multiple standars. In these series of post we'll discuss each of them. In last JavaOne in San Francisco, many of these 'new mobile architectures' were presented, and some of them are already implemented in some new devices.

Let's start to see some new APIs that complements MIDP and CLDC. These new JSR or APIs are the standard way to use new features in mobile Java technologies right now. Remember that if a device doesn't implement a API, we don't have a possibility to use it or install it on that device. There are a dozen of new APIs (just look at www.jcp.org), but I'll focus in this post in the following:

Web Services

This isn't a new API, but there aren't many developers using it yet. This API allow us to consume SOAP web services from the mobile device; a very useful feature in mobile development to create Smart Client Applications that connects to a remote server. This API is JSR-172 and it is implemented in some IDEs in a graphical way, like Nokia Carbide.j 1.5 and Netbeans Mobility Pack 5.0.

If we are working with JSR-172 no capable phones, we can still consume web services using our own library, by parsing the SOAP XML with the help of another library, like kXML, a free Java ME XML parser library.

Mobile Payment

This is a great feature for us (we are doing this for receive a payment, don't we? ;-) ).

In these area, there are two adittional packages to work with. These are Secure And Trusted Services APIs (SATSA JSR 177) and Payment API (PAPI JSR 229), Using this APIs we should develop, in the future, applications that charge the user for some service or content using, a) Remote Transactions (like a ringtone download) or b) Local Transactions using proximity technologies (like with a soda machine). These two APIs covers: security, interoperability and easy of use.

SATSA API add security and encryption to Java ME. With PAPI we can make mobile applications to charge the user, abstracting us the architecture behind. The user (or operator) should have available many payment mehods installed on the phone (by SMS, credit card, phone bill, etc) and we only decide how much we want to charge, and the user will be prompted to select a way to pay it.

Let's see some code of the process

import javax.microedition.payment.*;  
public void startApp(){
try {
   TransactionModule myTrans = new TransactionModule(this);
   myTrans.setListener(this)
   myTrans.process(featureID, “Title", "Description");
…
}catch (Exception e) { }
}
 
public void processed(TransactionRecord paymentRecord) {
switch(paymentRecord .getState()) {
   case TransactionRecord.TRANSACTION_SUCCESSFUL:
      // Payment OK
      break;
   case TransactionRecord.TRANSACTION_REJECTED:
      // Payment KO
      break;
}
}

The information about the price and other data is stored inside the manifest, in the JAR file.

We should use this feature in the future to offer some new cool levels for our games or, ¡new game lifes! Imagine yourself playing Space Invaders Ultimate in the last level, with the last enemy ship to kill and you lost your last life... will you pay $0,20 to get one more life? Will be 'gaming ethical' to offer this in a game? Interesting question...

What's Next?

In other post I'll continue with the Future of Java ME... talking about SVG, Internationalization, Contactless technologies, new tools and IDEs, and the most expected ones... MIDP with CDC, Next Generation Mobile Platform and MIDP 3.0.