Buzzdev.org

Written by:
Igor Darkov, Software Developer of Device Team, Apriorit Inc.

In this article I’ve described:

How to develop simple Java service for the Android Devices; How to communicate with a service from the other processes and a remote PC; How to install and start the service remotely from the PC. 1. Java Service Development for the Android Devices

Services are long running background processes provided by Android. They could be used for background tasks execution. Tasks can be different: background calculations, backup procedures, internet communications, etc. Services can be started on the system requests and they can communicate with other processes using the Android IPC channels technology. The Android system can control the service lifecycle depending on the client requests, memory and CPU usage. Note that the service has lower priority than any process which is visible for the user.

Let’s develop the simple example service. It will show scheduled and requested notifications to user. Service should be managed using the service request, communicated from the simple Android Activity and from the PC.

First we need to install and prepare environment:

Download and install latest Android SDK from the official web site (http://developer.android.com); Download and install Eclipse IDE (http://www.eclipse.org/downloads/); Also we’ll need to install Android Development Tools (ADT) plug-in for Eclipse.

After the environment is prepared we can create Eclipse Android project. It will include sources, resources, generated files and the Android manifest.

1.1 Service class development

First of all we need to implement service class. It should be inherited from the android.app.Service (http://developer.android.com/reference/android/app/Service.html) base class. Each service class must have the corresponding <service> declaration in its package’s manifest. Manifest declaration will be described later. Services, like the other application objects, run in the main thread of their hosting process. If you need to do some intensive work, you should do it in another thread.

In the service class we should implement abstract method onBind. Also we override some other methods:

onCreate(). It is called by the system when the service is created at the first time. Usually this method is used to initialize service resources. In our case the binder, task and timer objects are created. Also notification is send to the user and to the system log: public void onCreate() { super.onCreate(); Log.d(LOG_TAG, “Creating service”); showNotification(“Creating NotifyService”); binder = new NotifyServiceBinder(handler, notificator); task = new NotifyTask(handler, notificator); timer = new Timer(); } onStart(Intent intent, int startId). It is called by the system every time a client explicitly starts the service by calling startService(Intent), providing the arguments it requires and the unique integer token representing the start request. We can launch background threads, schedule tasks and perform other startup operations. public void onStart(Intent intent, int startId) { super.onStart(intent, startId); Log.d(LOG_TAG, “Starting service”); showNotification(“Starting NotifyService”); timer.scheduleAtFixedRate(task, Calendar.getInstance().getTime(), 30000); } onDestroy(). It is called by the system to notify a Service that it is no longer used and is being removed. Here we should perform all operations before service is stopped. In our case we will stop all scheduled timer tasks. public void onDestroy() { super.onDestroy(); Log.d(LOG_TAG, “Stopping service”); showNotification(“Stopping NotifyService”); timer.cancel(); } onBind(Intent intent). It will return the communication channel to the service. IBinder is the special base interface for a remotable object, the core part of a lightweight remote procedure call mechanism. This mechanism is designed for the high performance of in-process and cross-process calls. This interface describes the abstract protocol for interacting with a remotable object. The IBinder implementation will be described below. public IBinder onBind(Intent intent) { Log.d(LOG_TAG, “Binding service”); return binder; }

To send system log output we can use static methods of the android.util.Log class (http://developer.android.com/reference/android/util/Log.html). To browse system logs on PC you can use ADB utility command: adb logcat.

The notification feature is implemented in our service as the special runnable object. It could be used from the other threads and processes. The service class has method showNotification, which can display message to user using the Toast.makeText call. The runnable object also uses it:

public class NotificationRunnable implements Runnable { private String message = null; public void run() { if (null != message) { showNotification(message); } } public void setMessage(String message) { this.message = message; } }

Code will be executed in the service thread. To execute runnable method we can use the special object android.os.Handler. There are two main uses for the Handler: to schedule messages and runnables to be executed as some point in the future; and to place an action to be performed on a different thread than your own. Each Handler instance is associated with a single thread and that thread’s message queue. To show notification we should set message and call post() method of the Handler’s object.

1.2 IPC Service

Each application runs in its own process. Sometimes you need to pass objects between processes and call some service methods. These operations can be performed using IPC. On the Android platform, one process can not normally access the memory of another process. So they have to decompose their objects into primitives that can be understood by the operating system , and “marshall” the object across that boundary for developer.

The AIDL IPC mechanism is used in Android devices. It is interface-based, similar to COM or Corba, but is lighter . It uses a proxy class to pass values between the client and the implementation.

AIDL (Android Interface Definition Language) is an IDL language used to generate code that enables two processes on an Android-powered device to communicate using IPC. If you have the code in one process (for example, in Activity) that needs to call methods of the object in another process (for example, Service), you can use AIDL to generate code to marshall the parameters.

Service interface example showed below supports only one sendNotification call:

interface INotifyService { void sendNotification(String message); }

The IBinder interface for a remotable object is used by clients to perform IPC. Client can communicate with the service by calling Context’s bindService(). The IBinder implementation could be retrieved from the onBind method. The INotifyService interface implementation is based on the android.os.Binder class (http://developer.android.com/reference/android/os/Binder.html):

public class NotifyServiceBinder extends Binder implements INotifyService { private Handler handler = null; private NotificationRunnable notificator = null; public NotifyServiceBinder(Handler handler, NotificationRunnable notificator) { this.handler = handler; this.notificator = notificator; } public void sendNotification(String message) { if (null != notificator) { notificator.setMessage(message); handler.post(notificator); } } public IBinder asBinder() { return this; } }

As it was described above, the notifications could be send using the Handler object’s post() method call. The NotificaionRunnable object is passed as the method’s parameter.

On the client side we can request IBinder object and work with it as with the INotifyService interface.  To connect to the service the android.content.ServiceConnection interface implementation can be used. Two methods should be defined: onServiceConnected, onS

erviceDisconnected:

ServiceConnection conn = null; … conn = new ServiceConnection() { public void onServiceConnected(ComponentName name, IBinder service) { Log.d(“NotifyTest”, “onServiceConnected”); INotifyService s = (INotifyService) service; try { s.sendNotification(“Hello”); } catch (RemoteException ex) { Log.d(“NotifyTest”, “Cannot send notification”, ex); } } public void onServiceDisconnected(ComponentName name) { } };

The bindService method can be called from the client Activity context to connect to the service:

Context.bindService(new Intent(this, NotifyService.class), conn, Context.BIND_AUTO_CREATE);

The unbindService method can be called from the client Activity context to disconnect from the service:

Context.unbindService(conn); 1.3 Remote service control

Broadcasts are the way applications and system components can communicate. Also we can use broadcasts to control service from the PC. The messages are sent as Intents, and the system handles dispatching them, including starting receivers.

Intents can be broadcasted to BroadcastReceivers, allowing messaging between applications. By registering a BroadcastReceiver in application’s AndroidManifest.xml (using <receiver> tag) you can have your application’s receiver class started and called whenever someone sends you a broadcast. Activity Manager uses the IntentFilters, applications register to figure out which program should be used for a given broadcast.

Let’s develop the receiver that will start and stop notify service on request. The base class android.content.BroadcastReceiver should be used for these purposes (http://developer.android.com/reference/android/content/BroadcastReceiver.html):

public class ServiceBroadcastReceiver extends BroadcastReceiver { … private static String START_ACTION = “NotifyServiceStart”; private static String STOP_ACTION = “NotifyServiceStop”; … public void onReceive(Context context, Intent intent) { … String action = intent.getAction(); if (START_ACTION.equalsIgnoreCase(action)) { context.startService(new Intent(context, NotifyService.class)); } else if (STOP_ACTION.equalsIgnoreCase(action)) { context.stopService(new Intent(context, NotifyService.class)); } } }

To send broadcast from the client application we use the Context.sendBroadcast call. I will describe how to use receiver and send broadcasts from the PC in chapter 2.

1.4 Android Manifest

Every application must have an AndroidManifest.xml file in its root directory. The manifest contains essential information about the application to the Android system, the system must have this information before it can run any of the application’s code. The core components of an application (its activities, services, and broadcast receivers) are activated by intents. An intent is a bundle of information (an Intent object) describing a desired action — including the data to be acted upon, the category of component that should perform the action, and other pertinent instructions. Android locates an appropriate component to respond to the intent, starts the new instance of the component if one is needed, and passes it to the Intent object.

We should describe 2 components for our service:

NotifyService class is described in the <service> tag. It will not start on intent. So the intent filtering is not needed. ServiceBroadcastReceived class is described in the <receiver> tag. For the broadcast receiver the intent filter is used to select system events: <application android:icon=”@drawable/icon” android:label=”@string/app_name”> … <service android:enabled=”true” android:name=”.NotifyService” android:exported=”true”> </service> <receiver android:name=”ServiceBroadcastReceiver”> <intent-filter> <action android:name=”NotifyServiceStart”></action> <action android:name=”NotifyServiceStop”></action> </intent-filter> </receiver> … 2. Java service remote installation and start 2.1 Service installation

Services like the other applications for the Android platform can be installed from the special package with the .apk extension. Android package contains all required binary files and the manifest.

Before installing the service from the PC we should enable the USB Debugging option in the device Settings-Applications-Development menu and then connect device to PC via the USB.

On the PC side we will use the ADB utility which is available in the Android SDK tools directory. The ADB utility supports several optional command-line arguments that provide powerful features, such as copying files to and from the device. The shell command-line argument lets you connect to the phone itself and issue rudimentary shell commands.

We will use several commands:

Remote shell command execution: adb shell <command> <arguments> File send operation: adb push <local path> <remote path> Package installation operation: adb install <package>.apk

I’ll describe the package installation process in details. It consists of several steps which are performed by the ADB utility install command:

First of all the .apk package file should be copied to the device. The ADB utility connects to the device and has limited “shell” user privileges. So almost all file system directories are write-protected for it. The /data/local/tmp directory is used as the temporary storage for package files. To copy package to the device use the command: adb push NotifyService.apk /data/local/tmp Package installation. ADB utility uses special shell command to perform this operation. The “pm” (Package Manager?) utility is present on the Android devices. It supports several command line parameters which are described in the Appendix I. To install the package by yourself execute the remote shell command: adb shell pm install /data/local/tmp/NotifyService.apk Cleanup. After the package is installed, ADB removes the temporary file stored in /data/local/tmp folder using the “rm” utility: adb shell rm /data/local/tmp/NotifyService.apk. To uninstall package use the “pm” utility: adb shell pm uninstall <package> 2.2 Remote service control

To be able to start and stop the NotifyService from the PC we can use the “am” (Activity Manager?) utility which is present on the Android device. The command line parameters are described in the Appendix II. The “am” utility can send system broadcast intents. Our service has the broadcast receiver which will be launched by the system request.

To start NotifyService we can execute remote shell command:

adb shell am broadcast –a NotifyServiceStart

To stop the NotifyService we can execute remote shell command:

adb shell am broadcast –a NotifyServiceStop

Note, that the NotifyServiceStart and NotifyServiceStop intents were described in the manifest file inside the <receiver> … <intent-filter> tag. Other requests will not start the receiver.

Appendix I. PM Usage (from Android console) pm [list|path|install|uninstall] pm list packages [-f] pm list permission-groups pm list permissions [-g] [-f] [-d] [-u] [GROUP] pm path PACKAGE pm install [-l] [-r] PATH pm uninstall [-k] PACKAGE The list packages command prints all packages. Use the -f option to see their associated file. The list permission-groups command prints all known permission groups. The list permissions command prints all known permissions, optionally only those in GROUP. Use the -g option to organize by group. Use the -f option to print all information. Use the -s option for a short summary. Use the -d option to only list dangerous permissions. Use the -u option to list only the permissions users will see. The path command prints the path to the .apk of a package. The install command installs a package to the system. Use the -l option to install the package with FORWARD_LOCK. Use the -r option to reinstall an exisiting app, keeping its data. The uninstall command removes a package from the system. Use the -k option
to keep the data and cache directories around after the package removal. Appendix II. AM Usage (from Android console) am [start|broadcast|instrument] am start -D INTENT am broadcast INTENT am instrument [-r] [-e <ARG_NAME> <ARG_VALUE>] [-p <PROF_FILE>] [-w] <COMPONENT> INTENT is described with: [-a <ACTION>] [-d <DATA_URI>] [-t <MIME_TYPE>] [-c <CATEGORY> [-c <CATEGORY>] …] [-e|--es <EXTRA_KEY> <EXTRA_STRING_VALUE> ...] [--ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE> ...] [-e|--ei <EXTRA_KEY> <EXTRA_INT_VALUE> ...] [-n <COMPONENT>] [-f <FLAGS>] [<URI>] Resources used: Android Installation Guide.

http://developer.android.com/sdk/1.5_r2/installing.html

Android Developer reference.

http://developer.android.com/reference/classes.html

Jesse Burns. Developing Secure Mobile Applications for Android.

https://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf

Designing a Remote Interface Using AIDL

http://developer.android.com/guide/developing/tools/aidl.html

Android -A software stack for mobile devices that includes an operating system, middleware and key applications. Based on Open Source solutions (in particular, Linux kernel) it provides an easy integration with other Google services (maps, shopping, search).
The Android SDK includes a comprehensive set of development tools such as debugger, libraries, a handset emulator (based on QEMU), documentation, sample code, and tutorials.

With great built-in features of the Android SDK provides immense flexibility and opportunity to develop diverse smart mobile applications, providing the opportunity to cash in for not only technology companies but also individual entrepreneurs from various industries and aspects, be it pharmaceuticals, sales force automation, entertainment, games, location based services of or any sort of utility applications.

The Android core libraries provide the functionality needed to build some amazingly rich mobile applications, and the Android development tools make running, debugging, and testing your applications a snap. Android enable developers to create compelling mobile applications that take full advantage of all a handset has to offer such as making calls, sending text messages, or using the camera, allowing developers to create richer and more cohesive experiences for users.

Android is open source that liberally extends to incorporate new cutting edge technologies as they emerge. The platform will continue to evolve as the developer community working together to build innovative mobile applications.

Since Android has made Global recognition in the market, we have our Android application Development team which is well equipped to understand and use different toolkit and cater to the growing demands of Android application Development. We delegate the capabilities of the Android application Development and provide fast, high quality and a cost-effective solution to all our customers willing to add essence to it.

I haven’t been on here a while and I apologize for that. This summer has been a busy one for me – first in summer school for AP Macroeconomics for 6 weeks and then I went back to India for 4 weeks. I’m back now and of course, school starts in 2 days. But I have been doing some WinMo stuff over the past 2 months. However, I haven’t been working on my OnDemand customization. Instead, something bigger has caught my attention.

Ever since Da_G over at XDA-Developers created a thread about the Image Update system, I’ve been following and developing some of my own software. For those who don’t know, the Image Update system allows for you to update the IMGFS and XIP partition of your phone via cab files instead of flashing the device and losing all personal data/installed applications. To make this mechanism work, which has been present in Windows Mobile since WM5, all of the DSMs (Device Side Manifests) need to be in the proper MS format. Unfortunately, all of the current kitchen tools that we use for ROMs malform these DSMs or completely remove them from the ROMs. Because of that, I’ve been working on applications that will make Image Update work properly. In June, I was able to create two applications – one that regenerated DSMS from scratch in the exact same way MS’s tools are supposed to work. The other would create the Image Update packages and sign them - they produce the same results as the ones generated my MS’s tools as well. I’ve been working to consolidate them into one app that will also act as a ROM kitchen that adheres to MS’s documentation (for the most part ).

For those who are interested, you can check out Da_G’s thread in the Dev & Hacking section of XDA (I’m too lazy to link to it right now )

Now that the Windows Mobile 6.5 resource kit is out (You can download it from here) it is time to start writing widgets!!!

Necessary equipment

1. The 6.5 emulator images
2. The web development environment of choice
3. WMDC or Windows mobile device center (on vista or windows 7) or ActiveSync 4.5

With that you should be ready to go to get started, the first step is to start the emulator and cradle the device. The emulators can be started from the start menu under the “Windows Mobile 6 SDK -> Stand Alone Emulator Images -> ”. The device emulator manager can be started using explorer to navigate to the following folder “C:\Program Files\Microsoft Device Emulator\1.0” and selecting dvcemumanager.exe.

Once they are both started, open WMDC or ActiveSync and select connection options and, on the “Connect one of the following” combo box select “DMA” and click “OK”.

Now, on the “Device Emulator Manager” select “Refresh” and then find the emulator on the list, should be the GUID under others and right click -> cradle to connect it to the PC.

Once that is done, select “Connect without setting up my device” and you should be ready to go, to test, open internet explorer on the 6.5 emulator and navigate to any site, if all is set up correctly it will navigate to it using our brand new browser.

And now…. the fun part begins!

To write a widget we need to follow three easy steps.

Develop your widget code

For this you can use the web development tool of your choice, but as an example we can start with something super simple, as follows (write it into a widget.htm document)

Package your widget

Now we have our extremely functional widget code, now we need to create a manifest file (so the framework knows what to do with it) following the w3C widget standard for packaging and configuration (On 6.5 we support the December 22 2008 draft), but to make things easy, here is a small manifest, copy it into a config.xml file in the same folder as your widget.htm

Don’t forget to also add an icon called icon.png on the same folder.

At this point, you should have three files (config.xml, icon.png and widget.htm), now we need to package them, on explorer, select the files, right click and send to a compressed folder (it is important to select the files and not the folder that contains them because we want config.xml to be in the root of the zip container). Now just rename the newly created zip file to “widget.wgt” and you are done with this step.

Deploy and run

On “Computer” you should see the cradled device emulator as “PocketPC device”

Use it to navigate to “My Documents” on the device and copy the widget file created in step 2 there. Now, on the emulator, open file explorer using the start menu and, listed there you should see your widget file, click on it.

This should start the installation process, once that is done you will see your very first widget on screen!!!

To continue playing with this widget (make it better, etc) you can find the uncompressed files on the “Program Files\Widgets\User\ folder” on the device.

The widget ID is generated at install time and it is an always increasing integer (therefore, the most recently installed widget will have the greatest number). You can replace, add, remove files here for testing at will; the only thing you need for a your widget to pick the changes up is to exit it and start it again, it will have an entry on the start menu.

I will be sharing more information about the widget API, how to extend the widget framework capabilities, debugging tips, best practices, etc in future posts but I wanted to help everyone to get started.

For now, you can also take a quick look at my TechDays session where I describe the API set and some of the capabilities of the framework. To access it you’ll need to log into the Microsoft Tech Days site and search for MBL302 Windows Mobile Web and Widgets: Leveraging web technologies to build experiences for Windows Mobile.

Stay tuned, have fun and don’t forget to share your thoughts… Also, before I forget, you can upload your cool widget creations to the Marketplace , visit http://developer.windowsmobile.com for more information.

Jorge Peraza

This is one cool note, posted on Windows Mobile Team Blog @ microsoft!
Finally i know what WTF means

Earlier this week we released the Windows Mobile 6.5 Developer Toolkit (DTK). This release has raised a few questions relative to the other Windows Mobile software development tools and resources. I’d like to take a moment to describe what the SDK, DTK, and DRK are, and just as importantly what they are not.

SDK: Software Development Kit

We have not released a new SDK for Windows Mobile 6.5. The Windows Mobile 6 Professional SDK or Windows Mobile 6 Standard SDK are required for Windows Mobile 6.5 application development.

DTK: Developer Toolkit

The Windows Mobile 6.5 Developer Toolkit (DTK) is not an SDK! The DTK contains emulators, gesture APIs, and samples useful for developing Windows Mobile 6.5 applications. You will still need to install Microsoft Visual Studio® 2008 and the Windows Mobile 6 SDK prior to running the toolkit installer.

DRK: Developer Resource Kit

The Windows Mobile Developer Resource Kit (DRK) is an offline DVD copy of the most useful and relevant Windows Mobile application development tools and resources. Traditionally the DRK does not contain any exclusive content, in that nearly everything on the DRK is available for download online. This time we are pleased to publish the Windows Mobile 6.5 DRK with several sample chapters of Microsoft Mobile Development Handbook from Microsoft Press (Wigley, Moth, and Foot).

We hand out free copies of the DRK at several conferences and developer events throughout the year. Beginning in July 2009, you may also order the Windows Mobile 6.5 DRK online at this Microsoft Web site. The previously listed Windows Mobile 6 Developer Resource Kit will be replaced.

WTF: Where To Follow?

Follow us on Twitter @wmdev to get the inside scoop and up to date information for development on Windows Mobile!

The Windows Mobile 6.5 Developer Tool Kit adds documentation, sample code, header and library files, emulator images and tools to Visual Studio that let you build applications for Windows Mobile 6.5. This document contains important information about this package. For general information about writing software for Windows Mobile, please see the Windows Mobile Developer Center. The Windows Mobile 6 SDK must also be installed in order to use any of the Windows Mobile 6.5 Gesture API or samples. Windows Mobile 6.5 Developer Tool Kit comes with the following.

Quick Details

Version: 6.5
Date Published: 6/3/2009
Language: English
Download Size: 71.4 MB – 1848.3 MB*
*Download size depends on selected download components.

Emulator Images

• Windows Mobile 6.5 Professional Square Emulator
• Windows Mobile 6.5 Professional QVGA Emulator
• Windows Mobile 6.5 Professional WQVGA Emulator
• Windows Mobile 6.5 Professional VGA Emulator
• Windows Mobile 6.5 Professional WVGA Emulator
• Windows Mobile 6.5 Standard Square Emulator
• Windows Mobile 6.5 Standard QVGA Emulator

Available locales

• 0804 CHS Chinese Simplified
• 0409 USA English
• 0407 GER German
• 040c FRA French
• 0410 ITA Italian
• 0c0a ESN Spanish

A new set of APIs is being introduced that will enable application developers to take advantage of the new Windows Mobile 6.5 touch gesture framework. The gesture APIs allow an application to handle touch gesture input and provide a visually consistent experience with the rest of the device UI. Note that the gesture APIs are only available on the Windows Mobile Classic and Professional SKUs. The headers and libraries are installed in the Windows Mobile SDK\Pocket PC\ folder. Samples that make use of these APIs are installed into the Windows Mobile 6.5 Developer Tool Kit\Samples\ folder.System Requirements

Supported Operating Systems

• Windows Server 2003 Service Pack 2
• Windows Vista
• Windows XP Service Pack 3

Download

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=20686a1d-97a8-4f80-bc6a-ae010e085a6e#filelist

The Games API (GAPI) was a technology that allowed Windows Mobile 2003 applications to quickly draw graphics onto the device screen. It also contained functions that allowed an application to request all button press messages, even the ones that were normally intercepted by the Windows Mobile operating system.

The graphics component of GAPI was replaced by DirectDraw (which allowed hardware acceleration) in Windows Mobile 5.0. Application compatibility was maintained so that older programs would still work.

Most of the reference material for GAPI was removed from the Windows Mobile 6.1 documentation set, although the input functions were kept, so that applications could still request all key and button presses.  Application compatibility was maintained for this release as well.

This is all changing for the next generation of Windows Mobile, Windows Mobile 6.5.  Although some devices may still support GAPI, there is no longer a requirement for device manufacturers or mobile operators to ship or test for compatibility with GAPI.  This means that applications that require GAPI will provide an unpredictable experience for users on Windows Mobile 6.5 devices.

Another important change is that acceptance to the Windows Marketplace for Mobile and Designed for Windows Mobile certification requires no application dependencies on GAPI.

In order to replace the input functionality that GAPI once provided, a new keyboard API function is being made public.  This function is AllKeys(), and is defined below.  One great thing about this substitution is that AllKeys has been a part of Windows Mobile as long as GAPI, and is actually the API call that GAPI wrapped in order to publicly expose this functionality. This means that the transition to AllKeys should be easy, and backwards compatibility should be maintained.

You can migrate your input code to AllKeys in the following way:

Replace:

• GXOpenInput() with AllKeys(TRUE).
• GXCloseInput() with AllKeys(FALSE).

While AllKeys is set to true, all key presses will be sent to your application for handling.

Since GXOpenInput and GXCloseInput were simply wrappers for a call to AllKeys, so this substitution should cause no change in behavior in your programs.

The following is the definition of the new AllKeys API.

AllKeys

This function allows your programs to request that all key presses be sent directly to the requesting application. Normally some buttons are intercepted by the operating system for its own use, but games and input – intensive applications may want access to these buttons for their own use.

Syntax

BOOL AllKeys(
BOOL bAllKeys
);

Parameters

Return Value

Nonzero indicates success. Zero indicates failure. To get extended error information, call GetLastError.

Sample Code

The following C++ code illustrates how to use AllKeys. In the application that this sample is taken from, a check box is used to set AllKeys to true or false.

// process checkbox
case IDC_ALL_KEYS_CHECK_BOX:
if (g_AllKeys == true)
    {
    // Allow the OS to intercept some button presses
     AllKeys(FALSE);
    g_AllKeys = false;
    // set button state
    SendMessage(hwndCtl,BM_SETCHECK, BST_UNCHECKED,0);
    }
else
    {
    // Do not allow os to intercept button presses
    AllKeys(TRUE);
    g_AllKeys = true;
    //set button state
    SendMessage(hwndCtl,BM_SETCHECK, BST_CHECKED,0);
    }

Requirements

OS Versions: Windows Mobile 2003 and later.

Header: Winuser.h

Where to start?

It is safe to say that there are more options for development on Windows Mobile 6 than on any other mobile platform. WM has been around for a while, and Microsoft has built up a huge variety of APIs and development tools to support the platform. This is good – no matter what your preferred style of programming is, there is probably a supported solution on WM. It can also be confusing if you are trying to find out where to start when developing an application.

The options include:

• Browser based development using scripting languages and Flash or Silverlight. This option is poorly supported in the existing mobile browsers, so at the moment, this is not a practical option.
• Managed Code using . NET languages and the .NET Mobile Library.
• Native coding using C++ and Windows Mobile native libraries.

Note: Not all Windows Mobile native libraries have managed equivalents. This means that the author of a managed program (in C# or VB for example) will have to use cumbersome and potentially unsafe methods to integrate the native library into the managed application if they wish to make use of the full libraries.

There are also different flavors of Windows Mobile 6: Standard and Professional. The big difference is that Professional devices have touch screens, and generally more features. It’s reasonable to expect that the performance of a professional device will be superior to that of a standard (no touch screen) device and the touch screen allows more input possibilities so I expect to focus on those devices.

At the moment, I’m not sure if I want to develop on managed or unmanaged code. I prefer to develop in C# using managed code, but may need the performance and APIs that are available to the C++ programmer. Luckily, I will use the same tools to develop both kinds of applications for WM, so I don’t have to decide what environment to use quite yet.

Reading up

In the past, the first stop in making sense of all these options would be to check Microsoft’s official documentation on MSDN, but that is changing. The official starting point for development on Windows Mobile is now the Windows Mobile Developer Portal.

For the moment, I actually prefer the material found on a different site -Windows Mobile Developer Center, although I’m told that these two sites will be integrated in the next few months. This site has webcasts, videos, and (of course) this blog.

The first thing I want to do is set up my development environment, and so I started looking for a section that would tell me how to start.  I already have a copy of Visual Studio 2008 installed, and wanted to use it, so I looked for that first.

Setting up

Note: Unlike the documentation on MSDN (Windows Mobile 6 Documentation) which only covers Visual Studio 2005, the information I found for setting up Visual Studio 2008 on the Developer Center was in videos. See http://code.msdn.microsoft.com/WM6YourFirstApp for a good getting started video.

Although the videos are current, excellent and accurate, watching the video is more time consuming than reading a procedure, (and impossible to find via search) so I’ll summarize them here:

1. Install Visual Studio 2008. The SDK only works with the Standard and Professional editions, not with the free Express editions. There is a 90 day trial edition that you can download for free at the following web page: Try Visual Studio 2008 – Trial Software.
2. Install the Visual Studio 2008 Service Pack 1 and .NET Framework 3.5 Service Pack 1. There may be other service packs available by the time you read this. Information on the latest service packs may be found at the following page: Visual Studio 2008 Development System.
3. Download the Windows Mobile 6 SDKs from the following page: Mobile 6 Professional and Standard Software Development Kits Refresh. I am installing both, although I am planning on writing only for the Professional Edition device. You never know when you might change your mind!

Note: if you have installed the SDKs before Visual Studio 2008, you will need to remove and re-install them after the VS 2008 install.

Building a test application

To confirm that you have a working installation of Visual Studio and the SDK(s), try creating a simple application. I created a blank C++ project by following these steps:

1. On the start page of Visual Studio 2008, in the upper left hand corner, there is a block titled “Recent Projects”. At the bottom of this block, there is a link for Opening a Project, and for Creating a Project. Choose Create Project.
2. In the New Project dialog box, choose “Visual C++, then “Smart Device in the Project Types list. The Templates section should be populated with different project templates for different kinds of projects.
3. Choose Win32 Smart Device Project, and enter a name for the project. “Test” is fine. Click OK.
4. The Win32 Smart Device Project Wizard opens. The presets are set to Windows Mobile 5.0, which I don’t want to use, so I choose the Next button at the bottom of the dialog.
5. This brings up a list of installed Windows Mobile SDKs. I am going to remove the Windows Mobile 5.0 SDK from the Selected SDKs list, and add the Windows Mobile6 Professional SDK and Windows Mobile Standard SDK. Once this is done, I click Next.
6. In the Project Settings Dialog, I select “Windows application” and click Finish. The dialog closes, and Visual Studio creates a new project, populated with basic files, named “Test”.

In Visual Studio, I make sure that “Windows Mobile 6 Professional Emulator” is chosen in the drop down list on the upper left tool bar. I then build the application “Test”, and choose to start debugging.

The Emulator appears, and in a moment, my application (with a blank screen) loads and is displayed in the emulator.

Clicking on the close icon in the upper right hand corner shuts down my application, and Visual Studio returns to its default state.

Excellent – that was easy, and everything works!

If I wanted to build for a different flavor of Windows Mobile (Standard, Windows Mobile 5, or deploy to an actual device, I would choose a different option from the upper left hand tool bar drop down. Does it all make sense so far?

Marketplace Registration Open!

In the latest update to http://developer.windowsmobile.com, developers can now Register to participate in Windows Marketplace for Mobile. This marks another milestone in providing Windows Mobile Developers a clear path to develop, test, certify and distribute their Windows Mobile applications via the Windows® Marketplace for Mobile. Throughout the registration process, links to key documentation for distributing apps through Windows Marketplace for Mobile are provided.

Next steps for developers?

• REGISTER NOW. Developers can submit their complete profile information and take the first step in registration.
• Follow the Windows Mobile Developer team on Twitter @wmdev, Facebook and YouTube.
• Keep up to date via the Windows Mobile Team blog.
• And, stay informed with the latest development tools on the Windows Mobile Developer Center on MSDN.

Finally, if you have any questions for the team that are not already addressed in the Windows Marketplace for Mobile FAQ, I invite you to write a comment below.