Mobilizing field workers with mobile apps, so they can transact in real-time with business systems and data, is proving to be fertile ground for gaining competitive advantage in this digital age. It makes sense, field workers in all of their stripes, after all, are the ones closest to your customers, products, plant machinery and supply chain partners. Arming them with mobile apps ensures more timely and better decisions and actions; key stepping stones to reducing delays and cost, to providing better service, and in increasing revenues.
And while the benefits are clear, the path to achieving effective field mobilization is fraught with complexities and tough decisions that can impact the success of an app and the overall trajectory of your program. How to accommodate offline mobile app requirements is a perfect example of such a challenge; especially in the United States. No matter the region across the U.S., from rural climbs to urban centers and industrial settings, cell coverage is spotty. Spotty coverage is usually worst in centers of business and industrial settings; the very places where field personnel do their jobs. Access to core data and capabilities, regardless of connectivity, is critical to their productivity and success. Ignoring the requirement is the surest way to hurt adoption and undermine your mobile program.
AppGyver has helped dozens of customers navigate these waters around the world. Here are 6 of the most common important considerations customers should think through and get right when building mobile apps with offline capability:
Authentication Matters – solve this by using an access policy that expires or requires re-authentications within 24hrs.
Store data locally on the device in a secure environment. Enable data store limits for rich files like images and PDFs as to avoid data limits. The way to approach this is to enable structured text data stored in a local database on the device. Compression should be applied where possible. With larger files the data store should be updated on wifi only.
Write policy – What happens if there’s a conflict when coming online and a newer version or data update exists? In this sense there are a two good options: first in or last write. Which ever path you chose the user can be prompted upon connection via notification that a newer version of the data being updated exists and that an exception review is required. An alternative approach we often see is to have synchronization rules written specifically on a per-form basis inside the application. In general we do not recommend this. Time and again we see customers fold under the high overhead in maintaining the forms.
Data sync – When should the data sync? When you connect to Wifi or Cell? To maintain security policy data may have to discarded after a particular point in time. The other consideration is data cost on the cellular network. However, that must be weighed against productivity loss and should be a setting inside the application itself.
Which platforms do you need to support? This can be costly without cross platform tools. For field extensions of core apps wide platform support is required. The maintenance costs of three or four different platforms for one use case can run into seven figures. Offline support is handled differently on each native platform so unless you company is running only one specific device keep in mind that costs can quickly run over budget.
Lastly, and most importantly, what are the bare minimum requirements that the app needs to perform. The lighter you can make the application the less time you have to think about write policy, file storage limits and time to market.
With AppGyver’s Rapid Application Development Platform companies build powerful offline apps that connect securely to your core business apps like Salesforce, SAP EAM, IBM’s Maximo and Oracle in a matter of days. See how we cut cost and improved development time for Mitsubishi by months using our reusable cross platform technology.