Wednesday, May 07, 2008

Today's been interesting.   I've been deploying a mobile line of business solution to a customer who is deploying their application to a geographically dispersed (i.e all over the place) audience using both GPRS, WIFI, HSDPDA and Wired Lan.   

They are using a combination of devices ranging from Symbol scanners, to Windows Mobile phones with Bluetooth barcode scanners and mobile Zebra printers.    So here's my top ten tips to help you get through the pain of Compact Framework rollout like this.

1) Centralise

Centralise all of your device deployment - I use a single website to host of of the applications CAB Files.

2) Save your bacon

Implement a global exception handler so if your application does go POP,  you can call a web-service that will send you an email.    Know about problems before your boss does :-)

3) Remote Support

Having a tool like SOTI in your toolbox is invaluable.   I let end users see their IP address on an About window,  so you can quickly establish a SOTI Pocket controller connection to see what's going on, on the users screen.

4) Manage Version Updates

Things will go wrong/people will request changes.    Ensure you have a mechanism to automatically deploy revised versions of your software.    This will save you BIG time in the long run, not having to recall devices back.

5) Test Environment

Keep things easy for yourself have a separate test environment.  Also automate the procedure of rolling changes without intervention from test to live.   This is possibly a statement of the obvious, but in high pressure situation where an end user has encountered a problem you don't want to be hacking out changes into live.

6) One Version Of The Source

I hate maintaining separate source for different sceneries.   One size may not fit all, but it will save you a hell of a lot of time if you've got only one application to change.

7) Lock It Down

If your doing mobile line of business know your audience.   It may be ok if your deploying to power users on their Windows Mobile phones that's one thing.   However if your deploying to ruggedised devices that need to work around the clock hide start menus,  make your application start on device power up.   I also add password protection to settings screens to stop the casual 3am attempt to change stuff on the device.

8) URL's

You'll probably be working in different network environment some people on the network other people connection over the Internet.    Ensure a good policy to cope with resolving server names on devices.   I use the concept of profiles in a configuration file.   i.e a device can be set to be 'Working On LAN',  which will use an local IP address to resolve the server.   Whereas a profile of 'Internet', will use the external fully qualified Internet DNS name.

9) Clocks

This will let you down, time and time again.   You cannot rely on device time clocks to correctly write a timestamp onto a record.    Make sure if you have to write a timestamp in your .Net Compact Framework application you have synchronised the clock of your device to the server (search my blog on how to do this).   Better still always write your timestamp's in on the server side.

10) Configure By Data

Its way easier to have screens that are driven by data rather than coding in how things should operate.   Its way easier to put records in a database to determine what happens out on the device rather than having to change code.

 

Anyway my top 10 list works for me and I hope it helps you.

Wednesday, May 07, 2008 11:42:03 AM UTC  #    Comments [0]  | 
Comments are closed.

Theme design by Jelle Druyts

Pick a theme: