I've been working on this for a little while now.   Ever get asked when your out and about "where are you?".    We'll if you want to be truthful and really report back really where you are here's a little app that does just that.

With a GPS connected phone,   you've potentially got access to SAT Nav and all of that good stuff.   However its harder to notify someone of your exact location.   

Using the Windows Mobile GPS intermediate driver,   its a easy to build a mobile application that will talk to any Bluetooth, internal or SD card GPS receiver.

I've made the application so that you can store a number of your contacts email addresses from the Pocket Outlook address book, so its quick to find who you want to send your location to.     In addition  you can setup a number of Points Of Interest (POI's).    These POI's can be for locations such as 'Home', 'Work',  'Train Station' etc.

You can then send a message to one of your recipients with optionally the distance from one of your POI's.   i.e you can send your wife an email with your distance from home (and a live map).   Its limited at the moment to using Exchange as the email transport.

Finally the email that you get send out contains a link to a map with exactly where you are -

So if you like the idea of this little app.  You can download the Windows Mobile 5/6 Standard version (aka SmartPhone) version  HERE

You'll need the SQL Compact 3.5 runtime on your device,   which you can get HERE

If you haven't done it already on a Windows Mobile 5/6 phone to configure the GPS Intermediate driver you need the settings tool,  which I've put a link to HERE 

Its a good idea to click these 3 links on your phone,  to save you the bother of having to copy them over from your PC.

I make no claims for reliability, this is very much a work in progress, let me know what you think by sending me a mail (richard@binaryrefinery.com)  or adding a comment.

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.

I love this.   A couple of pinvokes to make two applications talk to each other.

To send messages to another application you need the following -

[DllImport("coredll.dll")]
  public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);

  [DllImport("coredll.dll")]
  public static extern int SendMessage(IntPtr window, int message, int wparam, int lparam);

Which respectively allow one application to get the window handle on another,  then send a message.

One the receiver side,  its a snap just override the following -

protected override void WndProc(ref Message msg)
{

}

I'm not really filling in all the gaps here I know, but I'll let you explore it works really great.   

I've been using a Zebra QL240 Plus printer today to generate pallet labels.

This has saved me a tonne of time.   I've been creating my labels using Label Vista,   the bundled software that comes with Zebra printers.

Get the labels looking nice.   Test print them by hooking up a printer on your PC using USB.

Now here comes the time saving bit.    Save the label file in Label Vista.    Now add the resultant LBL file as content to your compact framework application's project file.    Then simply read the file in code and send it to the appropriate com port.

This way you get all the speed of a nice WYSIWYG environment, with all of the benefit of being able to then use these label format as is, in a mobile line of business solution.

I made a further refinement which searches and replaces any text field on my label to substitute in my own values.   so xxBARCODE becomes the barcode we want etc.

Please notice,  that I've added an instant messaging link on the front page of my blog.  

I'm using one of the new features of Live.    Link is Here.

I'm not sure if this is a good idea yet or not...  

-41.241987 174.796904 TO 51.4420 0.75462

Thanks to my good friend Gareth Purchas,   the SQL Compact sync mission,   has just stepped up a gear.  

Tonight we did a SQL Compact sync, to Wellington in New Zealand.    That's a new record.

You can see the Virtual Earth Map by clicking here

I've been on a bit of a mission for the past few days.    A friend of mine asked how easy it would be to build a system that accepted text messages and was able to respond back to the sender.   So I got thinking,   radio stations and TV do this all the time.   Text "VOTE BOB",  to 83232332 to evict Bob from the Big Brother House.    Or nightclubs let you text the DJ for what to play next.     So how could you build a simple desktop application that could process and respond to text messages?     I'm going to take the next few posts to cover a solution to this problem.

I'm sure, you can see where this all going; doing windows mobile line of business we have all the pieces.    Firstly using SMS message interception,  we are able to capture any incoming text message and process it ourselves.    So first job was to build a Windows Mobile Line Of Business application to listen to the incoming texts.   Here's one that I prepared earlier -

This application captures any incoming text message with the magic bit of Compact Framework code -

            interceptor = new MessageInterceptor();
            interceptor.InterceptionAction = InterceptionAction.NotifyAndDelete;
            interceptor.MessageReceived += new MessageInterceptorEventHandler(interceptor_MessageReceived);

Next step we need to pass the contents of any text message over to a desktop PC for processing.    Now I now this isn't truly in the spirit of mobile line of business, where we normally do everything on the device,  but at 2am in a crowded nightclub, its probably better to pass the messages over to a desktop PC for handling.   Of course their are many ways to achieve the Windows Mobile to desktop connectivity.  I opted in the end for raw TCP/IP socket programming, which lets me use the setup either over an ActiveSync/Windows Mobile Device Centre with a cable from the mobile device or  a wireless connection.    

Here's the desktop side of things,    listening for incoming messages.

Now its not pretty 'yet'  and I haven't got it displaying a bar graph or counting votes,  but the mechanism for collecting and responding to text messages is all in place.

So lets give it a run.    Now being frugal  I thought I'd save myself lots of cash and use the Windows Mobile 6 SDK, Cellular emulator to send fake text messages to my phone emulator.    So I've sent "Vote Bob", to my phone.       I get an text message response back to me, saying "Thank you for you're vote".   

The desktop application just for proof of concept also pops up each received text message, as follows -

More over the next few posts.  Send me a mail if you are interested in the complete source of this application.

Nick Randolph (fellow device dev MVP) and I have just achieved something this evening/morning (depending on timezone).

We have used SQL Compact to synchronise a database all the way from Sidney Australia to the Sheerness UK.   That's a distance of 10,527 miles.

Here's the screenshot showing the synchronisation completing perfectly.

Thanks to Capespan's Kevin Cracknell's database that provided the sync. target.

You can see the Virtual Earth Map by clicking here

So just to recap,   this shows that a partially connected database application can be used with a back-end database running 10,527 miles away.