05.11.2016 UI/UX 0 Comments

By nature, most mobile applications are clients for backend services. They request data from the backend on users behalf, send the data back for update or delete operations. In todays IoT world, when even your fridge can be connected to the Internet, it is not a common case for a user (or app) to be offline or to work offline. But there are certain cases, when the connection could drop, or the user is in such a place where there is no network coverage (underground, high in the mountain, remote areas, security/protected facilities, etc.). Do your application really needs to be connected to the Internet all the time? And isn’t it a bit inconvenient for the users if you are not allowing them to use the app offline?

Think about any of these scenarios:

  • The mobile app perform a request and receive some data as response from your backend service. Let the user be able to store this data and to modify it later, while she is offline. Provide the users ability to synchronize the data when they are ready or when they are online again.
  • Let the users be able to create new data while they are offline and to synchronize with your backend later.

Real life example:
The backend API is about real estate classifieds and it’s a RESTful API, exposing various end-points to its clients (websites, apps, other APIs, etc.).

  • The real estate agent should be able to visit the property, to take photos, to fill-in a form for posting a new offer, to assign the photos to that offer and to save the data on her device. She can do it while on site or on her way back to the office. Whenever she is ready, and there is an Internet connection, she can send (post) all the data to the backend API. At that moment the offer will be published. You are helping your user to boost their productivity by not wasting time while in transit or in remote areas without network coverage.
  • The same real estate agent already has some offers posted, but they know the data needs to be updated. The user can download selected (multiple) offers to their device. They can change the data, edit the text, check or uncheck any form controls. All these operations could be performed offline and when the user is ready, they can send the data back to the service.

Important notes:

  • Local data store. Are you going to relay on localStorage or you’ll be using more sophisticated solution such as LokiJS, its a decision, which needs to be taken individually, on per project basis. Usually it depends on security level and storage reliability.
  • Data access. You need a way to prevent data to be overridden by other users. A lock flag or anything related to read/write access to the data downloaded for offline usage.
  • Endpoints structure. Are your real estate offer endpoint able to handle all the related data, or there are separate/individual endpoints for editing the offer description, offer images, categories, etc.? Sometimes you may need to track individual changes and when synchronizing the data, to perform multiple POST/PUT requests, instead of only one. Software (web service) architecture is very important here.


Submit a comment