So in today’s blog that continues our Mission Critical Mobile Solutions series, we’re going to de-focus on the hardware & support elements and instead take a look at the mobile software side of mission critical. Being “proper mobile” is an area that we see every day where applications and Windows Mobile software often simply miss the point and make the everyday mobile solution a pain to work with at best or even seriously hampering the business at worst. I thought I’d do this by means of the Top 7Mobile software cahooners I see here practically every month.
Top 7 Mobile Software Cahooners!
1. Poor Connectivity Management
People who write websites think they can just go ahead and use .NET to do mobile stuff. Whilst technically this is one of the benefits of using Microsoft technologies to program with, the mobile scenario in general is very different. If you don’t manage your GPRS, WiFi and Ethernet connections properly you’ll get all kinds of battery issues and data corruption issues too and your code needs to take in to account that a Rugged PDA is only occasionally connected to the Internet.
2. Non existent battery management
Ditto for the above but with the battery. No screen brightness management, not taking into account the sensors the device gives you and generally doing nothing to extend the life of the battery at all can often be the difference between a great business solution and a really poor one that costs you time and money needlessly.
3. PInvoking for the hell of it
I don’t know why we see this so much. Perhaps some programmers are just stuck in their old C++ ways, perhaps its programmers trying to look clever or make themselves more indispensable or perhaps it’s simply some software houses trying to lock customers in some how. Pinvoking (for those that might not know the depths of mobile programming!) is where you venture outside of Microsoft’s .NET safe and managed code area and you talk to elements of the device directly. It’s good if you need to do something that .NET doesn’t let you do, but it does often lock you in to using a particular device as they all implement low-level areas differently. We see a lot of software doing this where it simply doesn’t need to which makes support harder, the device choices more difficult and generally the business suffers from it. It’s definitely a case of why complicate things?
4. LCD and Screen
Screens change all the time and it’s easy now to develop for different screen sizes and resolutions so you can be multi device compatible or just move from one resolution to another, especially when moving from QVGA to VGA, there’s no excuse really. Make sure your software is as flexible as it can be for different screen sizes or the solution finds it really difficult to swap out hardware or run multiple devices.
5. Barcode and RFID Scanner usage
if you want fine control of your scanner then use the SDK that comes with the device, if you want device portability then you have to do it in other ways, Simples!
6. General lack of SDK and Rugged PDA Persistent storage usage
following on from the above, general use of the SDK and the special persistent and boot areas that rugged PDA’s offer shows a complete lack of Mission Critical understanding when it comes to programming. We see solutions that give major problems that would never have occurred if the devices SDK was used correctly or at all.
7. RFID implementation
We see so many people come unstuck here as RFID has become more and more popular. A simple lack of appreciation of the tag you are using can be critical in building a robust mission critical solution. There are countless tag memory structures, read/write types and general data structure formats so make sure you know what you are dealing with and then use the tag in the right way.
That’s it for software, we’ll continue tomorrow and up until the end of the week!
The Rugged and Mobile blog.