Let the mobile
games begin, Part 2
Tutorial Details:
Let the mobile games begin, Part 2
Let the mobile games begin, Part 2
By: By Michael Juntao Yuan
J2ME and .Net Compact Framework in action
n Part 1 of this series, I overviewed the two leading platforms for smart device development: Java 2 Platform, Micro Edition (J2ME) and .Net Compact Framework. The two platforms' ultimate goals are the same: to enable rich clients for users and to improve developer productivity. Both platforms offer similar benefits:
Well-designed programming languages for development (Java for J2ME, and C#/Visual Basic .Net (VB.Net) for .Net Compact Framework): Compared with older device development languages such as C/C++ and eVB (eMbedded Visual Basic), these new languages are easy to learn and have a large pool of qualified developers.
Managed runtime environments: Applications for both platforms run inside virtual machines that manage security, memory usage, and runtime optimization. Managed memory access improves developers' productivity by freeing them from the error-prone chore of memory management.
Rich libraries and components: Object-oriented programming languages like Java, C#, and VB.Net allow developers to reuse software modules. Both platforms come with a rich set of libraries for advanced UI (user interface), network connectivity, data management, and XML Web services. Libraries for accessing common device extensions (e.g., the GPS (global positioning system) or scanner module) are also available.
Familiar APIs from standard frameworks: J2ME and .Net Compact Framework allow desktop developers to migrate their skills to mobile development. For example, the Java AWT (Abstract Window Toolkit) UI can be directly used in certain J2ME profiles, and the Windows Forms controls can be used in Compact Framework applications. The IBM Service Management Framework (an OSGi (Open Services Gateway Initiative) implementation) even brings common J2EE (Java 2 Platform, Enterprise Edition) APIs and patterns to devices.
Extensive development tools: More than a dozen generic IDEs, development toolkits, and command-line tools are available from leading vendors in the J2ME space. Microsoft's flagship development tool, Visual Studio .Net, is also fully integrated with Compact Framework.
Despite those similarities, the differences between the two platforms are profound. In a nutshell, J2ME is a specification shaped by industry consensus, while .Net Compact Framework is a polished and fast-paced implementation driven by a single powerful vendor. Below, I describe the two platforms' hardware support:
J2ME runs on a range of devices from smart phones to set-top boxes from all major vendors, while .Net Compact Framework runs only on devices from Microsoft Pocket PC licensees.
Since Microsoft has control over Pocket PC hardware vendors, .Net Compact Framework developers have a specific hardware specification to program against (e.g., screen size) and can assume the availability of certain native software (e.g., Windows Media Player).
J2ME is also moving toward reducing the device market fragmentation via specifications like Java Specification Request (JSR) 185 (Java Technology for the Wireless Industry), which specifies the minimum hardware requirement for certain J2ME profiles.
Due to the requirements of uniform and powerful mobile devices, .Net Compact Framework is suitable for cash rich customers with controlled mobile environments. It was initially focused on the enterprise mobile market, especially for Microsoft-centric IT shops, while J2ME was originally active in the consumer sector. However, in the long run, most experts expect both platforms to coexist in all market sectors. As developers, we must choose the right tools and make them all work in heterogeneous environments. For example, we need to make J2ME clients work with .Net backend servers and vice versa. In this article, I walk through an end-to-end mobile GIS (geographic information system) application that mixes Java and .Net on client, server, and middleware layers. However, before we can dive into the sample application's technical aspects, we need to step back and look at the business aspects critical to our architecture design.
Read the whole series: "Let the Mobile Games Begin," Michael Juntao Yuan ( JavaWorld ):
Part 1: A comparison of the philosophies, approaches, and features of J2ME and the upcoming .Net Compact Framework
Part 2: J2ME and .Net Compact Framework in action
Note: You can download this article's source code from Resources .
GIS services and the MapPoint Web Service
In this section, I introduce some background to our driving-directions example. I discuss the basic concepts of location-based services and the geographic information system. I also introduce a commercial GIS service: MapPoint Web Service, which is the "brain" of our example mobile application.
What is GIS?
Location-based services (LBS) supply customized information based on the mobile user's current location. For example, a visiting nurse can quickly locate patient information when she is close to that patient's house. LBS is touted as the killer app for mobile commerce because it enables new applications not possible in the fixed location desktop world.
A central piece of any mobile LBS solution is the GIS component, which allows users to determine street addresses from coordinates and vice versa; look up Yellow Pages and landmarks; calculate optimal routes; and render custom maps. The ability to work with GIS servers is a major requirement for any mobile LBS client. In this article, I develop a mobile driving-directions client that utilizes a leading commercial GIS provider: Microsoft MapPoint Web Service.
MapPoint Web Service
Standalone GIS servers capable of geocoding (assigning a latitude-longitude coordinate to an address), rendering maps, and other complex geographic algorithms have been commercially available for a long time. However, running a GIS server by yourself is probably too expensive for most small to midsized businesses. The costs include:
Hiring GIS experts to set up and maintain the system.
Licensing high-resolution digital maps and business telephone number listings. This could prove expensive if your users roam across many metropolitan areas.
Aggregating geographic information updates from many sources (e.g., road construction and business address changes) and frequently updating them to the database.
Ongoing server administration for secure and high-availability services.
Licensing cost of the GIS server software itself.
For most companies, it makes sense to outsource the GIS operation to specialized providers. One such provider is MapPoint, a managed GIS solution from Microsoft. MapPoint services are accessible via a set of SOAP (Simple Object Access Protocol) Web services APIs, which ensures that the services are available to a variety of client applications. MapPoint also allows users to upload their own geocoding data and points-of-interest listings for customized services. Users can pay for MapPoint services based on the number of queries or get unlimited queries for a flat subscription fee. Developers can evaluate the service for free for 45 days. Important remote methods in MapPoint 3.0 divide into four categories:
Common service: Contains utility functions common to other services.
Find service: Allows user to do generic geocoding tasks. That includes finding addresses from latitudes and longitudes and vice versa. It also allows searching for nearby points of interest.
Route service: Calculates routes and directions based on locations and waypoints. It also generates a map view representation of the calculated routes. The map view can be used to highlight routes on a map.
Render service: Renders the map for the locations or routes. It highlights routes, places pushpins and icons, and supports zoom.
The aggregation API
MapPoint offers fine-grained access to its GIS services, which allows us to design flexible applications without arbitrary limitations imposed by preset scripts. However, the tradeoff is that we have to make separate method calls for each small step to complete a task. For example to retrieve driving directions between two addresses, we must complete the following steps:
Convert the addresses to latitude and longitude coordinates
Calculate the route according to options
Render the overview map with the route and start/end locations highlighted
Retrieve turn-by-turn instructions for each route segment
Render highlighted turn-by-turn maps for each route segment
The last two steps need to be performed repeatedly for a long route with many segments. Since all those method calls are remote SOAP calls, those excessive round-trips cause long delays on slow wireless networks. To minimize the data transfer over wireless networks, we can place a portal middleware between the mobile client and MapPoint. The portal takes in two human-readable addresses in a single SOAP call; queries MapPoint via many API calls over the wired Internet; constructs the resultant driving directions; and returns the results. The portal provides a simple API that aggregates functions of the basic MapPoint API methods for specific applications. Figure 1 illustrates the architecture.
Figure 1. The aggregator portal architecture
So, the goal of our sample project is to build an API aggregation portal to MapPoint and then build three mobile clients using J2ME and .Net Compact Framework. To maximize the environment's diversity, we use Apache Axis, a Java Web service toolkit to build the portal.
The Apache Axis portal
As a Microsoft platform, MapPoint was never designed for Java clients. But its SOAP Web service interface makes it platform independent. Java programs can access MapPoint services using Java SOAP toolkits such as Apache Axis and Sun Microsystems' Java Web Services Developer Pack. Those toolkits can also expose Java objects as SOAP Web services for client applications. Here's how to constru
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Let the mobile
games begin, Part 2
View Tutorial: Let the mobile
games begin, Part 2
Related
Tutorials:
 XML JavaBeans, Part 1 - JavaWorld February 1999
XML JavaBeans, Part 1 - JavaWorld February 1999
|
Program Java devices -- An
overview - JavaWorld July 1999
Program Java devices -- An
overview - JavaWorld July 1999
|
Solve real problems with aglets, a type of
mobile agent - JavaWorld May 1997
Solve real problems with aglets, a type of
mobile agent - JavaWorld May 1997
|
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
|
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
|
JavaWorld
December 1999
JavaWorld
December 1999
|
Signed and sealed objects
deliver secure serialized content - JavaWorld November
2000
Signed and sealed objects
deliver secure serialized content - JavaWorld November
2000
|
Java security evolution
and concepts, Part 3: Applet security
- JavaWorld
December 2000
Java security evolution
and concepts, Part 3: Applet security
- JavaWorld
December 2000
|
Printing in
Java, Part 3 - JavaWorld January 2001
Printing in
Java, Part 3 - JavaWorld January 2001
|
Device programming with MIDP, Part
1 - JavaWorld
January
2001
Device programming with MIDP, Part
1 - JavaWorld
January
2001
|
Device programming with MIDP, Part
2 - JavaWorld
March 2001
Device programming with MIDP, Part
2 - JavaWorld
March 2001
|
J2ME: The next
major games
platform? - JavaWorld March 2001
J2ME: The next
major games
platform? - JavaWorld March 2001
|
Talking Java! - JavaWorld August
2001
Talking Java! - JavaWorld August
2001
|
Unleash mobile agents
using Jini
Unleash mobile agents
using Jini
|
All that JAAS
All that JAAS
|
Big designs for
small devices
Big designs for
small devices
|
Let the mobile
games begin, Part 2
Let the mobile
games begin, Part 2
|
Develop state-of-the-art mobile
games
Develop state-of-the-art mobile
games
|
Java and GIS, Part 2: Mobile LBS
Java and GIS, Mobile LBS
Using LBS
First, let\'s make sure that we understand what an LBS application is. Typically, an LBS application is trying to answer the question \"Where am I?\" and then do something with that information. There are a number
|
Power Messaging, Maps and more...
BuddySpace is an instant messenger with four novel twists: (1) it allows optional maps for geographical & office-plan visualizations in addition to standard 'buddy lists'; (2) it is built on open source Jabber, which makes it interoperable with ICQ, MSN,
|
|
|
|
