Interner Technology World - Companies moving into enterprise mobility for the first time often make the mistake of thinking of the mobile platform as “just like the desktop, only smaller.” There are substantial differences between the mobile and the desktop environment. The biggest difference is in communications. The always-on, high-bandwidth communication we have grown accustomed to on our desktops has ushered in an era of thin clients with lots of functionality. Mobile platforms must work in a world of spotty communications — not always available and often very low-bandwidth.
It is a sad fact of life that mobile communications networks are not reliable enough to handle large volumes of interactive data. Anyone who has watched their phone take a few minutes to send a three-line email knows this all too well. Don’t be lulled into a false sense of security because your small pilot application works fine. You have to architect your application from the beginning to deal with spotty cell coverage and high data volumes, or you might have problems getting your app to scale to production levels.
SHH: The secret to a good mobile app is to build it so that it works even if the user can’t get a good signal.
A lot of companies, for example, get themselves in trouble with HTML 5. When faced with developing an application that can run on multiple mobile devices, it is tempting to implement the application with an architecture built largely around HTML 5. After all, the cross-platform mobile environment is what HTML 5 was designed for. Our experience working with our clients, however, is that HTML 5 apps work very well for a small data set or with a small subset of the base of end users. However, as soon as you try to expand the scope of the application, the data volume increases and performance begins to suffer, to the point where it is impossible to use the application remotely.
Many TPC clients have improved the performance of their mobile applications dramatically by storing data directly on the device to ensure the right information is available no matter what happens to the network. Yes, surprise! The secret to a good mobile app is to build it so that it works even if the user can’t get a good signal. Of course, this raises other issues.
With data stored on the mobile device, you will need some way of keeping the information in sync. For high data volumes, you can tune your data fetches to optimize the performance of the application. Maybe the right setting is 50 records at a time, or maybe it is 500. Having data stored on the device means you might not have to ship over all 500 records at once but instead limit it to sending only the five to seven that have changed since the last update.
Don’t assume, either, that mobile users need the same data or the same functionality on their mobile device that they might need on their desktop. In the first place, the users are doing different things, so you need to find out what is most important to give them while they are working on their mobile device. Second, the devices are smaller than most desktops, so you will only confuse them if you try and give them all the bells and whistles of the desktop. Keep your mobile environment simple, both in the data used and in the functionality of the app itself.
Obviously, having data stored on the phone brings a whole set of security concerns, but these can be easily addressed. First, you need to ensure that the data is stored on the device is encrypted, so that it is gibberish to anyone who doesn’t have the key needed to decrypt it. You also need the ability to wipe the mobile device if it is lost or stolen. The SAP Mobile Platform handles the encryption of the data when communicating across the network, and your mobile device management (MDM) solution can handle decommissioning the device or wiping out the data when you no longer use it.
High level: if you want a simple, quick application or one subprocess, then HTML 5 is a good environment and relying entirely on online access should work out fine. It’s great for prototyping. When you’re looking for a more comprehensive process app, then you should add offline capability. Ultimately, the way the SAP platform is evolving, you will be able to implement an offline architecture across multiple platforms very easily.
0 comments:
Post a Comment