Skip to content

Introduction

The SAP Cloud Platform SDK for Android version 3.1 introduces a new version of the flows component. It's implemented with Kotlin and the latest Google Android architecture components, managing the step fragments in a single activity and navigation with Google's Navigation component, sharing data among steps with View Model and Live Data.

The new flows component (flows2) provides a default implementation for your app's onboarding and restoring scenarios. It handles all the necessary steps during onboarding: getting application configuration from either the Discovery Service or by scanning a QR code, authenticating users based on the application configuration, and creating and validating passcodes, for example. These scenarios are based on the existing Foundation and Fiori libraries.

Besides the default implementation, there are also extension points that allow client code to provide its own logic, for example providing additional passcode validation rules, encrypting a local business data secure store with the passcode, etc.

At the same time, all the customization options of the UI are still supported, and additional custom code can be added to flows as well. The flows execute the onboarding and restoring scenarios as a sequential step sequence. Custom code can be added using custom steps added by the app developer.

Installation

To use the Flows component, include the following dependency in your build.gradle.

dependencies {
    implementation group: 'com.sap.cloud.android', name: 'flowsv2', version: sdkVersion
}

Flow Types

The Flows library currently supports the following scenarios (flow types) for onboarding flows implementation, described below:

  • Onboard
  • Restore
  • Change Passcode
  • Reset Client

Each flow contains several steps, and each step can be either a single step or a nested flow that contains other steps. For example, the activation step inside the onboarding flow is a nested flow: it contains the step to get application configuration from the Discovery Service and the QR scanning step. Step organization makes it easier to extend the flows component.

Besides these predefined flows, you can also use the flows component as a framework to create customized flows, as described below.

The Onboard Scenario

The onboarding flow contains the following steps:

  • Activation: The activation is responsible for getting the application configuration from either the Discovery Service or a QR code. This step can be skipped if the client code already provides a complete application configuration from which the flows component can determine how to authenticate users.
  • Authentication: Based on the application configuration, the authentication step will dynamically have corresponding authentication methods in place to authenticate users: basic, OAuth, SAML, or certificate authentication methods, for example.
  • Passcode: After a user is authenticated based on the passcode policy settings for the application, this step will help the user to create a passcode to protect the mobile application. If the passcode policy is not enabled, this step will be skipped and a developer can use the Change Passcode flow to create a passcode using the default passcode policy at a later time.
  • Usage Consent: Usage collection is a feature in Foundation which enables the mobile application to collect various kinds of usage information for analysis. This step will be in the onboarding flow if the developer wants this feature. Note that usage data will only be collected with the user's consent.
  • End Usage License Agreement: This is a mandatory step. The user must agree to the terms of the EULA to complete the onboarding process.

The Restore Scenario

After onboarding, the next time the mobile application starts it will execute the restore scenario. The restore flow will first unlock the application with either the passcode or fingerprint, if enabled. Then, if the passcode has expired, the change passcode flow is executed.

The flows component will automatically determine whether to use onboarding or restore, so the client code can use the same source code for these two flows.

The Change Passcode Scenario

After onboarding, if the user wants to change the current passcode, the change passcode flow can be started. This flow contains three steps: unlock with passcode, set a new passcode, and confirm the new passcode. This flow will also automatically be executed as part of the restore flow if the current passcode has expired.

The Reset Client Scenario

There will be cases when the user wants to reset the mobile client, for example if they have forgotten their passcode. When resetting the client, besides the internal status of the flows component, the client might also have something to clear. And after reset, the client mobile application might also want to open the launcher screen, so besides calling the flow component for reset, the client mobile application should also have a FlowStateListener defined and provided to the reset flow.


Last update: August 12, 2020