openSAP

Building Mobile Applications with SAP Screen

Personas
Week 2 Unit 1

00:00:09 Hello and welcome to week two, unit one, of our openSAP course, Building Mobile
Applications
00:00:14 with SAP Screen Personas. My name is Vandana Deep.
00:00:18 Last week, we gave you an introduction to building low-code applications using SAP Screen
Personas,
00:00:24 we discussed the architecture of Slipstream Engine, and then we shared some best
practices for planning
00:00:29 and designing your mobile application. We ended the week by showing you how to use
00:00:34 SAP Screen Personas Editor in Slipstream Engine to create a simplified flavor.
00:00:40 This week, we will begin by extending the simplified flavor to create flavors
00:00:44 for different device sizes. We will then show you how to enhance the flavor
00:00:48 by adding native device capabilities and how to achieve a consistent layout
00:00:53 across all the screens by using templates. After that, we will introduce the concept of
viewports,
00:00:59 and how they can be used to create wizard-style screens, and then we will wrap up this
week by sharing tips
00:01:05 on how to optimize performance for mobile flavors. Today, we will be focusing on building
flavors
00:01:11 for different device sizes. In the last unit we created a simplified flavor
00:01:16 for transaction IW21, which allows employees to create a ticket for malfunctioning
equipment.
00:01:22 This flavor can be used by anyone walking around with an iPad or another type of tablet to
report
00:01:29 the broken equipment. Of course, not everybody walks around with a tablet
00:01:33 in the office, but many people have a smartphone. Let's show you how you can transform
this flavor
00:01:39 to create something more suitable for a smaller form factor. So, we're going to start by
bringing the flavor in the edit mode.
00:01:46 So, if you recall from the last unit, we had created a flavor for the tablet device
00:01:51 which looked like this. The first thing you will notice
00:01:57 when the flavor is in the edit mode is this gray area on the screen,
00:02:01 giving an indication of the device width for which the flavor is created.
00:02:06 So, in the last unit I showed you that the width can be specified
00:02:09 from the Release tab, specified here as 1,000.
00:02:13 So, while the flavor renders very well on an iPad, this will not work for an iPhone.
00:02:18 We can test this by rendering the flavor in the Device Preview mode.
00:02:23 In the Device Preview, we will select tablets and we'll take a look at Apple iPad.
00:02:32 You'll notice the flavor looks very good on an Apple iPad, but if I switch to iPhone,
00:02:39 most of the screen gets cut off, so we will need to tailor this flavor
00:02:43 for an iPhone device. From the Device Preview window,
00:02:47 because you can see a large number of devices here, we can select the Show All Devices
00:02:53 and filter this list to only the devices we want to see. From this screen, we can also add any
custom device
00:03:01 if the listed devices don't match one of our criteria.
00:03:05 So, you can specify the device name, the viewport size, the preview size, and once created,

00:03:10 it will show up under Desktop/Laptop. In order to create multiple variations

00:03:22 of the flavor for different device sizes, we have introduced adaptive flavors.
00:03:26 To start, we create an adaptive flavor based on an existing flavor.
00:03:32 In our case, we'll click on this, select Add Adaptive Flavor
00:03:37 and we're going to call it "SPS4 Notification (iPhone)". We're going to specify a flavor width
of 300,
00:03:54 which is the device size for an iPhone. Notice that a parent flavor specified here
00:03:59 is "SPS4 Notification W2U1". An adaptive flavor always inherits the functionality
00:04:06 of the parent flavor but allows the users to rearrange,
00:04:10 organize, or hide controls from the screens to make them appropriate for rendering
00:04:14 for different device sizes. So, let's click on Create over here.
00:04:19 Now the gray area has adjusted to the screen to give you an indication of what the iPhone
screen will look like.
00:04:26 Let's start making adjustments to the flavor so that it fits within the screen width.
00:04:31 For an iPhone, we are going to hide the long text for the description. We want the user to be
able to quickly specify
00:04:38 the equipment and specify the description and click on Save.
00:04:43 We will also rearrange the fields at the bottom. We just need the Malfunction Start date and
time
00:04:49 and a flag for Breakdown. All the other fields can be hidden.
00:05:02 You notice that we are using the snap to grid and also the helper lines
00:05:06 to help us adjust the screen as we find it appropriate.
00:05:19 So, once we've made all the changes to the flavor, we are going to save it.
00:05:24 We can quickly check from the Release tab in the Device Preview to see if the flavor
00:05:28 will look good on an iPhone. Now let's come back to the runtime mode
00:05:35 for the flavor. As you can see, if an adaptive flavor
00:05:40 gets created for a specified transaction and a flavor, you will see an icon at the top
00:05:46 which indicates that there are adaptive flavors for this particular flavor.
00:05:50 Also, you will be able to manage all the flavors in the adaptive stack
00:05:54 as one unit, so you should be able to share or copy flavors or even delete the entire stack
together.
00:06:02 Let's talk about the behavior of adaptive flavors. The idea here is that Slipstream Engine
runtime selects
00:06:08 the right flavor from the adaptive stack based on the width of the client device
00:06:13 on which the flavor is being rendered. So, in our case, if this flavor was being rendered
00:06:18 on an iPhone, the iPhone flavor from the stack will be picked up.
00:06:22 If, however, the flavor is being rendered on a tablet, then Slipstream Engine will choose the
base flavor
00:06:28 in the stack to render the transaction screen. It's important to note that the base functionality

2
00:06:34 of the flavor, including the scripting, remains the same and is inherited by all child flavors
00:06:39 in the adaptive stack. Notice that we had the base flavor created
00:06:44 for a tablet, but because we are rendering it on an iPhone in portrait mode,
00:06:49 it picked up the flavor we just created in the adaptive stack.
00:06:54 Now, let's select a piece of equipment. I'm ready to provide a description
00:07:00 for the malfunctioning equipment, in this case, the cooling tower fan.
00:07:08 Once I'm done with the description, I'm ready to submit this report.
00:07:12 That brings us to the end of our unit today. Today we showed you how to create multiple
flavors
00:07:18 that inherit the same functionality as a parent flavor but are better suited for differently sized
devices
00:07:25 using adaptive flavors. We also discussed how you can modify these child flavors
00:07:30 to further suit your users' needs. Next time we will extend the flavor,
00:07:35 using the mobile device's built-in camera to capture an item number from a barcode
00:07:41 instead of typing it in. Thank you.

3
Week 2 Unit 2

00:00:06 Hello and welcome to week two, unit two of our openSAP course Building Mobile
Applications
00:00:11 with SAP Screen Personas. My name is Vandana Deep.
00:00:14 Last time, we talked about designing for different device sizes using adaptive flavors.
00:00:20 Today we will show you how you can access the native device capabilities from within your
flavor.
00:00:26 Before we do that, let's take a quick look at the flavor we built for creating notifications
00:00:30 for malfunctioning equipment. We have here the flavor that we created.
00:00:36 As you can see, we have in the Adaptive Stack a flavor that's created for a tablet device
00:00:43 and for the iPhone. The way the user typically uses this flavor
00:00:48 is by selecting the equipment here by choosing F4 help. Let's say we select the cooling
tower fan,
00:00:59 and now he will provide a quick description of the issue, and hit on Save.
00:01:10 This saves the notification. As you can see in the current scenario,
00:01:15 the office worker would either need to type in the equipment number
00:01:19 or select from a list before creating a notification. Now, since the flavor is being used with a
mobile device,
00:01:25 we can consider leveraging the native device functionality to provide an alternative
mechanism
00:01:30 for entering the equipment number. Now in today's unit, we will modify this flavor
00:01:36 to allow the user to use a camera to capture the barcode printed on the broken equipment.
00:01:41 This would improve the usability, and also reduce the time taken to create tickets.
00:01:47 To get started, we need to install the SAP Fiori Client application on our device.
00:01:51 SAP Fiori Client application is required to provide access to JavaScript interfaces
00:01:57 that allow SAP Screen Personas to use the device's native functions,
00:02:01 such as a camera or a GPS. Now let's modify the flavor
00:02:06 to add the scanning functionality. Let's launch the Script Editor for the flavor.
00:02:17 I'm going to make this a little bit bigger so you can see more on the screen.
00:02:21 So I will create a script called openScanner, which basically enables the scanning
functionality.
00:02:28 Now the JavaScript library that is available within Personas Scripting Engine
00:02:33 is the Apache Cordova library. So, the first thing that the script would need to
00:02:38 is to ensure the flavor is being rendered within the Fiori Client application
00:02:42 by checking for the Cordova variable that's defined here. If the flavor is being rendered on a
desktop,
00:02:49 we want to display a message to the user that the native device capabilities are not
accessible.
00:02:56 If, however, the variable is defined, then we need to use the Cordova barcode scanner
method,
00:03:03 as shown here. Now let's talk about the Cordova barcode scanner method.
00:03:10 The barcode scanner method requires you to specify two callback functions.
00:03:15 The first one is the case where the scanning is successful and a barcode value is
successfully read.
00:03:22 And the second one, where the scanning fails. Now let's take a look at the Success callback
function.

4
00:03:31 As you can see here, we are doing multiple things here. The first thing if the scanning is
successful
00:03:37 is that we take the barcode value and put it in a session variable called "scanvalue".
00:03:42 Next, we execute another script. Right now, in this case, the script is not defined,
00:03:48 but I will come back to it. Now in case the barcode scanning is unsuccessful,
00:03:54 we just alert the user with a message that the last scan canceled.
00:03:58 Now it's important to mention that the executeScriptAsync is required
00:04:04 because the Cordova API is using a callback function to notify the Slipstream Engine
00:04:09 when a scan result is available. Since this happens asynchronously,
00:04:14 in order to ensure that the screen gets refreshed after the scanned value is available,
00:04:19 we store the value in a session variable and then fetch it back in the script which is called
00:04:25 within the executeScriptAsync method. This synchronizes the screen update
00:04:30 after the scan result is available. Now, let me first create a script
00:04:35 which will be called when the scanning is successful. I'm going to call this script
writeBarcode.
00:04:49 Now, within this script, what we need to do is to take the value of the scanned value
00:04:54 from the camera, from the device camera, and update it in the text wheel for the equipment.

00:05:01 I have already created a script and I'm going to copy and paste it over here.
00:05:07 The first thing that the script does is copy the session value for a scanned value,
00:05:12 into a text variable. Next we're going to find the control ID of the equipment control,
00:05:18 and we're going to set the text value to the scanned value, which is sText over here.
00:05:24 And that's all there is to this script. Now let's take the script ID
00:05:31 and copy it, and we can now paste it in the openScanner method
00:05:36 where we are calling the executeScriptAsync. Now our scanning script is complete.
00:05:49 The next step that we need to do is to create a script button
00:05:52 which will invoke the device camera. So let's bring this flavor into edit mode.
00:06:00 We are going to create a Script Button. With the Scan button created,
00:06:27 we are now ready to test this functionality on the tablet. Before we do that, I would like to
point out
00:06:32 that there is an easier way to incorporate this functionality in your flavor.
00:06:37 We now have a barcode template available in SAP Screen Personas' flavor gallery,
00:06:42 that can be imported in your system and used within the flavor.
00:06:46 This functionality includes all the scripts that you wrote to incorporate
00:06:51 the scanning functionality, and also update the text feed. So now let's take a look at how
this works on a device.
00:06:58 The first thing that we do on the device is to have SAP Fiori Client application installed.
00:07:05 Now the first step is to configure the Fiori Client application
00:07:08 to point to the flavor we just created. So the way we do that is by clicking on Log In.
00:07:15 And in the first field over here, enter SAP Fiori URL or a work e-mail.
00:07:21 We will provide the URL for the flavor that we created. Now instead of providing, we can
also create
00:07:28 a QR code for the URL. In my case I've created a QR code for this particular flavor.
00:07:34 Let me scan the QR code. Now that I have the flavor set up
00:07:38 in the Fiori Client application, I'm going to click on OK.
00:07:43 I want to Disable Passcode. And now the system is going to try to access

5
00:07:50 this particular flavor on the device. As you can see, the flavor renders
00:08:00 within the Fiori Client application. Now let's try to scan a broken piece of equipment.
00:08:08 I have here a QR code for one of the broken pieces of equipment. Let me try to scan it.
00:08:16 Now you can see that when the cooling tower fan equipment ID
00:08:20 was picked up using the QR code, its functional location was also updated,
00:08:26 and the description was updated. Now I can provide a quick description here for what's
broken:
00:08:34 "Broken fan - needs attention". Now I have the notification created using the device.
00:08:48 As you can see with the small script that we created in the flavor,
00:08:51 I was able to use the device's camera, scan the broken equipment QR code
00:08:56 which was available to me, and use the flavor to actually generate
00:09:01 the notification request right there from my device. That brings us to the end of the demo.
00:09:07 Today we showed you how to access the native device capabilities
00:09:11 from within a flavor on a mobile device. Using the Cordova JavaScript library,
00:09:16 you can now implement scenarios which use the native device features,
00:09:20 such as the use of a camera or GPS. Next time, we will talk about
00:09:24 creating a consistent look and feel across all the flavors created
00:09:28 for your mobile device using templates. Thank you.

6
Week 2 Unit 3

00:00:07 Hello and welcome to week two, unit three, of our openSAP course,
00:00:11 Building Mobile Applications with SAP Screen Personas. My name is Conrad Bernal.
00:00:16 Last time, we showed you how to access the native capabilities of your mobile device,
00:00:20 turning your camera into a barcode scanner. Today we'll discuss how to create templates
00:00:25 for mobile flavors. If your SAP Screen Personas project
00:00:29 involves creating multiple flavors for use across several different screens,
00:00:33 it's pretty likely that you'll want all of those screens to have the same look and feel.
00:00:37 Templates allow you to quickly add a pre-configured set of objects,
00:00:40 such as labels, buttons, fields, or scripts to your flavors. This helps to expedite the flavor
creation process,
00:00:47 since using templates means you don't have to make the same set of changes
00:00:50 across a group of similar looking screens. You can build a template for your flavors
00:00:54 in the SAP Screen Personas Flavor Editor or download one from the SAP Screen Personas
Flavor Gallery.
00:01:00 You can also modify the templates you download from the Flavor Gallery to meet your
specific needs.
00:01:05 So now, let's look at how templates play into the scenario for this course.
00:01:08 In our first unit this week, we showed you how to create an adaptive flavor for a mobile
phone.
00:01:13 With it, our users can list a piece of broken equipment, where it's located, and write a short
description.
00:01:19 You may have noticed that we designed the flavor for the mobile phone with fewer fields,
00:01:23 hiding the long text box that allowed for more in-depth description of the issue.
00:01:27 We also hid the fields for additional location data. Basically, we gave users only the bare
essentials
00:01:33 due to their limited screen real estate, but what if they actually need to provide that
information?
00:01:38 In that case, we'll use an SAP Screen Personas feature called Viewports to create virtual
screens
00:01:43 with those fields. A virtual screen does not exist in the original transaction.
00:01:47 Instead, SAP Screen Personas creates it on- the-fly to render a subset of the transaction
screen
00:01:52 that you define in the editor. In earlier versions of SAP Screen Personas,
00:01:56 this was possible using scripts to show and hide different screen areas,
00:02:00 but now Viewports greatly simplify this process. We'll talk more in depth about Viewports in
our next unit.
00:02:06 For now, what you need to know is that our users will be able to click on different buttons
00:02:10 to navigate to these other screens and then back to our main screen
00:02:13 with the essential information. Of course, we want the appearance
00:02:16 of these screens to be consistent and that's where templates come in.
00:02:20 Today we're going to build a template for use on those virtual screens.
00:02:23 So let's get started. One important thing to mention
00:02:25 before we get started is that all child flavors, such as our adaptive flavor for the mobile
phone,
00:02:30 inherit the properties of the parent flavor. So, if you'd like your template to be both a part
00:02:34 of your parent and child flavors, just create it in the parent.

7
00:02:37 In our scenario, however, we only need navigation buttons in the flavor for our mobile
phone,
00:02:42 so we'll create the template in our child flavor. So, let's go to our child flavor here.
00:02:50 Okay, open the editor. Click on the Templates tab and hit Create Template.
00:02:59 Okay, let's call it "SPS4 Viewport Navigation", we're going to add it to the openSAP group,
00:03:09 and give it a short description. Okay, so here's our template.
00:03:22 So now let's insert the script buttons we need to navigate to the other screens.
00:03:34 Okay, this is our Issue button. And it's going to allow our users to navigate
00:03:45 to the basic overview of their notification. Here's our details button.
00:04:05 And this is going to take our users to a screen where they can enter long text description
00:04:09 if they need more than one line to describe the problem. And here's our Location Data
button,
00:04:28 Now we have all the buttons we need for our users to navigate between the screens.
00:04:33 As I mentioned before, this navigation is made possible through scripting.
00:04:36 But before I show you how to include a script in your template,
00:04:39 let me mention one important thing about using scripts in templates versus using scripts in a
flavor.
00:04:45 Your template scripts should only refer to controls or objects that are guaranteed to be
present
00:04:49 and have the same unique identifier in every flavor using that template.
00:04:53 You cannot use a template script that references a custom control
00:04:56 that's present in one flavor, but not another. The script will simply fail
00:05:00 because the control isn't present. In our case, the scripts we need
00:05:04 perform the same navigational steps on each screen, so we can safely include them in our
template.
00:05:09 Now, let me show you how to add a script to your template. We're going to click on the
Release tab
00:05:14 and then go to Template Scripts. So from here, let's just add placeholders
00:05:21 for the three scripts we need. We will actually add these when we get around
00:05:24 to building our Viewports next unit. There's the script for our future Location screen.
00:05:37 The script for our future Details screen. And the script to navigate back to our Issues
screen.
00:05:46 Okay, now let's hit Done to exit. And then before we wrap up here in the template editor,
00:05:52 let's make this a little more mobile-friendly. So let's make the template a little smaller.
00:06:02 And then we'll save and exit, and insert this in to our flavor.
00:06:12 Insert Template. So there you have it, we now have a template
00:06:36 for navigation buttons that we can use on any screen. Once we add our Viewports, our
mobile phone users
00:06:41 will have access to all of the same fields that our tablet users have.
00:06:45 Today, we talked about how to create templates for mobile devices.
00:06:49 You also learned how child flavors inherit the properties of their parent flavors
00:06:52 and how to insert scripts into your templates. Next time, we'll talk about how to use
Viewports
00:06:57 to create a wizard-like functionality for your users, using the virtual screens I mentioned
earlier.
00:07:02 Thanks for watching.

8
Week 2 Unit 4

00:00:09 Hello and welcome to week two, unit four, of our openSAP course, Building Mobile
Applications with SAP Screen Personas.
00:00:16 My name is Conrad Bernal. Last time, we talked about building templates
00:00:20 for mobile devices. Today, we'll focus on creating Viewports,
00:00:24 using the templates we created in the last unit. But before we build one, let's talk a little bit
about
00:00:30 what the Viewport feature does. Viewports let you have different layouts
00:00:34 for the same screen within the same flavor. This can have a variety of different uses.
00:00:39 For example, it allows you to take a complex transaction and break it up into smaller chunks
using scripting.
00:00:44 This can greatly simplify how people navigate through complex screens, which, as you
might know,
00:00:49 can be quite common in SAP ERP systems. These new chunks of a transaction
00:00:53 occupy what we call virtual screens or Viewports. Users can then step through these
screens
00:00:59 to provide the required information, rather than hunting for the relevant fields
00:01:02 on the original SAP GUI transaction. You could also use Viewports
00:01:06 to create a guided procedure for your users, walking them through a business process
00:01:09 in a wizard-like fashion. This could apply to both desktop and mobile scenarios
00:01:13 that run in both SAP GUI for HTML or the Slipstream Engine. For our course scenario, we
will use Viewports
00:01:19 to make the transaction mobile-friendly and run it in the Slipstream Engine.
00:01:23 As an alternative to Viewports, you can also write scripts to navigate between tabs of the
same screen,
00:01:28 or dynamically change a screen layout by hiding and showing fields,
00:01:31 but that's outside of the scope of this unit. It can also potentially result in performance
issues,
00:01:36 since dynamic screen changes would need to be applied each time the same screen is
redrawn.
00:01:40 To decide whether or not using a Viewport would be the best option for you,
00:01:44 you should consider the following questions. Does navigation require complex scripting?
00:01:48 Because this may negatively affect performance and create other maintenance
considerations.
00:01:53 Can the transaction be broken down into smaller tasks? You can create virtual screens to
help users
00:01:57 focus on those smaller tasks. And lastly, will this flavor be used on a mobile device?
00:02:03 Creating simpler virtual screens and having users navigate through them in a step-by-step
manner
00:02:07 reduces the amount of screen real estate needed at any one time.
00:02:11 Since our use case involves breaking a task into different chunks on a mobile device,
00:02:15 we're going to use the Viewport approach. With that as an introduction,
00:02:19 let's give our users on mobile phones all the functionality of our tablet users,
00:02:23 just in a way that makes better use of their smaller screen real estate.
00:02:27 Okay, so if you remember from our last unit, we want to create three different screens
00:02:31 for our mobile users to give them the functionality of the tablet flavor, but in a way that
makes more sense
00:02:35 for the mobile phone format. Since only a small group of users

9
00:02:39 need to provide the additional information, we don't want to clutter other users' small
screens
00:02:43 with a long text box and additional fields for location data.
00:02:46 Instead, we'll allow users who need to provide that data to navigate to two additional virtual
screens,
00:02:52 one with the long text field that allows them to provide a more detailed description of their
issue,
00:02:57 and another with the detailed location data. We are going to provide this navigation
00:03:01 by way of the script buttons we inserted in our template in the last unit.
00:03:05 Since our child flavor for the mobile device acts as our overview screen for the issue,
00:03:09 let's get started by making sure that our users can always get back to it.
00:03:13 Therefore, our first script will be for the Issue button so that it can act as a sort of Home
button.
00:03:18 When it comes to writing a script that will allow to return Home, you can do this in one of two
ways.
00:03:23 You can use the .show action, which will take you to a specified screen number,
00:03:27 or you can use the .reset action. To give you a better sense of what's going on,
00:03:31 we're going to use the .show method, so let's take a look at how you can find
00:03:34 the screen number for the Issue screen, this also works for any other screen.
00:03:38 To get started, we need to open the Script Editor in the Flavor Editor.
00:03:42 We also need to return to the parent flavor, as scripting is not currently supported in child
flavors.
00:03:46 Okay, now that we have the Script Editor open, we can find our screen number right here
00:03:50 at the top of the scripting window, 7255. Now that we have this, we can begin writing our
scripts.
00:03:57 So, let's go back to our child flavor, open the Flavor Editor,
00:04:05 and then the Template Editor. Okay, now that we're in the Template Editor,
00:04:14 let's go to the Release tab, and then click on Template Scripts
00:04:17 so that we can edit our placeholders from the last unit. Since we want to write our script for
the Issue button,
00:04:23 let's select the Issue script and press Edit Script. Then we're going to use the .show action,

00:04:28 so let's enter "session.viewport.show(7255)". If you remember, 7255 is the screen number
00:04:40 for our overview screen. So once we save this line of code,
00:04:44 we're done with that script, so now let's attach it to our Issue button.
00:04:47 First we're going to click Save Script and then Done. Then we're going to select our Issue
button
00:04:54 and make our way over to the Insert tab. Let's click on Script Events,
00:04:59 mouse over onClick, and then select our Issue script. Pressing the Issue button will now
take users
00:05:06 to the Issue screen. So now that our users have a way
00:05:08 to return to the Issue screen, we can begin creating our virtual screens.
00:05:12 Our first Viewport or virtual screen is going to take our users to a screen with a long text
box,
00:05:17 so that they can enter a more detailed description of their issue if needed.
00:05:21 To create this functionality, let's make our way back to the Release tab,
00:05:27 and select Template Scripts again. Let's select the Details script
00:05:31 and just like before, press Edit Script. Now, there are two ways to define a virtual screen.

10
00:05:37 You can use the .next action to create a screen with the screen number one higher than
your current screen,
00:05:42 or you can define your own screen number. In this case, we're going to define our own
screen numbers.
00:05:47 Creating a virtual screen only requires one line of and it's just like this,
session.viewport.show,
00:05:56 followed by your desired screen number. Just like our Issue script,
00:06:00 except now we're coming up with our own screen number. Here, I'm going to use 9050.
00:06:07 When you create your own screen numbers, make sure they're not similar
00:06:09 to numbers from other non-virtual screens as that can create some issues.
00:06:13 So now let's save and exit again. Now we want to attach that script to our Details button,
00:06:19 so let's click on our Details button and then open the Insert tab again.
00:06:23 From there, just like last time, we're going to click on Script Events, mouse over onClick
00:06:28 and then select our Details script. Now that the script is attached,
00:06:32 let's go to our new virtual screen. So let's save and exit both the Template and Flavor
Editors,
00:06:43 and click on our Details button. Okay, so now that we've entered our virtual screen,
00:06:50 you might notice that we're face to face with the original screen without any flavor
modifications.
00:06:55 This is because virtual screens do not carry over flavor changes.
00:06:59 This is where things like templates and themes come in handy, as they can help you quickly

00:07:03 your virtual screens look like your other flavors, but let's get back to the task at hand.
00:07:07 We want our users to come to this screen and enter a long text description of their issue,
00:07:11 so let's use the editor to hide everything else. To do this quickly, I'm going to make a little
space here at the top,
00:07:27 I'm going to find our long text box, and we're going to pull it out.
00:07:35 Then we're going to hide everything else, and put the long text box back into its proper
position.
00:07:47 Great, now we want our users to be able to either navigate back to the Issue screen
00:07:51 or to the Location Data screen, should they need to provide more specific location data,
00:07:55 so let's insert our navigation template here as well. Now, the good news about putting your
scripts
00:08:02 into a template is that they can be used in any transaction and on any screen,
00:08:06 so we won't have to rewrite our script to go back to the Issue screen.
00:08:09 As I mentioned in the previous unit, however, your template scripts cannot refer to objects,
00:08:13 custom or otherwise, that don't exist on other screens. Your scripts simply won't execute,
00:08:18 as those objects won't be present, just something to keep in mind.
00:08:22 So now, let's create our second and final Viewport. Just like last time, let's select our
navigation template
00:08:30 and enter the Template Editor. Again, we'll head over to the Release tab
00:08:36 and click on Template Scripts, then select our Location script and then Edit.
00:08:42 Just like last time, we're going to enter session.viewport.show,
00:08:50 this time entering 9051 as our screen number. So let's save our script and exit.
00:08:59 Again, just like last time, we're going to select our Location Data button
00:09:03 and insert our script. So let's go to the Insert tab, Script Events,
00:09:08 onClick, Location Data. Then we'll save and exit both editors.

11
00:09:24 Okay, now we'll click on our Location Data button and it's going to take us to our new
Viewport,
00:09:29 and again, we're confronted with the original screen. The information we want is on the
Location Data tab,
00:09:35 so let's navigate there, let's open the editor, and again
00:09:39 hide all the stuff we don't need. Just like last time, I'm going to make this a little faster,
00:09:48 let's clear some space at the top. Okay, now let's make a few more edits
00:10:08 to make this screen a little more mobile-friendly. So it's the same story with this screen,
00:11:13 we want our users to be able to navigate to the Issue or Details screen if required,
00:11:17 so let's insert our navigation template again. Okay, from here, let's save and exit
00:11:33 and test all of our navigation buttons. First, let's return to the overview screen
00:11:37 by pressing the Issue button, then let's go to the Details screen
00:11:42 by pressing the Details button, and then let's go back to the Location Data screen again
00:11:48 by pressing the Location button. Great, so there you have it.
00:11:53 Now our mobile phone users are able to create all of the same data as our tablet users,
00:11:57 but in a format that's easier to consume for them. Today we talked about how you can
create Viewports
00:12:02 to improve the navigation of your mobile app. You learned how to create virtual screens,
00:12:06 as well as some things to keep in mind while working with them.
00:12:09 Next time, we'll talk about how you can optimize the performance of your mobile flavors
00:12:13 to create a streamlined user experience for people using your app.
00:12:16 Thanks for watching!

12
Week 2 Unit 5

00:00:06 Hello and welcome to week two, unit five, of our openSAP course,
00:00:11 Building Mobile Applications with SAP Screen Personas. My name is Ashley Tung.
00:00:16 Last time, we talked about how to create wizards using Viewports.
00:00:20 Today we will focus on optimizing performance for mobile flavors.
00:00:25 An application's performance is becoming ever more important to its success. Quick loading
times are considered to be
00:00:32 part of a good user experience. When it comes to mobile applications,
00:00:37 performance optimization is even more critical. For desktop applications, typical measures
of performance
00:00:44 are the number of clicks required to perform a and the amount of time, in milliseconds or
seconds,
00:00:50 that each click takes. These are still important in a mobile application,
00:00:56 but mobile use cases also have another important component as well.
00:01:01 That's the effective use of screen real estate. Therefore, application design and complexity
00:01:07 are also major factors that must be considered when designing a mobile app.
00:01:13 In this unit, I am going to give you some tips to help you with the performance of mobile
apps.
00:01:20 As we discussed in previous units, when designing a flavor for a mobile app,
00:01:25 you must take into consideration the size of the mobile device you are designing for.
00:01:31 You can take advantage of features such as adaptive flavors, Viewports, and Mobile
Preview
00:01:37 to help you visualize the screens that will be presented to the end user.
00:01:42 Viewports allow you to convert a complex screen into multiple smaller virtual screens
00:01:47 that are suitable for mobile devices. When using Viewports in a mobile application,
00:01:53 you can create guided processes. If you have used tab merging in your flavor,
00:01:59 you may be able to reduce or eliminate it by using Viewports.
00:02:04 Given the limited space on a mobile device, a mobile application with proper design
00:02:10 must have much less data than the screen designed for desktop. This is critical for high-
performing applications,
00:02:17 as it reduces the amount of data that needs to be exchanged between client and server.
00:02:23 Less data and processing means faster performance. Table controls tend to have many
columns
00:02:31 in an SAP GUI transaction. The number of columns being rendered in a table can impact
00:02:37 the performance of the application. When designing the flavor,
00:02:41 you must only show the columns that are absolutely relevant for that current screen.
00:02:47 You can use a table variant to hide the rest of the columns. When using images to improve

00:02:55 the visual appearance of your flavor, do not simply reuse the image
00:02:59 that was used in the desktop flavor. Instead, design an image specific to your mobile device

00:03:06 to keep the size of the image as small as possible. Also, when designing the mobile app,
00:03:14 the need for scripting may intensify in order to automate and reduce the number of steps.
00:03:21 Do consider the nature of the script and try to combine the steps into batch actions
00:03:26 to reduce the number of roundtrips to the back end. Let me show you a simple example of
this.
00:03:33 Let's use the create notification transaction as an example.

13
00:03:38 When creating a notification, you may need to enter the location data.
00:03:43 I created a script to populate the plant section, work center, and sort field,
00:03:48 depending on the values I set for plant, location, and room.
00:03:53 This is my first script. My script first reads the value of the plant and location
00:04:00 and then it updates the value of the plant section. Then it reads the value of the location
00:04:06 and sets the value of the work center. Finally, I read the value of the room field
00:04:12 and I update the sort field accordingly. Let's try to execute the script.
00:04:21 As you can see, with the execution of this script, I generated five round trips to the back
end.
00:04:29 Now, let's take a look at my optimized script. In this optimized script, I group my
restatements
00:04:38 in the first section of the script. And I sign each of these to a variable.
00:04:44 Then I use the variable as a condition to proceed to do the update.
00:04:50 Now let's try to execute this same script. With this optimized script I only generated
00:05:05 three roundtrips to the back end. As you can see, by making a small change
00:05:11 in the ordering of the script, I was able to reduce the number of the trips made to the back
end.
00:05:17 Today we talked about some of the factors that affect application performance, and I gave
you
00:05:23 a few tips to improve the performance and user experience of your application for your
users.
00:05:30 Since this is the end of week two, let's sum up what you've learned this week.
00:05:36 We covered how to create adaptive flavors so that you can design your screens for different
devices.
00:05:43 And we showed you how to access the native capabilities of your device, turning a mobile
phone's camera
00:05:49 into a barcode scanner. We also showed you how to create and use templates to have
00:05:55 a consistent look and feel across your flavors. We then took the template we built and used
it to help us
00:06:03 create Viewports for our scenario. Finally, we capped off the week by showing you how to
get
00:06:10 the best performance out of your flavors. Next week, we're going to talk about deploying our
flavors,
00:06:17 integrating flavors with SAP Fiori launchpad, configuring front-end server for Slipstream
Engine,
00:06:24 and using Slipstream Engine with SAP Cloud Platform. Then, we'll wrap up the course
00:06:30 and tie it up some miscellaneous topics. Thank you.

14
www.sap.com/contactsap

© 2018 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from e xpectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See http://www.sap.com/corporate-en/legal/copyright/index.epx for additional trademark
information and notices.