Introduction to Technology Stack

In general terms, a technology stack consists of the parts or sections of any set of components or services that are used to deploy or provide any technical solution or application.

When applied to the software industry, technology stacks might be examples such as the TCP/IP protocol stack and the seven layer OSI model.

User Interface Technology Stack

User Interface Technology Stack, as the name suggests, comprises of the technologies that are used for UI development. For the purpose of this blog, we will extend the same definition and call it technologies that could be used to develop the UI and need not primarily be UI technologies. The UI technology stack could be different for different kinds of applications. Hence, we will discuss the three most common kinds of applications being developed, which an ordinary user commonly gets to use:

• Web applications
• Desktop applications
• Mobile applications

In the following subsections, we shall cover these three kinds of applications and the UI technology stacks that are most prevalent in their respective areas.

The figure below depicts the UI technology layer separation across Web and desktop applications (mobile applications have been intentionally left out in the diagram).

Web Applications

Web applications are the ones which can be accessed from a standard Internet browser, such as IE, Firefox or Google Chrome, on a desktop or laptop computer. This excludes ‘browser on a device’, which is covered later in mobile applications.

The first and foremost thing coming to mind about Web applications is terms such as HTML, DHTML, JavaScript and CSS from a technology point of view, which have been there from the early days of browser based applications.

Earlier, browsers could only render HTML and process JavaScript and CSS. But with the help of different plug-in components such as applets, Macromedia Flash, ActiveX, SilverLight and Flex, browser-based applications can now provide a very rich user experience. We shall now see a short overview of the different technologies available to develop Web applications.

HTML/DHTML

HTML today is the language all other programming languages render into after performing complex backend operations. HTML has transformed into a powerful language that can actually open sockets to server (HTML5). In January 2008, HTML5 was published as a working draft. It contains a set of new tags, CSS enhancements and JavaScript APIs.

DHTML allows developing better-than-browser experience with features such as drag/drop, fading, animation effects etc. As a result, applications will continue to provide such user interfaces for years to come.

AJAX

Ajax (Asynchronous JavaScript and XML) is a standards-based technique/design pattern for developing better-than-browser user experiences for server-deployed applications. It is a server side technology, but invoked from the client side. Ajax is primarily used to make interactive Web applications by retrieving data from the server asynchronously in the background without interfering with the display and behavior of the existing Web page. Features such as auto-complete, submitting a form without page reload and displaying the success/failure of submission, performing local user input validations are some basic examples of the usage of Ajax. Google Maps is one of the best examples of the use of Ajax to resolve complex issues.

JavaScript

Like HTML, the decade-old JavaScript has become the most popular programming language on the Web. JavaScript is object oriented and has support for classes, callbacks, events, run-time evaluation and much more. Third parties have come up with libraries that let ordinary users to develop applications with ease. A few of them are listed below:

• Prototype – Prototype is a JavaScript framework that aims to ease development of dynamic Web applications. Featuring a unique, easy-to-use toolkit for class-driven development and the nicest Ajax library around, Prototype is quickly becoming the code-base of choice for Web application developers everywhere.
• JQuery – JQuery is a fast and concise JavaScript library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid Web development. JQuery is equally powerful and easy to use as Prototype, plus the library also supports animation, giving developers an additional tool to add more style and features. It may be a tough call for anyone to decide between Prototype and JQuery.
• Both Prototype and JQuery are open source and free to use. There is an equally powerful paid JavaScript library called Ext JS, described next.
• Ext JS – Ext JS is similar to the above two JavaScript libraries but with enhanced capabilities of providing an interface and features more similar to those traditionally associated with desktop applications. Ext JS, unlike JQuery and Prototype, is governed under the LGPL style license.
• Java Server Faces – Java Server Faces (JSF) is a Java EE 1.4 component, allowing developers to develop user interfaced for their Java EE applications without much expertise on the UI technologies. It is a framework with a huge set of tag libraries and support for Apache MyFaces (Tomahawk) and many others, maximizing the developers’ productivity. Think about a traditional JDBC operation and displaying a record set using JSP on a webpage: JSF could do that by mapping a bean on the server side and the JSF DataTable widget would render the same results with using a simple tag, rather than iterating over the result set using JSP scrip-lets. The code looks neat and the objects are mapped on-the-fly to server-side managed beans. JSF also integrates seamlessly with CSS and JavaScript.

However, it does come with its own limitations and complexities. Though the configuration is very simple, one has to design the implementation to minimize frequent changes. JSF being very easy to develop, many tend to ignore the performance aspects and use tags very loosely. Once a decision to use JSF is taken, it may be difficult to change the application development to any other framework midway.

• Flex and OpenLaszlo – Flex and OpenLaszlo are similar declarative approaches to creating better-than-browser interfaces for Java EE applications. Flex and OpenLaszlo both are open source; Flex is Adobe’s product and also comes with a proprietary, license-based Charting supporting component. Both of them use scripts – either ActionScript (Flex) or JavaScript (OpenLaszlo).

While the two technologies have many similarities, one key difference is the runtime environment they require. Flex requires Flex Data server running for the client to interact with the server. Alternatively, the server could be any as long as the interaction points are exposed as Web-services. OpenLaszlo requires its own server to be running for client-server interactions. OpenLaszlo version 3 introduced SOLO deployment mode, which eliminates the requirement for a presentation server in some configurations. While some components of Adobe Flex are licensed, the cost of the overall application could become an issue. OpenLaszlo being open-source, many companies have firm policy restrictions on usage of open source software for application development.

Microsoft SilverLight

SilverLight is a Web application framework that provides functionalities similar to those in Adobe Flash, integrating multimedia, graphics, animations and interactivity into a single runtime environment. It is supported by multiple browsers on Microsoft operating systems as well as mobile devices running Windows 7. Novell, in association with Microsoft, have come up with MoonLight to bring out the most of SilverLight functionalities on Linux and other open source platforms. Like any other Microsoft technology, SilverLight stands alone as the only technology that tightly binds with .Net and requires Windows for development purposes. If the overall technology stack is independent of Microsoft technology offerings, then SilverLight may not be an option.

If the OS and .Net platforms are not a restriction, SilverLight stands in parallel to Adobe’s Flex and OpenLaszlo.

Discussed next are UI technologies for desktop and mobile application development.

Desktop Applications

Java Swing

Along with APIs from Java for Web development, Java AWT/Swing is a platform-independent, Model-View-Controller GUI framework for Java. Swing lost its edge with the introduction of many other GUI technologies, but is still in use by many products common in software development, typically IDEs such as Eclipse, BlackBerry (JDE), JBuilder etc.

Adobe AIR

Adobe Integrated Runtime (AIR), also known as Adobe AIR, is a cross-platform runtime environment developed by Adobe Systems for building rich Internet applications using Adobe Flash, Adobe Flex, HTML, or Ajax, that can be deployed as desktop applications.

Typically when we talk about RIA (rich internet applications) we immediately think of browser based applications, but AIR gives Adobe an edge to have RIA applications to be browser-less. One of the interesting facts is that AIR gets installed with Adobe Acrobat reader v9.3 without user knowledge, making most of the desktops that have Acrobat reader installed ready to run AIR apps and not requiring any additional software to make AIR apps run. Adobe AIR has not really caught up in the market space to be recognized as a popular desktop application technology, but certainly it is gaining attention in developing light weight applications. Also, JavaScript frameworks such as JQuery, Ext JS and Dojo Toolkit have been updated to support Adobe AIR’s application sandbox.

.Net(VB), .Net(C#) and VC++

Like Java, Microsoft also has .Net, VC++ and VB to develop desktop applications, though they have existed for quite some time and are the technologies preferred by developers on Microsoft’s platforms. Barring VB, both .Net(C#) and VC++ allow applications to utilize core system functions, e.g., kernel level access, device drivers etc. Developers on VB find it very easy to switch to .Net(VB) as the coding syntax and style are almost similar.

Mobile Applications

For mobile application development, two things have to be kept in mind. Like the desktop and Web, the mobile platform in itself has two kinds of applications:

• Native applications
• Browser based applications

Native Applications

These applications primarily use the APIs and frameworks supported on the operating system, and to a certain extent, the particular Java Specification Request (JSR) implementation for a particular model. For e.g., for Bluetooth programming, the device manufacturer may or may not have all capabilities/support for Bluetooth communication on all his models. This could vary on different models from the same company. Hence, when it comes to mobiles, one needs to study the brand, model and the support for features that the application is going to use. The security aspects are also important to study and evaluate before deciding on the model and brand. One key point is that there cannot be the same application code that can run on iPhone (Objective C), Blackberry (J2ME) and Windows Mobile (.Net Compact Framework) primarily because these platforms have support for different programming languages.

Browser Based Applications

For the mobile platform, when a native application is not an option, the immediate solution is to have a browser based application developed in XHTML, and along with CSS and proper design, the application could be made compatible to most of the devices (from different manufacturers and with different screen sizes etc). But, this is easier said than done.

There are far more technologies present than those discussed above to keep the article concise. The key is that none of these technologies is ‘one size fits all’ and hence not perfect for all situations. Each of these technologies has its own merits and demerits and can be a good fit depending on the requirement and expectations. So, how do we decide on the UI technology for the application?

For starters, the best way to reach out maximum users is HTML and technologies that generate HTML before it hits the client’s browser. For the opposite, when it is essential to install the application on user’s machine, then AIR, Microsoft VC++, VB .Net and Swing are the options.

The decision on which one to select is rather easy for desktops than for Web applications. Desktop UI technology is driven primarily by the technology used on the server side; rarely the UI technology would be on a different platform than that on the server side. If it is a stand-alone desktop application, the deciding factors are the features and extent of OS level operations that the application needs to perform. Microsoft technologies are the most preferred when it comes to low level programming. For RIA desktop applications, Adobe AIR and the Out of Browser solution from SilverLight could be an option.

For Web applications, there are many options, and all are equally powerful in terms of functionality, usability and providing a rich user interface. The key to selecting the right technology is to let the application requirements drive the technology choice for the best user experience. This may look like a very generic and obvious recommendation. In many cases, developers tend to miss the obvious and jump into considerations that are best known to them rather than what should be the best.

Some of the key points/suggestions that could be followed are:

1. Knowing the technology/framework well is not always enough to decide on the UI technology to use. The best approach is to walk through the requirements and then evaluate by prototyping some complex features, which should give an early indication of the efforts and challenges lying ahead.
2. Never hold on to a technology that you are most comfortable with. Experimenting with the newer versions, newer open source APIs, building sample UIs using newer technologies will always keep you a step ahead of competition. Many developers are still using Java Applets assuming that is the best for displaying graphics and dynamic data updates from server, whereas JavaScript libraries have been there for years now which lets them achieve far better results and in a very short development time.
3. Always remember: It is the user who uses the application and so, providing a rich and friendly UI to the user is the only objective of the UI. Select the technology that works well with the backend binding and allows you to develop some really cool GUIs and the user would certainly keep coming back for more!

So, we saw in this blog the ideal combinations of deployment technologies that can be used for each of the three primary application software platforms discussed – Web, desktop and mobile. Finally, it goes without saying that for any application to remain popular, it not only has to be technically robust, but also functionally easy and intuitive to use, and has to continuously evolve with emerging trends and technologies.

The concept of retrieving location information using GPS device and Location API is already discussed in one of the earlier post (http://www.xoriant.com/blog/mobile-application-development/location-based-programming.html ). In this article we are going to learn to use of Blackberry’s Location API and work with geocoding and reverse geocoding. Though, Geocoding and reverse Geocoding information could be used in multiple applications, a majority of applications will need to integrate the location information and display that on a Map.

To start with, let me introduce some terms:

Geocoding: is the process of finding associated geographic coordinates (often expressed as latitude and longitude) from other geographic data, such as street addresses, or zip codes (postal codes). With geographic coordinates, the features can be mapped and entered into Geographic Information Systems, or the coordinates can be embedded into media such as digital photographs via geotagging.

Reverse Geocoding: is the process of back (reverse) coding of a point location (latitude, longitude) to a readable address or place name. This permits the identification of nearby street addresses, places, and/or real subdivisions such as neighborhoods, county, state, or country. Combined with geocoding and routing services, reverse geocoding is a critical component of mobile location-based services to convert a coordinate obtained by GPS to a readable street address which is easier to understand by the end user.

Before we see the code part, let us look at the BlackBerry API (Locator) that facilitates the application to gain access to geospatial coordinates for an address and vice-versa i.e.  retrieve a street address for given coordinates in case of reverse geocoding.

Locator is a Geocoding service in BlackBerry that allows you to obtain location address for an address. This service has static method “geocode”, “reverseGeocode” and as it should be obvious by now, geocode require address and returns coordinates, reverseGeocode require coordinates and returns the address information.

There are few things to keep in mind while Locator is used in the application

1. LBS Map API is a pre-requisite for Locator API to work. Application may throw exception if the LS MAP API is not installed.
2. Call to geocode is synchronous in nature. And at any given time there should be one call made using the Locator class. Application may throw exception if more than one call is made.
3. Call to geocode and reverseGeocode should be made outside the event dispatch thread. Requests to these methods that are made on the event dispatch thread are denied and result in an exception.

Let us look how to use the Locator API to retrieve geospatial coordinates for an address using geocode.

• Packages required

import net.rim.device.api.lbs.*;
import javax.microedition.location.*;

• Create a class and constructor

public class myGeocode
{
public myGeocode()
{

}
}

• Create a private Thread variable

private Thread geocoder;

• In constructor, create instance of the Thread class. As mentioned earlier, geocode cannot be performed on the application’s primary thread.

geocoder = new Thread(thread);
geocoder.setPriority(Thread.MIN_PRIORITY);
geocoder.start();

• In the class, create a Thread that invokdes a public run() method.

Runnable thread = new Runnable() {

public void run() {

AddressInfo addrInfo = new AddressInfo();

addrInfo.setField(AddressInfo.STREET, "Whitewood Dr");

addrInfo.setField(AddressInfo.CITY, "San Jose");

addrInfo.setField(AddressInfo.STATE, "California");

addrInfo.setField(AddressInfo.POSTAL_CODE, "95110");

addrInfo.setField(AddressInfo.COUNTRY, "US");

Coordinates startCoords = new Coordinates(37.386087,-121.889244, Float.NaN);

try {

Landmark[] results = Locator.geocode(addrInfo, startCoords);

}

catch ( LocatorException lex ) {

//thrown when The BlackBerry device is not sufficiently connected to send or receive over any transport.

}

catch (MapServiceException mex) {

// if the LBS Map API is not installed on a BlackBerry device or if an application makes more than one request at a time.

}

catch (IllegalThreadStateException itex) {

// if a request is made on the event dispatch thread

}

catch(IllegalStateException isex) {

// if there is no valid radio/wi-fi connection to send the request to

}

}

};

• The new two classes used above AddressInfo and Landmark, they allow application to pass formatted address object. However, overloaded geocode also accept “String” (e.g. Whitewood Dr, San Jose, Santa Clara, California 95110). This should also work and return the array of Landmark, the first array element contains the most relevant Landmark to the locator request. May be null if geocode request is cancelled or the request fails.

• startCoords are for hint to the geocode for starting the search specified in the request. This could also be null.

• Using the same class structure, let us see how to get the address info using coordinates.

Runnable thread = new Runnable() {

public void run() {

AddressInfo addrInfo = null;

int latitude = (int)(45.423488 * 100000);

int longitude = (int)(-80.32480 * 100000);

try {

Landmark[] results = Locator.reverseGeocode

(latitude, longitude, Locator.ADDRESS );

if ( results != null && results.length > 0 )

addrInfo = results[0].getAddressInfo();

} catch ( LocatorException lex ) {

//do something

}

}

};

• Pass one of the following parameters to Locator.reverseGeocode():
  • Locator.ADDRESS: requests the nearest address or nearest street to the specified latitude/longitude
  • Locator.CITY: returns a value that is focused on the city level Development Guide Retrieve an address by using reverse geocoding 44
  • Locator.COUNTRY: returns a value that is focused on the country level
  • Locator.PROVINCE_STATE: returns a value that is focused on the province or state level

Now, we’ve seen how to use the Locator API to get geospatial and address information. When we talk about coordinates, the next thing that comes to mind is how the same code can be extended to show the location on a map.

Well, BlackBerry also has a Map API that allows us to extend the above example and use the information as is i.e. to plot the address point on a map.

• Package required

import net.rim.blackberry.api.invoke.*;
import net.rim.blackberry.api.maps.*;

• Maps is an inbuilt application in BlackBerry. This eliminates the user from writing core Map logic like displaying images, , calling Google Maps API and rendering the image in the application. All we have to do is invoke the external application (external to your application).

• Create class and constructor

public class showMap {
public showMap ()
{
}
}

• In constructor create an instance of MapView

MapView mapView = new MapView();
mapView.setLatitude(4328915);
mapView.setLongitude(-8032480);
mapView.setZoom(10);

• In the constructor, create an instance of the MapsArguments class using the MapView object as an argument. Invoke Invoke.invokeApplication() to open BlackBerry Maps and pass in the MapsArguments object.

MapsArguments mapsArgs = new MapsArguments(mapView);
Invoke.invokeApplication(Invoke.APP_TYPE_MAPS, mapsArgs);

Or you can also use the Lankmark object return by Locator.geocode

MapsArguments mapsArgs = new MapsArguments(results);
Invoke.invokeApplication(Invoke.APP_TYPE_MAPS, mapsArgs)

Location Based applications that incorporate maps are everywhere. The BlackBerry platform allows you to incorporate both location information and merge that into maps as we have seen in the blog post. It is important to note that the BlackBerry platform provide additional ways of showing a map using different inputs. You can also embed the map  within the application. What I have covered here are the basics and hope that this article highlights the important nuances that could be useful for developers to try things quickly and then extend the same by building more complex applications.

A BlackBerry phone is primarily a business phone with additional features like Email, Phone, Maps, GPS, Organizer, Social Networking and games. Developers can take advantage of various BlackBerry APIs to take the user experience to a new level. In this article, I am going to talk about BlackBerry and Location API,that allows you to develop Location based (LB) applications.

Compatibility

BlackBerry is packed with advanced features, but they are not supported in all models. Let us quickly have a glance at some of the models.

In general there are two options for using GPS with a BlackBerry. You either have a device with an internal GPS receiver, or you will need an external Bluetooth GPS receiver, which will provide the GPS data to your BlackBerry. Refer to this link to find out the models which support GPS http://na.blackberry.com/eng/devices/features/gps.jsp

Do not be disappointed if your preferred model is not the list, you can always download the simulator from https://www.blackberry.com/Downloads/entry.do

Though, the above list mentions about GPS support by default, it should also be noted that there will be existing applications developed based on JSR 179 java ME api even if the model doesn’t not have inbuilt GPS support. GPS capabilities could also be obtained by connecting to an external GPS device over Bluetooth, but this comes with its own set of challenges. Another option is for old blackberry models (RIM 857/957), which works with a serial GPS receiver attached via cable.

Overview

You must enable GPS on your device, for applications to retrieve the current location. The location is nothing but coordinates for latitude, longitude and altitude.

Additionally, support for JSR 179 Location API for Java ME comes with device software 4.0.2 and later. If you want BlackBerry extensions to JSR 179, you will need device software 5.0.0 and later.

To obtain a location via the GPS support in your device, your application has to do the following:

○   Specify the GPS mode

○   Get the location provider

○   Make GPS request

○   Retrieve the GPS location of a BlackBerry device

Code sample: Specifying the GPS mode

/* JSR 179 */
Criteria myCriteria = new Criteria();
/* JSR 179 extension */
BlackBerryCriteria myBlackBerryCriteria = new BlackBerryCriteria(…);

Dig Deep

There are three GPS modes and they have speficic properties that are described below. You will need to select one based on your application requirements.

○   Autonomous – relies on the GPS satellite only. This mode uses the GPS receiver on the BlackBerry device to retrieve location information. This mode cannot be used indoors or in close proximity to many physical obstructions, and it can take several minutes to fully synchronize with four or more satellites for the first GPS fix. An example application that can use this mode is a Car Parking Spot application.

○   Assisted Mode – GPS satellite and servers on the wireless network only. This mode uses the wireless network to retrieve satellite information. This mode can achieve a fast retrieval of the first GPS fix. An example application that can use this mode is a Nearby Restaurants application.

○    Cell site Mode – Geolocation service or the wireless network to provide on the location information of current base station. This mode uses the wireless network to achieve the first GPS fix, and is generally considered the fastest mode. This mode does not provide BlackBerry device tracking information such as the speed and the bearing. An example application that can use this mode is a Weather Application.

Let us look at the code samples to use the BlackBerry API to get location and satellite information. The code fragments are used to highlight the API rather than give a fully working GPS Application that also provides additional value added information.

First, let us look at a Java class GPSSatteliteInfo listed below. This is a utility class in which we will wrap all the GPS related sample code. The thread implementation is currently empty.

/* packages to import */
import java.util.*;
import java.lang.*;
import net.rim.device.api.gps.*;
/* create public class */
public class GPSSatelliteInfo {
	/* member variables */
	…
	public GPSSatelliteInfo() {
		gpsThread = new GPSThread(); //private thread class reference
		gpsThread.start();
	}
	/* private thread class */
	private static class GPSThread extends Thread
	{
		public void run()
		{
			//do something
		}
	}
}

○   Next, specify the GPSMode inside the run() method of Thread class

BlackBerryCriteria myCriteria = new BlackBerryCriteria(GPSInfo.GPS_MODE_AUTONOMOUS);
//OR  to be on safer side
BlackBerryCriteria myCriteria = new BlackBerryCriteria();
if (GPSInfo.isGPSModeAvailable(GPSInfo.GPS_MODE_ASSIST))
	myCriteria.setMode(GPSInfo.GPS_MODE_ASSIST);
else if (GPSInfo.isGPSModeAvailable(GPSInfo.GPS_MODE_AUTONOMOUS))
	myCriteria.setMode(GPSInfo.GPS_MODE_AUTONOMOUS);

○   Next, get the LocationProvider and create a BlackBerryLocation object to retrieve the GPS fix including a 300 second timeout expiry.

BlackBerryLocationProvider myProvider;
myProvider  = (BlackBerryLocationProvider) LocationProvider.getInstance(myCriteria);
BlackBerryLocation myLocation;
myLocation = (BlackBerryLocation) myProvider.getLocation(300);

○   Retrieve the satellite information

satCount  = myLocation.getSatelliteCount();
signalQuality  = myLocation.getAverageSatelliteSignalQuality();
dataSource  = myLocation.getDataSource();
gpsMode  = myLocation.getGPSMode();
SatelliteInfo si;
StringBuffer sb = new StringBuffer("[Id:SQ:E:A]\n");
String separator = ":";
for( Enumeration infoEnum  = myLocation.getSatelliteInfo(); infoEnum != null; infoEnum.hasMoreElements();){
	si = (SatelliteInfo)e.nextElement();
	sb.append(si.getId() + separator);
	sb.append(si.getSignalQuality() + separator);
	sb.append(si.getElevation() + separator);
	sb.append(si.getAzimuth());
	sb.append('\n');
}

Note:The assisted mode can be used with BlackBerry devices that are associated with a CDMA network that utilizes PDE server technology. The assisted mode is designed to provide fast retrieval of a GPS fix. Assisted GPS capabilities are currently defined by wireless service providers. In many instances, you must enter into a formal relationship with wireless service providers before you can connect to their PDE server.

if ( !GPSInfo.isGPSModeAvailable(GPSInfo.GPS_MODE_ASSIST) || !GPSSettings.isPDEInfoRequired(GPSInfo.GPS_MODE_ASSIST))
	return;

On similar lines, let us see how to retrieve location information.

static double lat, lon;
static float alt, spd, crs;
lat = myLocation.getQualifiedCoordinates().getLatitude();
lon = myLocation.getQualifiedCoordinates().getLongitude();
alt = myLocation.getQualifiedCoordinates().getAltitude();
spd = myLocation.getSpeed();
crs = myLocation.getCourse();

This covers how to retrieve satellite information and location coordinates.

However, there is a lot more that an application should do to provide a good user experience. Majority of times it is driven by the kind of application being developed. For example, if the application is designed to display my location on a map at a given time, then retrieving GPS location one time should suffice. But, at the same time, if the application is designed to keep retrieving the GPS coordinates as person moves some distance, then something more needs to be done. One way is to use the  setLocationListener() by passing the interval value, timeout value, and maximum age as parameters to add a LocationListener.)

myProvider.setLocationListener(new handleGPSListener(), 10, -1, -1);

In the class, implement the LocationListener interface. Implement the basic framework for the locationUpdated () method, and the providerStateChanged() method.

public static class handleGPSListener implements LocationListener
{
	public void locationUpdated(LocationProvider provider, Location location)
	{
		if (location.isValid())
		{...}
		else
		{... }
	}
	public void providerStateChanged(LocationProvider provider,	int newState)
	{
		if (newState == LocationProvider.AVAILABLE)
		{...}
		else if (newState == LocationProvider.OUT_OF_SERVICE)
		{...}
		else if (newState == LocationProvider.TEMPORARILY_UNAVAILABLE )
		{...}
	}
}

This gets invoked at a fixed interval to any location changes. This is ideal for application that is plotting user movement over a map. (Similar to the GPS navigation device to get directions).

We have now covered how to use the BlackBerry JSR 179 extension (aka GPS API) to get satellite and location coordinates. The code covered so far provides a basic working example to retrieve the satellite and location information. The same could be extended to  make complex applications. There are other areas which are “good to know” like GPS error code, Location error codes, control the power consumption, preferred response time, manage cost allowed, setting the failover mode (fall back on other available options if one is not available), etc and the reader is advised to refer to the available documentation.

Location Based Services and applications are growing in importance. The BlackBerry platform provides good support for you to get started with building location based applications today. In future posts, we shall delve into deeper topics that help you to take advantage of the full range of BlackBerry location based APIs.