Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 





It’s finally here: Mobile Cards for Android. For the past year and a half, Mobile Services has been solving a big problem with a simple solution: moving all the web content you want into an app, all without your organization having to do any coding. This content could be anything: a SuccessFactors pay check, a leave request or even the weather for the day.





Today’s users are used to interacting with their data in native apps tailored for their phones. Mobile browsers aren’t enough anymore, and it isn’t just about pretty, native- looking buttons. Web browsers are limited by a real problem: they’re slow.

Mobile Cards (formerly Content to Go) has been saving iOS users from web browsers for over a year and half. Now, at long last, SAP Cloud Platform’s many Android users can enjoy the same effortless mobilization.

Under the hood, Mobile Cards for Android is similar to its older iOS sibling, but its user interface is pure Android. From floating buttons to Android’s classic two-color palette, the new app uses Material Design’s visual language throughout every screen.

In addition to using Android’s latest graphic design principles, Mobile Cards uses some leading-edge Android engineering. First, RecyclerView. As you might expect, RecyclerView, well, recycles views. If you have a list of ten items and each item is just a couple words of text, you could just maintain ten items in memory all the time, even if all ten don’t fit on screen at once. But what if you have fifty images in a list? Keeping all of those in memory would mean using a fair bit of memory.





Android provides a solution: RecyclerView. Instead of keeping all fifty items in memory, it only keeps the ones on-screen in memory. When a view goes off-screen and another comes on-screen, it reuses the old view with the new view’s data, instead of creating a new view.

RecyclerView is more flexible than ListView and GridView, which it replaces. Developers can use RecyclerView to display a list, a grid or deck of cards; an app could even use RecyclerView to display views in a scrollable spiral. A customizable layout manager controls how views are presented, and RecyclerView handles the recycling and memory management.

Another state-of-the-art framework is Firebase, Google’s backend infrastructure solution. It can give developers everything from backend servers to analytics. Mobile Cards uses it to easily send push notifications to Android users. The Cloud Platform Mobile Service sends messages to Firebase, which sends the messages to Android devices. When the app receives a message, it interprets the message and acts accordingly. This could mean downloading new cards from the server or telling the Android operating system to show the user new notification.

Showing lots of images efficiently isn’t easy; Mobile Cards employs some simple but useful engineering to show a slick custom layout without using too much memory or over- working the rendering thread. Either of these could lead to janky user experience.










The first optimization is the simplest: minimize overdraw. Complex layouts, like an image view inside a scroll view, itself inside a custom layout, all wrapped in another outer layout, can make Android waste resources by drawing a view that the user will never see. For example, imagine a layout that should have a red square filling the top half of the screen and a blue square filling the bottom half. A layout with red square filling the entire screen and a blue square covering the bottom half of the red square would be wasteful. The system would draw the bottom of the screen twice, once in red and again in blue. Mobile Cards’ layouts are carefully designed to be as flat as possible.

To speed up rendering during scrolling, RecyclerView provides a pre-fetch API. Mobile Cards uses this to prepare the next card while the rendering thread is drawing the current card. By preparing the next card on the UI thread while the rendering thread renders the current card, we save time in each frame and help to create a smooth experience for users.

Finally, Mobile Cards limits the memory footprint by maintaining only the necessary segment of each card at a given time. Full cards are pre-loaded when the user taps on a card and displayed when the card is selected and fully visible. Only the upper, visible part of unselected cards are kept in memory.

Mobile Cards is a simple solution to a major user experience hurdle; it enables user to see all of their SAP-backed content in a native app. Of course, this project wouldn’t be complete without an Android app to match its iOS forerunner, and the Android app completes the project, using the latest in Android UX design and engineering.




1 Comment