The Pocket Commando by Carl Davis | Back

Part 2: Building a better world with Windows CE logo certification
Written by Carl Davis  [author's bio]  [read 34447 times]
Edited by Derek

      

Page 1  Page 2  Page 3 

This installment took longer than I would have liked. I spent the month of July preparing for GenCon, one of the largest gaming conventions in the world. This event brings together players of card games (Magic: the Gathering - not the poker kind) and Role Playing Games (the Dungeons and Dragons kind not the computer kind) for four days of constant fun. I run several adventures (see www.webcommando.com/gencon) and took my trusty Pocket PC with me. This was a great opportunity to showcase the power of the Pocket PC and some of the applications I wrote (www.rpgcommando.com).

The tools I brought along were Illium Software's ListPro to track nuggets of gaming information, my own Slicer and Dicer for advanced dice rolling, and my Character Sheet program to track ability scores of the antagonists of the adventures. I combined these with Pocket Word for descriptions and notes. I also added a J2ME application I wrote running on my iDEN phone for simple dice rolling; each button on the keypad was represented a different style of dice (I am by nature an equal opportunity small device developer!). With all this wonderful technology, I was hoping I could eliminate binders full of maps and notes. I was also thought I would never need to pull out my big bag of dice! Figure 1, below shows my techno-tools setup.

My solution worked pretty well, I was much more efficient and could spend more time working closely with players. I constantly wandered around the table, staying close to the action. However, I still found myself returning to my notebook. It was much quicker to page through my notes. Also, switching between applications was tedious and I needed to give too much attention to navigating the interface. This limitation might be due to fact that Pocket Word doesn't have a table of contents feature. As a developer, it made me wonder if there wasn't a better way to manage all this information. Perhaps I'll write something new to try next year!

Ok, enough on gaming, lets talk Windows CE Logo Certification…

As promised last time, we'll look at some more at becoming Windows CE Logo compliant. John Lescoulie from Veritest was kind enough to provide a list of the top-ten problems they find when applications are tested. I think it's useful to mention that Veritest wants to work with developers and I encourage you to consult them prior to submitting your application. They want to see you succeed on the first try!

We'll first take a look at the list. I've recreated them exactly as Jon sent them and will add my own comments later.

1) Help system for the application not integrated with the system TOC
2) The "no user-exposed method for closing the application" logo requirement is violated
3) Application does not resize when the 80 pixels tall SIP is up.
4) Application fails to register both 16x16 and 32x32 pixel icons for main executables and saved files.
5) Application fails to uninstall properly using the CEAppManager in ActiveSync.
6) Application leaves items behind in the Registry after uninstall.
7) Application fails to install on one of more processor types suck as SA1100, SH3, or MIPS.
8) Application fails to function properly on one or more processor types.
9) Application has a Help button visible to the user in the UI/Shell instead of enabling Help access through the Start menu.
10) The "Applications may not use NavBar for anything application specific" logo requirement is not met with developers adding icons or text.

I was pleasantly surprised by this list. I had expect much more difficult problems to tackle. Obviously, we don't solve all the problems eloquently with our eVB applications. For example, the icons installed are generic eVB icons not our own. We can use the code provided by Microsoft to create an eVC++ loader, but I won't get into this now.

Looking closer at the list…

I was surprised that the number one issue isn't a problem with complex coding for the numerous processors, but help for users. Help is often the last thing on the mind of many developers, but fortunately integrating help with the Table-of-Contents (TOC) on the Pocket PC isn't difficult. The number nine issue is also related to help. Placing a help button or menu item within the application is not allowed under Microsoft's guidelines, though many of us are guilty of taking this short cut. I've decided to spend time building help into an application that handles these issues. Before we get to that, we should look at a couple of interesting entries on the list.

Last time we looked at our second big hitter on the list. To remove the "OK" and ability to exit, I created an application that used the list view/card model for an application. Refer to part one (ß link to part one) of this series to learn more.

Working with the SIP can be a bit tricky, leading to the number three problem. It requires resizing your content and avoiding placing input controls under the keyboard when it pops up. My article on scrollable forms (ß link) shows one way to handle changes in the SIP. I created a form with a scroll bar on the side that allows the user to move the form up and down as desired.

Finally, to avoid failing because you used the NavBar on top of the screen…well don't. That solves that issue pretty easily. If you want to add buttons, use the menu bar at the bottom of the screen.

Next Page 

Back to the Pocket Commando | [Article Index]