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!
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.
Congratulations on going live with your first mobile app built on Fiori Cloud. Thanks for sharing all your notes 🙂 Very helpful for people looking to do the same. Cheers
Thanks for sharing the content .
Do we need to have licensed edition of HCP to build or mobile Apps or we can use trial account to build component and then deploy that on to server on premise and move it to staging using transport.
As in your blog also you have mentioned that you can build your own App using trial account .
In general you don’t need SAP Cloud Platform in order to build mobile apps. You can use the SAP Mobile Platform (SMP) on-premise. Of course you could use a non-SAP platform too and just connect to your back-end systems via OData.
For Fiori Mobile apps you do need to have a productive Cloud Platform account, because you trigger the build from Web IDE. I believe that you also need to be using Cloud Platform Mobile Services (CPms) rather than SMP. The Fiori apps you are packaging can be deployed either to an on-premise Fiori Launchpad (e.g. on a Gateway Hub) or to a Cloud Platform portal site (‘Fiori Cloud’). That’s the only Cloud Platform part which is optional.
If you don’t have a Cloud Platform account and you want to develop a hybrid mobile app you could always install the Hybrid Application Toolkit (HAT) locally and use it with SMP.
Another technology to look into is the SAP Mobile Development Kit (MDK) which was formerly known as SEAM. That is another way to build cross-platform apps.
Hope that answers your questions
can you share the links on how to develop hybrid mobile app by installing HAT locally and use it with SMP?
Hi Kaleem, please the update I've made to the top of this post
For local install HAT I suggest you look at Daniel Van Leeuwen's series:
Getting Started with Kapsel
I would think very carefully before taking this approach. Cordova is very mature but I don't think it will see much focus from SAP in the coming years. Have you looked into the Mobile Dev Kit (or MDK)?
I am creating ESS and MSS hybrid apps, I am new to mobile development, How do we enable SSO via an IDP server for all users using the hybrid apps created in web ide full stack? We are not supposed to use the cloud, can we still use the cloud platform subscription to build the hybrid app?
If you build an app using this architecture all of the calls will be routed via SAP Cloud Platform Mobile Services. So, you can't use this approach if you can't use the cloud. That said, the data don't necessarily have to be persisted on Cloud Platform. They will be if you use features like calculating deltas or declaring entities as 'shared'.
Regarding SSO you would link your cloud platform account to your IDP and then all requests (apart from things like the SAP CP cockpit) will be redirected to your IDP for authentication.
This blog, which is about using ADFS, should give you an idea about how it works:
I hope you're able to use Cloud Platform soon, otherwise your options will be very limited in my opinion.
Thanks for the information,however for a usecase like
User A using the hybrid app(ex:Create Leave request) opens the app and it gets directed to idp server and on entering the credentials, can we fetch the startup parameters(jQuery.sap.getUriParameters().mParams) like personal number from the response token?
Right now, the hybrid app which I have created is using the credentials used for the destination specified for back-end for getting the startup params, which I want to get it from the logged in credentials of the user via idp server.
Great blog Mike!
Agree on your sentiments on Offline OData - setting it up is easy, but error handling can get tricky since standard APIs for errors seems to be lacking. The authentication/registration lifecycle is something that can also be improved.
That said, the process of developing hybrid apps has improved significantly with Fiori Mobile and I'm looking forward to future releases.