Name: Viewing the Native Screen-Sets Features in SAP Customer Data Cloud
Uploaded: 2024-5-29
Duration: 321 s
Description: In this video, you will see the features offered by Mobile Native Screen-Sets or NSS.

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, you will see the features offered by Mobile Native Screen-Sets or NSS.</div></div></div></div></div></div></div></div>

Viewing the Native Screen-Sets Features in SAP Customer Data Cloud

In this video, we will see the features offered by native screen sets or NSS.  Let's start with the difference between native screen sets and web screen sets. Web screen sets allow you to build the screens and carry the functionalities that come out of the box with SAP customer data cloud into the mobile app. However, this may not be necessarily the best experience that you can offer in a mobile app. CDC Mobile SDKs present social login and handle two factor authentication. However, all these screens have to be implemented natively. All the interactions between the different inputs, the forms and the components had to be written explicitly to interact with the mobile SDK. With native screen sets, a simple JSON file compiles into cross-platform natively compiled CIM screens. We define the screens, behavior and styles  and JSON Mobile SDKs generate the native screen sets for both iOS and Android platforms. Let's jump in right away into some of the core features offered by native screen sets.  Let's start with initialization. First, set up your environment and download the sample app that is offered in the SAP GitHub to initialize the native screen sets flow provide a JSON as an application asset. It has two basic elements. First is the JSON file to load the screens, and the second is the initial route to present to the user. In this example, it is a register button in your native application. Now where do we define this JSON file? There are two options. The first option is the native screen set editor in the CDC console. You can access this Editor under the screen set section. The other option is to go directly to the development editor. Let's say X code of Android. And using our sample app, you can just start editing the JSON file right there. You can find more information on the basic attributes and the styling in our documentation. Let's jump into the actual functional features. The first one is automatic screen routing. This is a core feature of the web screen sets. It is the ability to determine which screen to show once an operation is complete. For instance, after a user completes registration you want to show the profile screen. This feature is also available in native screen sets where you can also define different routings for error handling scenarios and alternative flows. These routes are defined in the JSON file to make sure you contexts that creates a continuous flow of screens.  How do we create these beautiful interfaces? A set of components are offered by the NSS engine, like screens, inputs, images, checkboxes, and much more. These components render native components in the app and our platform aware.  One of the features that the web screen sets currently offer is the two-way binding to the schema. It maps all the different controls to schema fields in SAP customer data cloud. The same functionality is available and the native screen sets. The two-way binding is one of the biggest differences and advantages over trying to create a mobile native implementation from scratch.  What about social login? NSS offers two components to implement a native social login experience, as well as a line with all social provider branding guidelines. You can see here what we call the grid social login buttons. These buttons already encapsulate all the logic required when someone presses on the Facebook or Google button. It encapsulates all the complexity of interacting with Facebook, Google and WeChat libraries. We just need to define in the JSON file the component to expose and make the corresponding configurations on the social provider app.  Next is styling. We get a different experience on the screen depending if it's on iOS or Android. Native screen set components are aware of the material design and Cupertino branding guidelines for the two platforms. The components and styling properties allow us to match the corporate branding. Some of the attributes that the components offer are listed here.  Schema validation is another feature that is present in web screen sets and now available in NSS. The NSS engine retrieves the schema validations from CDC and enforces these validations on your mobile screens. You can also add validations at the JSON level, such as required field or a regex JSON level validation overwrites what we have in the schema.  Let's talk about localization and translating screens. You can define a localization file with different languages and translations for the UI. On similar lines, you could also create a theme. In the theme file, define the basic styling attributes such as primary color, secondary color, or text color, and custom attributes, which are very similar to CSS classes. These classes could then be applied and reused across different screens of the native screen sets. These were some of the core features and functionalities of native screen sets.  Thank you for learning with us.