Page 1
Page 2
Page 3
Page 4
The Microsoft Mobile Internet Toolkit
It is inevitable that once you have contemplated the utility of using the Pocket PC as a solution platform this is quickly followed with the notion of – “Right how can I deploy this to say a cell phone, and a Palm and our sales force in Japan?” Well serving up different content styles, images and functionality (richness) for different mobile platforms is the purpose of the Microsoft Mobile Internet Toolkit (MMIT). After discovering XML and XSL one of my first reactions was that I could now tailor content to different platforms using the same XML source and different XSL style sheets. I soon realized though that keeping up to date with the new clients capabilities and the complexity of generating the appropriate XSL was not a task for any regular code warrior. To this scenario, MMIT brings sanity and lots of hope.
MMIT extends the VS.NET IDE with the introduction of the Mobile Internet Designer. You can create a mobile application dragging and dropping the appropriate controls onto mobile web forms in the knowledge that MMIT will render it appropriately to the different devices.
MMIT achieves this via an adaptive user interface which has the capability to adapt the content displayed to the requirements of different mobile clients; depending on screen size, cookie support and markup language. MMIT overcomes another irksome issue with mobile devices that don’t support cookies by maintaining state on the server but using unique URL based identifiers instead of passing all the session information in the URL, which would not work well with these bandwidth challenged devices. In addition you can assert some control over MMIT’s customization using device adapters or filters which give you the means to ensure a certain behavior from MMIT for certain devices.
STANDARDS & Mobile2Market
Standards for application behavior are critical. We have all come to expect context sensitive menus when we right click an object in a Win32 application and the same should apply to the Pocket PC.
Windows CE logo certification information
Enhancing the similarity of the user experience across all applications on the device is very important when faced with the data entry challenges of the Pocket PC. The more uniform the behavior and interface of all the applications on the device the better the experience for the end user.
PROJECT TIME LINES
I occasionally come across the perspective that developing for Pocket PC devices almost falls into the hobby type arena and that I should be able to cobble together an application in a spare weekend and hand it over on a Monday. Nothing could be further from the truth. Pocket PC development is far more time consuming than its desktop cousin. By it’s very nature developing for the Pocket PC often entails retrieving data from a remote data resource, adding or editing that data and then uploading it to the original source. This process is further complicated by device constraints, which often call for judicious workarounds. You may think nothing of using an edit screen on your desktop which has multiple list boxes each with 150 entries. Scrolling on a Pocket PC is no fun and that same solution on a Pocket PC would be very cumbersome. You would need to come up with an alternative approach. This translation of approach from what works on the desktop to what works on the handheld takes time and you need to cater for this.
In addition frequent iterations of developing the code on the desktop, deploying it to the device and then field testing it all take time.
INSTALLATION
Installation and deployment of the Pocket PC applications is maturing and there are some great third party solutions. Once you have painstakingly developed, tested and honed your mobile application you need to deploy it on end users’ Pocket PC’s. If you were developing for the Pocket PC 2000 specification you would have to create a separate download for each processor your application was targeting, with the different runtime libraries for each processor. Since the Pocket PC 2002 specification only supports the ARM processor you just need to create one installation file. How you deploy that file though is kind of interesting. You can install it on the desktop which will then install it on your device at the next sync or you can create a CAB file which will install on the device and remove itself after installation. Your approach here depends upon whether your mobile application has any desktop components and what kind of setup they require.
SUPPORT
This is a key area – without support to troubleshoot say potential connectivity issues; your killer app may never get to synchronize with the CEO’s Pocket PC. Setting up mobile connectivity, dealing with ActiveSync issues, networking, TCP/IP configuration, Connection Manager, Bluetooth, 802.11, dialup modem, infrared and synchronization require knowledgeable support staff.
The application may work like a charm in your test lab and not even install on the client Pocket PC because they are running a patch for their VPN software. Finding support personnel with Pocket PC experience is essential for any large scale Pocket PC application deployment.
Previous Page