Fiori Mobile: Overview

UPDATE January 2019: Fiori Mobile has been deprecated.  There is a another way to cloud-build hybrid apps, the so-called ‘mobile services’ approach which is explained by Ludo Noens:

Creating an Offline CRUD hybrid mobile app in SAP Web IDE Full-Stack with Hybrid Application Toolkit

I’d also recommend this series from Greg Cariño:

Let’s build an Offline Hybrid UI5 Application from scratch – Part 1

A few weeks ago we went live with a mobile app built using the Mobile Service for SAP Fiori (a.k.a. Fiori Mobile).  I wanted to share my experiences as well as giving some practical tips and also making some suggestions to SAP for new features and improvements.  I’ve also written some notes about designing a Fiori Mobile app.  To begin the story we need a little background….

What are hybrid mobile apps?

Hybrid mobile apps can run on any of the mobile platforms (Android, iOS, Windows etc.).  In essence they are a web application wrapped up their own browser.  The big advantage of a hybrid app is that it has a single codebase, whereas a native app must be re-written for each platform (in order to keep things brief I won’t discuss other approaches, like Xamarin or Progressive Web Apps, here).

Apache Cordova is an open-source framework for developing hybrid apps.  To use native features (beyond those already available via hmtl5) apps can make use of plugins.  These plugins handle the platform-specific code and are available for one or many platforms.  Plugins are available to access the GPS, accelerometer or camera, for example.

SAP have written their own plugins, branded as Kapsel, to handle things like logon and offline OData.  These bring an enterprise flavour to hybrid apps.

What is Fiori Mobile?

Until recently SAP’s recommended approach was to use the Hybrid Application Toolkit (or HAT) in order to build hybrid apps. The app build took place on the developer’s PC or Mac.  The HAT gained a reputation for being tricky to set up and that hindered the use of hybrid apps within the SAP ecosystem.

Fiori Mobile has at its core a cloud-build service, so there is no need to install the HAT.  We can trigger the build from Web IDE.  We specify the (already deployed) Fiori app(s) that we want to package and after a few minutes we can download the .apk (for Android) and .ipa (for iOS) files ready to be installed on mobile devices.

Why should I use Fiori Mobile?

Regular Fiori web apps (running in a browser) are great.  There are many things you can do with them and they can run on any device with a suitable browser.  It’s also easy to push out new versions of your apps.  However, there are some features which aren’t (currently) possible with these web apps.

One example is offline OData.  If you need your app to work offline (using SAP Cloud Platform as ‘middleware’) then you need either hybrid or native mobile apps.  If you need to write-once for multiple platforms then hybrid is the way to go.  And if you need to build a hybrid app Fiori Mobile is now arguably the easiest way to do it.

Indeed Fiori Mobile has a great advantage which hasn’t really been discussed much.  With careful design it’s quite possible to use a single code base for both web and hybrid versions of your app.   Why not let your users choose what works best for them?  If they need to work offline they can download the hybrid app.  If they want to work on a PC or Mac they can use the web app.  Or perhaps they don’t want to or aren’t allowed to install an app on their mobile device.

Note that barcode scanning doesn’t require hybrid or native apps.  A regular Fiori web app can do this if it runs in the Fiori Client.  Further, Ian MacGregor recently wrote about how scanning can be done in-browser.

Does it work?

In my experience the cloud build service works well.  Without any fuss it typically builds for both platforms in about 8 minutes. There have just been a couple of occasions when I haven’t been able to build due to technical problems.

There are some facets to the technology which don’t feel mature yet.  One area is the offline OData features.  When using Fiori Mobile things work differently to the more conventional hybrid and native apps.  One example would be the destinations, because Fiori Mobile apps use a generated destination which references the SAP Cloud Platform (CP) portal service.

My point is not that offline OData seems immature, rather that the offline features can be tricky when used with Fiori Mobile apps.  We are still receiving assistance from SAP to get the offline features of our app optimised.  This is a shame, because shared data and the handling of delta requests, for example, are two features which justify the ‘middleware’ approach to offline that SAP have taken.

Authentication has also been a challenge.  On a previous project I used the Fiori Client in conjunction with SAP Cloud Identity (now officially SAP Cloud Platform Identity Authentication).  The Fiori Client stored the username and password on the device so that the user didn’t need to enter them every time their session timed out.  We haven’t achieved that yet with our Fiori Mobile app.

Wouldn’t I be better off with a native app?

Native apps will always give the best performance, because they are rendered at a lower level in the stack rather than running in the browser.  In addition, all hardware features can be accessed, whether there are Cordova plugins or not.  That said, I was surprised at how good the performance of our Fiori Mobile (hybrid) app was.  As mobile devices get better each year in terms of performance, the difference in User Experience (UX) between native and hybrid gets smaller in absolute terms.  The question is not ‘is native better than hybrid?’ it’s ‘is the difference in UX noticeable enough to justify the increased cost of native development’? The increased cost comes from having to develop Android and iOS versions of the same app.

This debate was covered nicely by Robin van het Hof in this blog (with an interesting comment by Former Member).

What are you waiting for?

If you need mobile app features like offline OData you should definitely look into Fiori Mobile.  You can even build apps on a trial account.  Perhaps all of your needs can be met by a combination of Fiori web apps and Fiori Mobile apps.  You can standardise on this one platform and concentrate on UX.  Happy days!

Further Reading

Design notes

Practical tips

Comments and suggestions

Resources

Acknowledgements

I’d like to thank my teammates Former Member and Luke Phelan.  It was great working with them and many of the solutions I have discussed here were worked out by them.

I’d also like to thank Britt Womelsdorf, Mark Wright and Matt Borges at SAP for their assistance and guidance.