Fiori Mobile: Design notes
Offline
If an app is to support offline use, it must be in the design from the very beginning. It is not something which can easily be added later on.
SAP’s recommended approach for Fiori web apps is to make the front end (UI5 app) as simple as possible by pushing complexity into the OData service. One advantage of this approach is that changes to the business logic do not require changes in the front-end code. One disadvantage is that it makes it hard to later develop an offline version of the app, because that app must be able to operate without the OData back-end.
Many such OData services do two jobs at once. First, they read business ‘rules’, e.g. a status profile which states that if an order status is Awaiting approval, allowed new statuses are Approved and Rejected. Second, they apply those ‘rules’, simply returning to the client that the allowed statuses for order 123 are Approved and Rejected.
For an offline app we might design the OData service such that the rules themselves are returned (job 1) but the client must have the logic to apply them independently of the backend (job 2). In this way the rules can be changed without changing the client application, but the client can still operate without the OData backend. To continue our example, the client would be able to handle applying multiple changes to the order status during a single period away from the network. At each new status the client would ‘know’ which statuses are allowed next.
Flexible apps
You should consider designing your app in such a way that it can run both as a Fiori web app and as a Fiori Mobile app. This gives great flexibility in terms of how your users consume your app. It also makes it much quicker to develop and test your app, because you can code much of it running as a web app (in a browser). Remember that changing a line of code, re-building a mobile app, downloading and installing might take 15 or 20 minutes. If you can run as a web app you can test your work much faster.
There is the companion app, but that didn’t work for us. We’ve been told that it doesn’t support offline apps.
How does one design for such a scenario? Consider the following example. An offline-capable product-lookup app is required. Whilst online (with network coverage) it will download all of the products to the local database. This happens automatically when the offline store is created (if the store was declared in the manifest). Then, when offline (no network coverage), the user will scan a product ID and the relevant item must be retrieved.
To support this we only need implement the query (e.g. GET_ENTITYSET) method of the OData service. The app will include a read of the single matching entity from the OData service (e.g. GET_ENTITY), called when the user scans the product. However, in practice this request will never reach the OData back-end (e.g. SAP NW Gateway). Instead it will be fulfilled from the local database via the offline OData plugin.
Now if we ran the app in-browser the query method would never be called, because there is no offline store to initialise. When the user scanned a product the GET_ENTITY method would be called and the request would now reach the OData back-end.
Each scenario requires the implementation of one of the two methods in the OData backend. If we plan from the start to implement both….then we have a flexible app which can run as a web app or a mobile app all from a single code base. Happy days!
You can easily add logic to consider which mode the app is running in. If you need to optimise the web app OData calls, for example, you could create an extension of the main project and then run that one from the Fiori Launchpad for online users. We no longer have a single codebase, but the extension only contains the ‘deltas’, not a complete new app.