Fundamental Software Solutions

On a past project, we had been challenged with Windows Mobile and GPS.  Specifically, our customer wanted to have a display of the position of his crew on the street from back at the control center.  GPS provides the positions, but there is a huge penalty in terms of battery power.  On some of our test phones, it was better for the battery to have the GPS tracking on permanently, as gathering the first sample sometimes took too long, and of course took too much power to provide little result. On others, just the GPS startup delay would draw sufficient power for the battery to drain within a morning of in-field testing around downtown buildings and other GPS-holes.

The project had been canceled, but our thoughts still moved forward.  We often find repeat requests for the same thing relatively close to the same time, and we had to know how to solve this.  Google Maps (mobile) was doing something with cell towers, and could the average company also head this way with satisfactory results?

After reviewing some previous internet articles (Google mmaps MCC MNC LAC CELLID) on the subject of tower-provided coordinates, we threw together a demo in a little under a week that incorporated tower position gathering, optimal power management, app waking and a web service that not only collected the tower and location positions, but also provided a map of the subject(s) that were being tracked.

There are some obvious issues that were somewhat difficult, yet vital for this project.

1. Battery
   No matter how little you wake a device, you still are waking it.  Smart-phones seem to handle this better, but the general idea is wake it, do the smallest amount you need to do and then shut it down.
   
2. Power States
   The Windows Mobile is a complex device, and you properly have to manage the power states.  (Imagine waking the device and attempting to update a position when the network is powered-off!)  Finding the right power state that both accomplished the task and kept the user from accidentally dialing when his phone awoke within his pocket was a challenge.
   
3. Sample Rate
   If you are like me, waiting 10 minutes for an update on location was painful.  Especially during testing.  However, if you wake a device and transmit (our packet happens to be around 128-238 bytes each update) then you start to either wear on your data plan, or the battery over time.
   
4. Precision
   We have used a couple of things to maximize precision.  First, we have a technology that we implement called Supplemental Tower Positions.  When a tower is known to be somewhere, we can supplement or correct the location.  Since the location information is all done on the server side, the phone doesn't need to process anything more than Wake, Transmit and then Sleep.

What's next?

The technology is relatively boundless.  Once we have position information, it is possible either at the phone or home base to calculate other things or otherwise add value.  The technology, although implemented here very one-way, could be adjusted to add two-way communications.  A quick search and click by a service rep at the office could schedule for the closest maintenance worker in the field, for example, all through the same communications system. 

You could also outline GPS zones, where it would be possible to say that a rep was "at home" or "in the office" automatically by seeing where his phone was (or wasn't). 

Positioning could also have effects for unlocking or controlling secrets.  IT managers may encrypt a password or entry code with a GPS position or positions.  The IT Staff can then only retrieve the passwords for the systems when at that position.  For home alarms, perhaps the alarm knows you are at the door and automatically turns off.  If you are away, it knows and alerts the authorities.

Source Code

We are not currently ready to release any source-code.  Since the service hits our public web server, we can't allow free downloads except upon specific circumstances or special request, sorry.

I had the pleasure of creating and working with some "always up to date" applications on my Windows Mobile Device, and have tested some other manufacturer's products that do similar things.  One thing I really hate is having to set peak times or configure when data transfers should occur in every application differently.

For some people, it may be beneficial to have mail syncing at a separate schedule than for something like phone-coordinate tracking, but sometimes it is nice to should be able to set those settings ONCE if I choose, and let all my software follow that one setting.  For example, I often reset ActiveSync's schedule when I travel to avoid costly data transfers when I don't need to check my mail.  I really hate when I get the bill the next month after I forget one app!  Maybe allow the user to choose "follow activesync" or "use custom settings" or something like that if you need more precision than just M-F and a start/end time.  For most of our customers, ActiveSync's schedule is exactly what they needed.

So, For all the developers out there making software that communicates over the air - I have posted some source code(below) that will tell you if the current time is "syncable" and if not, will tell you the next time when a transfer should be allowed.

For example:

if(FSSI.Mobile.ActiveSync.Settings.IsInPeak(DateTime.Now))
{
   // Do something.
}

or, to check when the next sync time is (such as when planning when to wake the device to Sync....)

DateTime TimeToWake = DateTime.Now + new TimeSpan(60,0,0);
TimeToWake = FSSI.Mobile.ActiveSync.Settings.MakePeakTime(TimeToWake);
if(TimeToWake == DateTime.MaxValue)
{
     // The sync settings say that no future days are valid (no sync days)
}
else
{
     // TimeToWake is set to the next available Sync time on or after the passed in value.
}

Project Source and Demo Project:

• GetActiveSyncPeakTimes.zip (10.93 kb)

Most of the time, encryption is useful for sending sensitive data to recipients in a one-to-one relationship. 

We have done this numerous times for clients, with subtle differences in terms of authentication and trust or encoding and error checking or digital signatures.  This simple encrypt-and-send-to-recipient is great when data must be held secret between the source and target.  However, what if you want to encode something so that anyone in a pre-determined list can open it?  We can do this simply by encoding the secret multiple times, once for each receiver.  This is acceptable both in terms of time and space if the secret is small, such as the often-portrayed-in-movies eight digit launch codes to a missile - but what if the secret is significant, like a 5 megapixel spy photograph of the enemy sleeping with the prime minister's wife?

Obviously we don't want to take a 12MB image and encode it 12 different times for 12 different people - as anyone can calculate will result in a file of about 144MB. 

So how can we do this?  NTFS does it.  Outlook does it.  But how?

Well, instead of encrypting the file with each key, let's abstract it a bit.  Let's take some random data and call it a password.  Let's encode the original secret with the random data (password) and then encode that random data (password) with each user's public key.  Now, we only have a duplicate of the significantly smaller random data, and the 12MB secret is still safe and still only 12MB, even though we can decode it for all 12 users.

To decode, we find the random data that we can decode with our key.  Then we take the decoded random data and use it as a password to decode the actual secret.

Simple!

[Edit:  I am debating whether or not to put the source up for this c# stream-derived class, or roll it into a project.]

I have an update, almost an hour after I published the blog entry.  It seems Google has discontinued Dodgeball, Google Catalog Search, Google Mashup Editor, Google Notebook, and Jaiku. 

(See Slashdot, the reference pointing to the articke at InformationWeek)

There are a lot of free web services or web applications being offered on the web.  Whether it is something like mail, maps or communications, these services often meet or exceed personal users requirements.  But how about for business use?  Is it something that should be added to your product?

First of all, read the fine print.  Find out if you are allowed to use the service from a business or for business purposes. We aren't talking about re-branding Google Maps to "My Company Maps" entirely, which is obviously forbidden in the Google terms of use (And every other mapping product's terms of use, of course).  For the purposes of this article, let's assume we are talking about your business adding significant value to the service.  Most public services allow business accesses, but have certain restrictions on number of accesses per day, or size of storage, or something like that.  If the terms meet your needs, remember that they can be changed at any time and that you don't have a permanent right to use their services.

Before you begin any new project around a particular service, you next want to impose some restrictions and drive development in a proper manner.  Make the service as modular as possible.  Instead of hard-coding something to do a lookup with one provider's service only, abstract it enough that you can later field-replace the component should the service be taken down, or allow the configuration in the software.  It is important to ensure that you also monitor the terms of service for the connection to ensure it hasn't changed or to ensure that you or your customers haven't been blocked.  In some circumstances, it may be better or mandatory to have the requests hit your public server and then you drive the connections solely to the public service.  This redirection may allow you to cache data, re-deploy it in another format, but most importantly it allows you to keep statistics to ensure you aren't exceeding the public services terms of use.

Remember also the rule of change.  Things change,  always.  If we talk about mapping software, the providers constantly try to add new features, become higher resolution or something like that.  The law also may have an effect, for example, Google maps has to blur faces.  If your software relied on previous features that suddenly change or completely disappear, you have no recourse and just have to redevelop if you want to keep your products on-line and providing value.

And what if the service is wrong?  What if you ask for a temperature conversion and retrieve an obviously wrong value?  Does your business need to have accuracy or you have to support those errors?  Most of these companies have support for their on-line services, and have invested interests in fixing problems.  Some may only have a window of repair for their next release and you will have to suffer through.  Make sure you have a way to deal with things that they publish that you cannot control.

Can you disclaim this in your software?  I have heard of people adding exclusions in their service agreements for products that state something to the effect of "uses components of xxx public product, which has its own terms and conditions that you also must abide by."  However, if your product is 90% xxx public product, and only 10% stuff you added, you really haven't sold a workable product when the public product is taken down.  Since your product disintegrates, you may have to (by law!) replace the cost of the product for your users.

Is it valuable then to use these services in the long term?  We think so.  At least in the "here and now".  Most companies offering public services track usage.  The more the public use it, generally, the more they provide in terms of support and features.  Only if economic conditions or something drastic occurs will the plug be pulled.  And remember, that plug will effect tens of millions of other users, too.