SAP Cloud Platform SDK for Android, version 2.0 is here!
Time flies when you’re having fun! This is especially true when one is on the Android team here at SAP. It seems like only yesterday that we announced the general availability of the SAP Cloud Platform SDK for Android. You might think that after all that hard work, we’d take some well-deserved time off, basking in the glory of our accomplishments. But not this team, they NEVER rest. As soon as version 1.0 hit the market we immediately went back to work on version 2.0.
Today, I’m happy to say that version 2.0 of the SAP Cloud Platform SDK for Android is generally available! Let’s spend some quality time getting to know the new features of the SDK, shall we?
Enhancements to the SAP Cloud Platform SDK for Android wizard
The SAP Cloud Platform SDK for Android wizard, a feature of the SDK that I introduced here, has received quite a few improvements with the 2.0 release (even though it was already awesome). Let’s take a look at the highlights.
Kotlin Language Support
The headline for a recent ZDNet article says it all – “Microsoft’s GitHub: ‘Kotlin for Android now fastest-growing programming language’.” Simply put, Android developers are using Kotlin for their Android projects at a rapidly increasing rate. While the SAP SDK has always supported Kotlin as a programming language, the 1.0 wizard created ready-to-run Java projects only. With the 2.0 release, developers can choose the target language – Java OR Kotlin. This enhancement underscores our commitment to supporting the developer language of choice for their mobile app development project.
While network connectivity is profoundly more reliable now than it was even a few years ago, there are still many scenarios where devices can’t (or aren’t allowed to) connect to a wireless network. There are other cases that, due to the volume and/or change rate of data being accessed, it makes more sense to lookup data locally regardless of the network state. To address both of these scenarios, SAP Cloud Platform Mobile Services provides the Offline OData feature. This blog would be waaaay long if we went into detail on all aspects of OData, but you can go here for an introduction. To learn more about the implementation of OData in the SAP Cloud Platform SDK for Android, I recommend starting here. And finally, to learn about Offline OData, here’s a great resource to get you started. If a tutorial is what you’re looking for, feel free to jump right to the SAP developer site and try out Dan Van Leeuwen’s tutorial Offline Enable Your Android Application.
With the 2.0 release of the SDK, the wizard now presents the developer with the ability to specify the operating mode for their mobile app – online or offline. This simple choice triggers the wizard to automatically generate boilerplate data handling code on behalf of the developer. For an offline app that includes:
- Initialization, creation and population of the offline store
- Default actions to upload pending modification requests from the client to Mobile Services (and ultimately the backend) as well as to refresh downloaded data.
Talk about a productivity booster!
Refactored Generated Code
One aspect of the wizard generated code that I thought could be better handled is extensibility. Let’s be clear – what you get from the wizard is a standard Android Studio project, nothing proprietary here, so of course it can be extended. But it’s not easy as it could be. Several changes have been made to the wizard to facilitate project extensibility and to be more in line with Android development best practices. One aspect I immediately noticed when working with the 2.0 SDK was the implementation of the model-view-viewmodel pattern and the creation of specific activities/fragments for each entityset returned in the OData service’s metadata.
Additionally, and as part of the implementation of this software pattern, we will implement NavigationProperty elements of an EntitySet in the generated UI. For example, a SalesOrderHeader will have one-to-many SalesOrderItems, the wizard will generate the code to implement this navigation.
Client Usage is part of the Foundation layer of the SDK. If you’ve listened to me talk about the SDK in general you’ve probably heard me say that the Foundation layer is focused on the “iceberg” aspect of your mobile app. It handles everything in your app that your user doesn’t necessarily see, but that are critical for enterprise readiness, security and supportability. I personally think that Client Usage component is one of the features of the Foundation layer that provides the most insight to the app developer. The SDK provides means to acquire user consent and to subsequently provides granular app usage information back to the developer. What views are accessed, by what types of devices, how long the app runs and what actions the user takes are just a few of the many pieces of information that can be gathered. With version 2.0, we can automatically generate a sample consent screen, track basic usage information (the activities and data that are accessed and the type of device) and enable the user to upload usage information to the server for analysis. Developers can extend or adapt this framework at their discretion, with ready-made working code to use as a guide.
It is important to understand that SAP provides the necessary tools for a customer to build an app that is compliant to any specific regulations. It’s up to the customer to use those tools and claim compliance.
To see a demo of the new features related to the SAP Cloud Platform SDK for Android Wizard (and a basic end to end demo), check out this short video.
Integration with other SAP Cloud Platform Services
The SDK exists as a feature of Mobile Services, one of many services that exist in SAP Cloud Platform. The value of the platform as a whole comes from being able to leverage each service for what they’re good at; you weave services together into the fabric of a business solution. With version 2.0 we are extending an Android developer’s ability to leverage two SAP Cloud Platform services directly from Android Studio.
SAP API Management
Most of us have heard the term “Data is the new oil,” a phrase generally attributed to Clive Humby. But what good is data (or oil for that matter) unless there is a reliable way to get to it? APIs provide the language for systems to communicate, for information to be shared, for data to be accessed. To me, APIs are just as important as the information they expose. With that in mind it’s no surprised that just like data, APIs need to be managed. APIs need to be discoverable, consumable, shaped, productized, operationalized, analyzed and even monetized. SAP Cloud Platform API Management provides these services, enabling enterprises to publish, promote, and oversee APIs in a secure and scalable environment.
How does this apply to the SDK? Consider this – what good is an API if a developer doesn’t know how to find and use it? With version 2.0 of the SAP SDK, the wizard can now connect either to the SAP API Business Hub or an API Management developer account, enabling simple discovery and consumption of any OData-based APIs exposed through the service. From there, the wizard takes over, generating proxy class code and a user experience based on SAP Fiori for Android.
To see a demo of the integration of SAP API Management into the SDK wizard, check out this short video.
SAP Translation Hub
I’ve worked in a virtual office for almost 20 years. It started that way because I performed a more customer facing role, but by the time I transitioned to product management there were so many effective collaboration tools available that there was no need for me to relocate to work in a physical facility. I suspect I am not the only one at SAP who does this. We are a global company, and chances are the people you are trying to reach are also often globally distributed. To quote this video, “a globally successful app must speak to a global audience.”
How do you make a connection with a global community of users with your mobile app? Okay, perhaps that’s a bit outside the scope of this blog, but perhaps you can start by speaking the language of the user.
But too often, localization of an app is handled as an afterthought. It’s not budgeted appropriately, it’s started very late in the app lifecycle and is often slow and error prone. SAP has 50 years of localization experience. Wouldn’t it be nice if you could take advantage of all the work we’ve done to simplify the translation effort for your project? Well of course you can by using SAP Translation Hub, an SAP Cloud Platform Service that allows you to develop using one language and quickly translate your language resource with just a few clicks. With the release of version 2.0 of the SAP SDK, you can access SAP Translation Hub directly from within the confines of Android Studio. As a developer building an app for a global audience, you can localize your mobile app to a variety of languages and even choose from a series of business domains to refine your results – all without leaving your development tool.
To see a demo of the how SAP Translation Hub can be used with an SAP Cloud Platform SDK for Android project, check out this short video.
Other really cool and amazing innovations
I’m so excited about this feature; I really hope I can communicate the value properly here. The process of onboarding a user to a mobile app and a mobile app to the appropriate Mobile Services account can logically be broken down into a series of sequential steps. Display of a welcome screen, bootstrapping app configuration, authenticatIon, settings download, app passcode creation, prompting for a EULA…while not all of these steps are always implemented, they’re pretty typical in the app onboarding process. Currently, the SDK wizard creates code for all these steps; for apps created without the wizard, the developer is left to rely on the documentation. And the truth is, while the onboarding process is necessary, it isn’t really all that related to the solving a business problem.
Enter Fiori Flows. With Fiori Flows, the developer is responsible for the initialization of a FlowManager service, then choosing from a predefined set of onboarding steps (such as a EulaScreenStep, PasscodePolicyStoreStep) and adding them to a Flow object. The FlowManager then executes the newly created Flow, calling each step in sequence. If you are satisfied with the step execution as-is, you don’t have to do anything else, each step has a default implementation. The FlowManager has an onSuccess callback that basically tells the developer, “okay, we’re done onboarding, where do you want to go”. Here’s where you’d probably start the activity that defines the business context of your app.
The SDK wizard is awesome in that it generates code that enables the end-to-end onboarding flow. But that code is still code you have to manage and maintain and could be thought of as “noise” around what’s important to you – the code that supports the business case. Using Fiori Flows even in the wizard minimizes the code footprint in the resulting app that you are responsible for managing. While we won’t get Fiori Flows integrated in the wizard with the 2.0 release, look for that to happen some time in the near future.
And while I’ve talked mostly about Fiori Flows in the context of onboarding, many of these steps can be called in the context of a restore, reset or change scenario. If the step should behave differently based on the scenario, this is handled automatically.
Fiori Flows are awesome.
SAP Cloud Platform Mobile Services provides many Mobile App Management features as part of our app services portfolio. These services are implemented both on the admin side and by our SDKs and pre-built clients (SAP Mobile Cards, the mobile development kit client, SAP Fiori Client, etc…). A key feature of app management is the ability for the solution to support temporary (or permanent) blocking access to the backend and in more drastic cases wiping app data and/or blocking app access. The Blocked Users feature of Mobile Services has always been supported by the SDK (resulting in a 403 error for data calls), but with 2.0 we provide a BlockedUserInterceptor and a callback so that developers can intelligently handle traffic blocking separately from other app authorization errors.
Similarly the 2.0 SDK provides support for consuming the Block/Wipe Setting (delivered as part of the Client Policies feature), along with callbacks to handle when the time thresholds for taking action have been exceeded. The developer can then implement the callbacks and create a self defending app.
New SAP Fiori for Android controls
Much of the work on the UI side of the SAP SDK has been supporting one of our favorite customers, the mobile development kit team. They are hard at work too, and you have primarily web developers but want to deliver a native experience to your end users, the mobile development kit might be your thing. Create the app once, deploy it to an intelligent runtime as metadata, user experiences a native Android app that displays SAP SDK UI controls. We just recently launched support for Android and continue collaborate closely. If you’re interested in using mobile development kit, check out Don Coops blog “Expanding mobile development kit to Android.”
For those of you using the SDK directly, we did add two new controls for your programming pleasure:
- Collection View – The Image Collection control is a horizontally scrolling control that is ideal for displaying information where an image is the most important piece of information in the control.
- Scan Button on Simple Property Form Cell – The Simple Property Form Cell represents a key value cell in which the value is a single line editable text field. With version 2.0 of the SDK we added a new attribute that supports, by default, a barcode scan event.
Where to get the SDK and more information
There are two ways to get access to the SAP Cloud Platform SDK for Android 2.0. Trial customers (production customers too) can download the software from the Trial/Downloads site here. Production customers can additionally download the software from SAP Support Portal under “Download Software“. One additional channel that you can use as a production customer is SAP Cloud Shipment. The Android SDK is the first mobile component on the SAP Cloud Shipment channel; you can learn more about it by reading Michael Jess’ blog – “Cloud Shipment: A small step for us, but a huge leap for the community.”
There are also new and updated tutorials! Visit the SAP Cloud Platform SDK for Android topic on the SAP Developer Center to check out the updated content, including 3 new tutorials (SAP API Management, SAP Translation Hub, Fiori Flows).
Of course there’s no way I could cover everything in this blog, there’s simply too much. Too much I tell you! For a complete list of all the new features in SAP Cloud Platform SDK for Android version 2.0, check out the What’s New section in the official product documentation.
Until next time, happy coding!