Name: Implementing Native Screen Sets in SAP Customer Data Cloud
Uploaded: 2024-5-29
Duration: 369 s
Description: In this video, we will demonstrate how to implement Native Screen-Sets.

Share feedback

<p>Planned maintenance of Practice Systems</p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Subscribe now

Learn more

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div><div><div><div>In this video, we will demonstrate how to implement Native Screen-Sets.</div><div></div></div></div></div></div></div></div></div>

Implementing Native Screen Sets in SAP Customer Data Cloud

In this video, we will demonstrate how to implement native screen-sets.  To start, you can take a look at Gigya’s documentation portal to have a better understanding of the feature, find sample apps and see if this is the approach that you want to use for your next mobile implementations. On Gigya’s documentation portal, you’ll find our client-side SDKs and the links to the iOS and Android platforms.  Open the platform page for more details.  The source code for mobile SDKs and sample apps are open source.  You can find them on SAP GitHub. To get there, you click on Gigya Developer Downloads, and you can see the link to the GitHub repo.  On the Downloads page, under the Mobile SDKs menu, you can choose from the Mobile SDKs and versions.  When you open the GitHub repo link, there you will find the engines for native screen-sets. You will also find our sample applications both for iOS and Android. For example you can see here “example-kotlin”.  Let's look at the Native Screen Sets documentation.  Here you will find all the details you will need from the steps necessary to copy the engine to your project, to how to start customizing the screens. You can find the code snippet for initialization, and how you can start adding the different components into the JSON file. Once you understand the styling options, it is simple to start customizing the screens on the JSON file.  We recommend starting with our sample apps. When you download the repo for iOS or Android, you will get the sample app which already comes with an implementation and a sample JSON file, which is the best way to start with native screen-sets.  We’ll switch to the Android sample app.  You can see that first, there is a call to render the native screen set and specify the route of login upon clicking on an option in the UI.  This is basically all we need to start, with the screen-set.  The name that you see here, “gigya-nss-original” should match one of our JSON files defined in the assets folder.  Let's look at the structure of this JSON file.  At the top, we have an option to indicate that the engine should actually use the schema validation. Then we have a default routing, indicating some default behaviors for our screens.  And then we have an object that defines the different screens. Each of these names would correspond to either a route, which is the initial route i.e. login or how screens can actually route between each other by using a routing element within the object.  So as you can see here, for instance, if a user tries to login and the user’s status is onPendingRegistration, we can take the user to the account-update screen.  On success we want to discard the screen. This is how we define a screen and its behavior. The attribute of “action” defines what the NSS engine should do when the screen is submitted.  Let's go down into the children object. Here we find different components that will be rendered in the screen.  We have a container that can have additional children, like a title.  We have a social button, for instance, for Facebook and for Google. In this way, we can add additional components in a simple JSON structure.  We can also add inline validations, in case there's something not defined or enforced by the Gigya schema.  There are 2 additional files that can help us to keep our project more organized and keep the files smaller.  The first file is the theme file. For the NSS engine to automatically load the theme file, create a file with the same name as the NSS screen definition, and add the “theme” extension to it.  There will be a predefined set of theme attributes as well as custom themes which can be reused across the screen. This allows you to easily and consistently brand different screens, for example you can define an input and say that all the inputs should have a corner radius.  This is very similar to CSS classes used with web screen-sets.  Next, we have the localization file.  It allows us to define different keys which can be translated or specified in different languages and different localizations.  Once we have those keys, for instance, the register-title, they can be used in any component which is using the attribute text key.  So how is the engine going to determine which language we'll pick up?  If we go back to where we were loading the initial route, we could pass a language.  This tells the engine which localization files or keys to be loaded.  So now, let’s see this in action. Let’s see the native screen sets that come with the sample app available on SAP GitHub. You can see the app in the mobile phone displayed on the screen.  At the top, we have an app bar followed by a customized label, three social buttons, followed by two inputs, one of them a password, which has a built-in hint button, and we have a couple of labels, one of them with the capability to link between screens and a button.  Let’s quickly go back to the localization file to see how those links are created.  Basically, we have the text that we want to display on the screen, followed by the routing to another screen. In this case, the routing is to a login screen. So if I go here to register, which will correspond to this key, it will take me right away to another screen.  On the registration screen, you can use containers to display two controls next to each other.  Here the two controls are First name and Last name fields.  And we have here a different approach for social logins. In this case, we have a grid component, which can be customized based on how many columns you need or which buttons you want to render for the users.  This is the experience you will get for the registration and login screens, which come in the sample app.  This wraps up our demo on how to implement native mobile screen sets.  Thank you for learning with us.