Making Applications aware of their Mobile Contexts using the Intel® Mobile Platform SDK

This article provides an overview of the Mobile Platform SDK, as well as several code examples showing how to add power and connectivity awareness to your applications.

Mobile platforms such as laptops, Ultra mobile PCs (UMPCs), personal digital assistants (PDAs), and smart phones are rapidly becoming an integral part of the IT infrastructure of any thriving business. Users of the need their business applications to function on the road as well as in their offices. As a consequence, developers face the challenging task of extending existing applications across multiple platforms to handle the needs of users in this mobile computing environment.

The Intel® Mobile Platform Software Development Kit (Intel® Mobile Platform SDK) simplifies the task of adapting an application for use in a mobile environment. It provides a set of libraries, runtime components, and programming interfaces that is common across supported platforms and runtimes, to enable the developer to quickly and efficiently deliver applications with mobility features while maximizing code reuse. In the v1.2 open source release of the SDK, platform support and information models have been enhanced and expanded.

Users of mobile devices are maturing. Instead of putting up with devices that only work for a limited amount of time in limited environments, users have come to expect a lot more:

• Work offline – Users can access locally stored data and continue working when disconnected from the network and then resynchronize data between their device and the server when they reconnect.
• Transparent connection management – Users want to focus on their core tasks rather than managing connections to one or more networks.
• Effective balance of power and performance – Users expect to get the most from their device's available battery life.

There are two significant challenges that developers face when creating new or extending existing mobile applications:

• Creating applications that are aware of platform context and resources and that can efficiently adapt when changes occur is a new paradigm, and not well supported by current software solutions.
• Developing cross-platform, cross-runtime solutions to allow applications to be deployed across multiple clients is challenging, given that there is no standard way to implement this functionality across a wide range of devices.

When an application is aware of its platform context, features may be added that enable the application to respond to environmental changes based on user preferences. For example, on a laptop system, a user may select an option specifying the behavior of a virus scanner application to be optimized for performance when connected to external power and tuned to save power when running on batteries. When the laptop is disconnected from its external power source, the virus scanner pauses its background execution to conser ve battery power. It then resumes the scan when the power source is reconnected. Similar examples can be applied to changes in network connection state, network bandwidth, display resolution, available disk space, available memory, computing power, and overall platform status such as suspend mode and hibernate mode.

Mobilizing an application from the ground up—making the application context aware—can be a daunting task, requiring extensive coding and testing. Ideally, new mobile features should be developed in such a way that one set of code can be used across many platforms. By using a common programming interface with consistent object models, naming conventions, and parameters across the programming languages used, developers can minimize code differences across platforms. Such an interface allows applications to be deployed natively on different platforms without extensive recoding, and can be found in the Intel Mobile Platform SDK.

The Intel® Mobile Platform SDK provides you with the technology to address all these challenges and make your applications mobile-aware. Of particular importance are SDK features that support developing mobile applications that can run on multiple platforms and in various runtime environments.

Another important feature is the ability to make applications aware of and adapt to changes in platform context and resources, so they can efficiently adjust to take advantage of the capabilities of the platform. Runtime components included in the SDK monitor and provide notification of context changes, allowing the application to respond to these changes programmatically in real-time. This feature enables ISVs and users to specify and control the way a mobile platform reacts to changes in context.

The Intel Mobile Platform SDK includes an information programming model, development libraries, redistributable runtime components, a Programmer’s Guide, many code samples and testing utilities. As this is an open source project, all the source code is available too. Three programming interface bindings are supported in the SDK:

• C++ interface for native applications
• Sun Microsystems Java*
• Microsoft .NET* CLR

The Intel Mobile Platform SDK’s programming interface and information model is consistent across all the supported languages and platforms. This programming model includes:

• Classes, instances, properties, methods – This set of classes represent system devices and capabilities, referred to as “context information” which is a change with the v1.2 release. Instances of these classes describe and control devices on the platform using properties and methods.
• Events and threshold notifications – Events notify applications when a state change occurs. For example, an application can register to be informed when the system goes on battery power. When this event occurs, the runtime executes a callback routine to notify the application, which can then respond in real-time. For example, the application may be programmed to go into a power-optimized mode to conserve power when the system goes on battery power. Event notification may also be tied to a boundary condition, such as when the battery level drops below 50%.
• Collections and enumeration – These classes assist in the discovery of the devices on the system and allow enumeration when multiple instances of a device are present.

Let’s look at the features of SDK before diving into a few code samples.

Several examples below introduce some of the devices and capabilities in the Intel® Mobile Platform SDK and show how they were used to enable an application to modify its behavior to optimize its use of system power. The SDK exposes a set of devices and capabilities that can be used to solve a range of problems faced by mobile users. Let’s look at the devices, contexts and runtimes supported by the SDK.

Devices

The SDK’s device object model allows applications to determine the status of a device. The v1.2 SDK supports the following devices:

• Battery – Used to access information about a battery in the system, such as percent charge, life remaining, and manufacturer’s serial number.
• DisplayAdapter – Used to access information about the display adapter. It includes information such as the manufacturer as well as the color depth, resolution and refresh rate.
• LinkProtocol – Used to describe the link protocols running on the system, such as IEEE 802.3, 802.11abg*, and to monitor the state of network connections. LinkProtocol is a logical device associated with the NetworkAdapter device.
• NetworkAdapter – Used to describe the network adapters currently available in the system, such as 802.3 (Ethernet), 802.11 (WiFi) and Bluetooth PAN*, GPRS/CDMA (WWAN).
• LogicalDisk – Used to access information about the logical disks, both local and remote, on the system. It includes format and location of the logical disk as well as the amount of total and free storage capacity it contains.
• Memory – Used to access information about the RAM on the system used for application execution.
• PhysicalDisk – Used to access information about the physical disks attached to the system. It includes information such as manufacturer and model as well as the size of the disk.
• Platform – Used to access information about the system platform, such as when the system enters suspend mode or hibernate mode or shutdown.
• Processor – Used to access information about the system microprocessor, such as the manufacturer, the current processor frequency, and whether Intel® Streaming SIMD Extensions 2 (SSE2) or Intel® Streaming SIMD Extensions 3 (SSE3) are supported. This device also supports multi-core and Hyper-Threading Technology enabled processors by providing information about each core and each logical processor.
• RFID reader – Used to enable the system to read data from and write data to RFID tags. This capability can be used in many different ways, such as, validating a system user, identifying a person for medical treatment, inventory control and location detection when tags are at a fixed point.

Contexts

A context layer provides aggregate information about all the devices on a system. For example, if a system has two batteries, the Power context can be used to determine the average charge remaining in the two individual batteries. If one battery is at 90% charge and the other at 100%, the Power context will report the aggregate charge as 95%. The v1.2 SDK supports the following context objects:

• Bandwidth – Used to monitor and control the network bandwidth of the system, application process, and network sessions.
• Connectivity – Used to access system connectivity information, such as whether the system has at least one valid network interface connected to a network or whether a remote host is reachable. This context object also notifies applications via events when the system loses network connectivity and when it regains it.
• Display – Used to provide information about the overall display of the system by aggregating the DisplayAdapter information. It includes information such as the color depth, horizontal and vertical resolution.
• Power – Used to access information about system power, such as the system power source (battery or external AC) and the aggregated system battery charge.
• Storage – Used to provide information about persistent storage space, i.e., disk space, and memory on the system. Also includes the ability to determine how much space is available for a given folder which is useful when installing software or creating a data store at a specific location.

Supported Runtime Environments

The Intel® Mobile Platform SDK v1.2is supported on the following operating systems:

• Microsoft Windows* XP Professional
• Microsoft Windows* Vista Business/Ultimate Edition
• Microsoft Windows* Tablet PC Edition 2005
• Microsoft Windows* Mobile Edition 2003 for Pocket PC Platforms
• Microsoft Windows* Mobile Edition 2003 for Smartphone Platforms
• Microsoft Windows* Mobile Edition 5.0 for Pocket PC Platforms
• Microsoft Windows* Mobile Edition 5.0 for Smartphone Platforms

Besides all the OSs listed above being supported in current version, we are also considering the Linux version of the SDK.

All runtime environments support programming interfaces for C++, Java, and .NET, except for Microsoft Windows Mobile Edition 2003 and Mobile Edition 5.0 for Smartphone which supports only C++ and .NET.

The Intel® Mobile Platform SDK v1.2 package contains the following directories and files:

• Docs – Contains the Programmer’s Guide, release notes, and Quick Start Guide.
• Projects – Contains development environment including solution and project files. For backwards compatibility it also contains libraries that can be linked with applications developed and link with version 1.1 of the SDK.
• Tools – Contains several tools to use for different platforms:
  • Information Viewers – Two sample applications, one written in Java and the other in C#, that demonstrate features of the SDK such as:
    • Enumerating the devices on a system and viewing their properties.
    • Regi stering to be notified of an event and viewing the notification reported when the event occurs.
      
      You can use the information viewers as a validation tool to compare results to those returned by your implementation which calls the Intel® Mobile Platform APIs.
  • Intel® Mobile Bandwidth GUI – This utility provides a graphical user interface to view the status of and manage network bandwidth usage on an individual system. Online help is accessible from the interface.
• Bin – Contains the Intel® Mobile Platform SDK run-time libraries, and setup scripts.
• Src – contains source files of framework, provider and binding, etc.
• Samples – contains sample code to demo how to program with the API

The following section includes examples of how the Intel® Mobile Platform SDK can be used to detect system power and connection status. It also provides an example of multithreading a workload on a multi-core system. If you are looking for sample code that can help, see the SDK’s Samples directory that contains examples in C++, Java* and C#.

Example #1 – Power Awareness
An application that hasn’t been designed for use in a mobile environment may exhibit behaviors frustrating for a user. For example, it may use excessive power when the system is running on battery, decreasing the time the system can run between charges. It may also attempt long-running (such as burning a CD or DVD) or power-intensive operations when the power level is low. The application example below shows how you can use the Intel Mobile Platform SDK to optimize an application’s use of power by pausing non-critical processes when the system is running on battery power.

Problem Statement: An application is not optimized to conserve system power. You would like to add the capability to the application to turn off processing of non-critical functions when the system is on battery power and to resume processing these functions when the system is connected to external AC power. For efficiency, you want to add this functionality without polling the OS for the power connection status.

Using the SDK to Solve the Problem

The power context provided in the Intel Mobile Platform SDK provides information about the system power. The following features of the Power context will be used in the solution to this problem:

• Source property – The values of the Source property are External and Internal.
• Events – The two Power events that will be monitored are InternallyPowered and ExternallyPowered.

To solve this problem, you could incorporate the following functionality into your application:

1. Register for events that indicate the system power source has changed.
2. At application startup, check the system connection status to determine if the application should initially be put in the low power mode or in the high performance mode.
3. Respond appropriately when notification of an event is received.
   • For an InternallyPowered event, pause all optional, non-critical proce sses, such as a background virus check or automatic word processor spell checking.
   • For an ExternallyPowered event, resume processing of optional, non-critical processes that have been paused.
4. At application shutdown, unregister events and free allocated memory.

The next section will describe in detail how the SDK API is used to implement this solution.

Approach

The procedure below provides details about how you can incorporate code into an application to optimize its use of system power.

Step 1:

1. In the project that will use the Intel Mobile Platform SDK, reference the appropriate header file and .lib file.
   • Add the header files directory to the include path for the project. By default this is: "$MPSDKProjectsWin32VS2003BindingC++inc".
   • At the top of source files add:

#include "IntelMobileCPP.h"

#include "ContextContextClassObject.h"

#include "ContextPowerInstanceObject.h"

using namespace Intel::Mobile::Base;

using namespace Intel::Mobile::Context;

• • Add the lib files directory to the project lib path. By default this is: "$MPSDKProjectsWin32VS2003BindingC++lib".
  • Add the following to the linker input:

IntelMobileCPP12.lib
ContextCPP12.lib

Step 2:

1. Add an initialization routine to run at application start-up that includes the following functions:
   • Create a pointer to the PowerInstance object and initialize it. The PowerInstance object will be used throughout the life of the process to obtain information and receive notification of events related to power.

PowerInstance* pMyPowerInstance;

ContextClass MyClass;

pMyPowerInstance = dynamic_cast<PowerInstance*>

( MyClass.GetInstance(L"Power") ); 

• Get values describing the current status of the system power, such as the power source currently being used (battery or external AC) and the percent of the system battery power remaining.
  
  The IsNull() method is used in the code below to ensure that a particular feature is supported on the running platform.

unsigned int PowerInfo::GetPowerLevel()

{

try

{

if (pMyPowerInstance != NULL)

{

if (!pMyPowerInstance->PercentRemaining.IsNull())

{

unsigned __int32 value = pMyPowerInstance->

PercentRemaining.GetValue();

return value;

}

}

}

catch (IntelMobileException& ex)

{

//Handle Exception here

ASSERT(0);

}



return 0;

}



CString PowerInfo::GetPowerSource()

{

CString rv = _T("Unknown");



try

{

if (pMyPowerInstance != NULL)

{

if (!pMyPowerInstance->Source.IsNull())

{

SourceEnum value = pMyPowerInstance->Source.GetValue();

rv = value.ToString();

}

}

}

catch (IntelMobileException& ex)

{

//Handle Exception here

ASSERT(0);

}



return rv;

}

• Define an Observer class called PowerObserver. An instance of this class will be registered to handle events. (See step 3 for how this class is implemented.)

#include "Basease_Event.h"

#include "Basease_Observer.h"

using namespace Intel::Mobile::Base;

class PowerObserver : public Observer

{

public:

void Notify( const Event& event);

void SetDialogPtr(CDialog *DialogPtr);  

private:

CDialog *MyUIDialog;

//Used to update the user interface

};

• Register an instance of the PowerObserver class called MyPowerObserver to be informed of power related events. In the code example below, MyPowerObserver is being registered for the ExternalPower, InternalPower and StatusChange events.

void PowerInfo::RegisterObserver()

{

assert(pMyPowerInstance != NULL);

pMyPowerInstance->ExternallyPowered.AddObserver(MyPowerObserver);

pMyPowerInstance->InternallyPowered.AddObserver(MyPowerObserver);

pMyPowerInstance->StatusChanged.AddObserver(MyPowerObserver);

}

Step 3:

• Add an event handler to receive notification of power-related changes in the system. In the code example below, three events are handled: a change to AC power (external), a change to battery power (internal), and a change in battery level. In this simplified example, the response is to post WM_PAINT, causing the main dialog box to update.
  
  A more typical event handler for power events would respond to an event by changing the behavior of the application to optimize power use, such as turning off background processing when the system goes to battery power and turning it back on when AC power is reconnected.
  
  The notify method is called on a separate thread. Therefore, anytime the notify function is used to update shared data, critical sections must be implemented in the code to protect the shared data. Critical sections were not used in the simple code example below, but would be required for most applications.

#include "stdafx.h"

#include "PowerObserver.h"

#include "IntelMobileCPP.h"

using namespace Intel::Mobile::Base;

using namespace Intel::Mobile::Context;

void PowerObserver::Notify(const Event& event)

{

try

{

switch (event.GetType())

{

case Event::eExternallyPowered:

OutputDebugString(_T("ExternallyPowered Event received"));

MyUIDialog->PostMessage(WM_PAINT);

//Tell the main dialog to repaint

break;

case Event::eInternallyPowered:

OutputDebugString(_T("InternallyPowered Event received"));

MyUIDialog->PostMessage(WM_PAINT);

//Tell the main dialog to repaint

break;

case Event::eStatusChange:

OutputDebugString(_T("StatusChanged Event received"));

MyUIDialog->PostMessage(WM_PAINT);

//Tell the main dialog to repaint.

break;

}

}

catch (IntelMobileException& ex)

{

OutputDebugString(_T("IntelMobileException exception caught!!!"));

}

}

Step 4:

• Add a cleanup routine to run at shutdown to unregister observers for power-related events and remove them.

void PowerInfo::UnregisterObserver()

{

assert(pMyPowerInstance != NULL);

pMyPowerInstance->ExternallyPowered.RemoveObserver(MyPowerObserver);

pMyPowerInstance->InternallyPowered.RemoveObserver(MyPowerObserver);

pMyPowerInstance->StatusChanged.RemoveObserver(MyPowerObserver);

}

A this point the project can compile and run. While the application is running, unplug the AC adaptor from your laptop to see the status change from “External” to “Internal”. Plug it back in and see it change back to “External”. If left unplugged, the “Power Level” will change because each time the value decreases the StatusChanged event will be trigged causing the application to get the new value. Now that the application “knows” the power state of the system, it can be designed to include lots of features when on AC power, but to throttle back as appropriate when on battery power.

An application that hasn’t been designed for use on a system with multiple cores would only take advantage of one core at any given time. With the release of multi-core CPUs on mobile systems as well as on desktop and server systems, the processing capacity has effectively doubled. For example, a single-threaded application can be redesigned to be a multithreaded application such that it runs in multithreaded mode when on a multi-core system. Doing so allows an application to get more done in a shorter amount of time. The application below shows how you can dynamically create threads to match the number of cores on the system using the Intel® Mobile Platform SDK.

Problem Statement: An application is single-threaded and will be multithreaded to take advantage of multi-core CPUs. Furthermore, the application should dynamically adapt to the number of cores on the system as the number of cores in future processors will likely increase.

Using the SDK to Solve the Problem

The ProcessorClass, ProcessorCollection, and ProcessorInstance objects provided in the Intel Mobile Platform SDK accesses information about the system processor or processors. The following features of these objects will be used in the solution to this problem:

• ProcessorClass GetInstances() method – Returns a collection of the processors on the system.
• ProcessorCollection HasNext(), and Next() methods - Provide a means for enumerating through a collection of objects.
• ProcessorInstance CoreCount Property – Provides the number of cores for each processor.

To solve this problem, you could:

1. At application startup, create a ProcessorClass object.
2. Using the ProcessorClass get a ProcessorCollection object.
3. Use the ProcessorCollection object to enumerate through the ProcessorInstance objects.
4. For each ProcessorInstance object call GetValue() for the CoreCount property.
5. With the core count value in hand, subdivide the workload into equal parts and assign each thread to work on each part. Watch out for thread synchronization issues that might arise.

The next section will describe in detail how components of the SDK are used to implement this solution.

Approach

The description below provides details about how you can incorporate code into a C++ application to optimize the use of the multiple cores on the system.

Step 1:

In the project that will use the Intel Mobile Platform SDK, reference the appropriate header file and .lib file.

• Add the header files directory to the include path for the project. By default this is: "$MPSDKProjectsWin32VS2003BindingC++inc ".
• At the top of source files add:

#include "IntelMobileCPP.h"

#include "ProcessorProcessorClassObject.h"

using namespace Intel::Mobile::Processor;

• Add the lib files directory to the project lib path. By default this is: "C:Program FilesIntelIntel(R) Mobile Platform SDK 1.1DevelopmentC++lib".
• Add the following to the linker input:

IntelMobileCPP12.lib

ProcessorCPP12.lib

Step 2:

• Add a routine to run at application start-up that gets the number of cores on the system. This only needs to happen once if it is stored in a variable accessible by the parts of the application that need it.

unsigned GetCoreCount()

{

unsigned CoreCount = 0;

ProcessorCollection* pMyCollection = NULL;

ProcessorInstance* pMyInstance = NULL;

//Use try catch blocks to handle exceptions that could be thrown

//  by the Intel® Mobile Platform Runtime

try

{

//Get a collection of processors

ProcessorClass MyClass;

pMyCollection = 

dynamic_cast<ProcessorCollection*>(MyClass.GetInstances());

//Enumerate through the processors

while (pMyCollection->HasNext())

{

pMyInstance = 

dynamic_cast<ProcessorInstance*>(pMyCollection->Next());

//Check and make sure there is data available

if ( !pMyInstance->CoreCount.IsNull() )

{

//Get the value.  Add to CoreCount should there 

//   be more than one CPU

CoreCount += pMyInstance->CoreCount.GetValue();

}

delete pMyInstance;

pMyInstance = NULL;

}

}

catch (IntelMobileException& ex)

{

wprintf( L"

------------ Exception Occurred ------------ 

" );

;

wprintf( L"Message: %s", ex.GetGeneralMessage().GetValue() );

wprintf( L"Source: %s", ex.GetSource().GetValue() );

wprintf( L"Target Site: %s", ex.GetTargetSite().GetValue() );

wprintf( L"Error Code: %s", ex.GetErrorCode().GetValue() );

wprintf( L"Detailed Error Info: %s", ex.GetDetailErrorInfo().GetValue() );

}

catch ( ... )

{

wprintf( L"

------------ Exception Occurred ------------ 

" );

}

//Clean up objects created earlier

if ( pMyInstance ) 

delete pMyInstance;

if ( pMyCollection ) 

delete pMyCollection;

return CoreCount;

//Return the final count of cores

}

Step 3:

• Now that the application is aware of the number of cores on the system, the workload needs to be subdivided into a number of tasks that can be handled by each thread. The way this is done may vary between applications. In the sample application provided, the ThreadWorkloads array is allocated dynamically and the workload for each thread is computed to evenly distribute the workload.

//Determine a workload that is uniformly distributed between threads

int *ThreadWorkloads;

ThreadWorkloads = new int[CoreCount];

memset(ThreadWorkloads, 0, sizeof(int) * CoreCount); 

for (int i=0; i < TotalNum; i++)

ThreadWorkloads[i % CoreCount]++;

Step 4:

• Thread specific data structures, such as thread handles and thread parameters, are created dynamically since the number of threads is not known in advance.

HANDLE *hThreads = new HANDLE[CoreCount];

memset(hThreads, 0, sizeof(HANDLE) * CoreCount);

ThreadData_Struct *ThreadData = new ThreadData_Struct[CoreCount];

memset(ThreadData, 0, sizeof(ThreadData_Struct) * CoreCount);

Step 5:

• At this point write the code to create the threads. Each one is passed its unique parameters which indicate which workload to process.

int CurrentValue = StartNum;

for (unsigned i=0; i<CoreCount; i++)

{

ThreadData[i].BeginValue = CurrentValue;

ThreadData[i].EndValue = CurrentValue + ThreadWorkloads[i] - 1;

hThreads[i] = CreateThread(              NULL, 0, ThreadFunc,

&ThreadData[i], 0, &dwThreadId);

if (hThreads[i] == NULL) 

{

printf( "CreateThread failed (%d)!", GetLastError() );

printf( "Processes Aborted");

break;

}

CurrentValue += ThreadWorkloads[i];

}

Step 6:

• Finally, the main thread blocks and waits for the worker threads to complete their assigned workloads. For purposes of the sample application, this allows the application to calculate the total elapsed time for the calculations and to also wait and clean up after the threads are done.

//Wait for all the threads to exit 

WaitForMultipleObjects(CoreCount, hThreads, TRUE, INFINITE);

//Clean up 

for (unsigned i=0; i<CoreCount; i++) 

if (hThreads[i] != NULL) 

CloseHandle(hThreads[i]); 

delete[] hThreads; 

delete[] ThreadData; 

delete[] ThreadWorkloads; 

printf("Elapsed time: %u msec", GetTickCount() - StartTime);

At this point the project will compile and run. While the application is running, you should see the results from the single threaded implementation and then the results from the multithreaded implementation. If run on a system using dual-core technology such as the Intel® Centrino® Duo mobile technology, the multithreaded results should be about twice as fast as the single threaded results.

A distributed application that hasn’t been designed with intermittent networking in mind will likely prove to be problematic for the mobile platform user. For example, when the system is unexpectedly disconnected from the network, applications that expect a constant connection to remote resources will at best throw error messages and at worst unexpectedly terminate or put the entire system into an unstable state. Distributed applications that can run in offline mode but don’t have the ability to detect and adapt to network status changes will require some kind of user intervention in order to return to online mode, be it a restart of the application or the manual initiation of the client-server synchronization process. In a truly mobile application, software deals with network disconnects and reconnects seamlessly, requires no user intervention, and unobtrusively notifies the user of the change in state.

Problem Statement: An application that hasn’t been designed for mobility shows strange error messages and other abnormal behaviors when the client is disconnected from the server. The application must be restarted after the client is reconnected. You would like to add the capability to the application to enable it to handle network disconnections and reconnections seamlessly.

Using the SDK to Solve the Proble m

The ConnectivityInstance object provided in the Intel® Mobile Platform SDK is part of the context information layer which abstracts and aggregates information from all the network devices on the system. The following features of this object will be used in the solution to this problem:

• IpAddressChanged event – This event is generated whenever there is a change in the system IP Address table.
• RouteTableChanged event – This event is generated whenever there is a change in the system route table.
• IsReachable() method – This method allows the caller to determine whether or not a specific network location or service is available.

Approach

A sample application has not been provided for this example, but sample code relating to the ConnectivityInstance object is provided in the development directory of the SDK. See the following projects in the sample code: ConnectivitySample, DisconnectEventSample and ConnectEventSample. To solve this problem, you can follow these steps.

1. Create an instance of a ConnectivityInstance object and check the current state of the connection to the network resource using the IsReachable() method. If the resource is available, run the application in a “connected” mode. If not, run the application in an “offline” mode.
2. Register for the IpAddressChanged and/or RouteTableChanged events. At startup, the application registers an observer for the events so that it will be notified of a change in the network routing and IP Address tables. The Connectivity context object is used to monitor the state of network connections. When Dynamic Host Configuration Protocol (DHCP) is being used and a network adapter on the system is either reconnected or disconnected, the IpAddressChange event is triggered when an IP address has been assigned. The RouteTableChanged event is fired whenever there is a change in network connectivity and may be a better indicator of network state change when DHCP is not used.
3. Modify your application to react to changes in the network connection state. The most important thing is to determine whether the change in network state is relevant. For example, while the user may have just connected to a network and been assigned an IP Address by a DHCP server, the network may not be the same network where the remote resource resides. In order to determine whether the change in network status is relevant, call one of the IsReachable() methods with the path to the network service as a parameter. If the call to IsReachable() returns false, depending on the previous state, the software should change to or continue to function in an offline mode (e.g., local data cache should be used). Conversely, if the call to IsReachable() returns true, depending on the previous state, the application may switch to or continue in an online mode (e.g., local data synchronized with remote data store).
4. Add features to your application to unobtrusively let the user know when the network connection state changes. For example, the application could display a message such as “The network has been disconnected. The data you are using has been saved locall y.” Or you could incorporate a status bar icon into your application that shows when the application is operating offline.
5. Add a shutdown procedure to the application to unregister for the observer object for the RouteTableChanged and IpAddressChanged events when the application shuts down.

As users increasingly turn to mobile platforms, software developers must modify their application to deal with resource and context changes. Adding mobile features to your applications will provide users with consistent application behavior optimized for a mobile environment.

As this article shows, the Intel® Mobile Platform SDK helps you add mobile features to your applications while reducing development time and maximizing code reuse. The SDK provides:

• Multi-platform/multi-runtime support
• A common, consistent programming interface that provides access to key capabilities needed by mobile applications
• The ability to easily provide context awareness to applications

For additional information, you can access the Intel Mobile Platform SDK open source project at:

• Intel Mobile Platform SDK
• http://sourceforge.net/projects/mpsdk

The overall effort of the v1.2 release of the Intel® Mobile Platform SDK was to primarily extend the platform support and to increase the richness of the information that it provides, however other improvements were made as well. The following is a list of enhancements over the v1.1 release.

• RFID/GPRS/CDMA only has the binding interface, no corresponding providers are supported in 1.2 open source version.
• Additional development environment are supported, including Microsoft Visual Studio* 2005, and .NET Framework 2.0.
• The package includes Intel® Mobile Platform Provider Development Kit, which enables you to develop plug-in modules for your own devices.
• Improved the performance by avoiding the multiple mobile servers co-existing in the system
• Supports linkage with different C runtime libraries, not only the dynamically loadable libraries (/MD and /MDd compiler options), but also the static libraries (/MT and /MTd compiler options).
• Detection of Intel® Virtualization Technology is supported.
• Detection of Intel® Centrino® processor technology is supported.

For more complete information about compiler optimizations, see our Optimization Notice.

Comments (1)

May 5, 2009 12:22 PM PDT southsidesmoka Total Points: 1,139 Brown Belt

I was unsure about how to go about implementing the Mobile SDK in my application - or should we say "mobilizing" it. This article has given me insight and thus I've perceived the perfect context for some of those handy Mobile SDK classes. Very thorough documentation on the subject of application mobilization.

Trackbacks (0)

Leave a comment