Why are we so excited about SUP 2.0?

[former_member190800]

It's been just over a month since we announced the release of SUP 2.0 at Sapphire NOW, and the product has been available through the SAP Marketplace and Sybase Product Download Center.  2.0 includes the debut of the Hybrid Web Container , a native application for the iOS, BlackBerry, Windows Mobile, and (later in Q2) Android platforms which connects to SUP infrastructure, and runs web applications securely on an embedded browser.  It enables server-initiated push notifications and application scenarios, as well as end-user initiated applications.

It's been a busy month, so I've summarized some of the key questions I've answered in recent conversations to share some of the new functionality, and explain why we're so excited about SUP 2.0.

Why are we so excited about SUP 2.0?

2.0 is a big deal for us because it marks a big step forward for in delivering SUP application development on open web standards: with applications written in HTML5, JavaScript, and CSS. What this means is that in addition to providing SUP SDKs for the native OS languages, we are also providing as part of the platform a native application, called the Hybrid Web Container, (or 'Container'), which is installed on the device. That Container app includes some of the SUP messaging libraries and local data store, and embeds the WebKit runtime from the native operating system's SDK. So that is the basic structure of the Container. The 'apps' that are written to run in the container are Web Apps. They are constructed just like an app written for the browser: they have an HTML5 page, with a set of div's and form elements that make up the app screens. There are a set of JavaScript files, which include the methods for navigating from screen to screen, and the functions for accessing data for the screens. And there are a set of CSS files which provide the styling for the screen elements written on the HTML.

What CSS is used? Is there a standard look and feel across devices, or is each device specific?

We're shipping jQueryMobile out of the box. Both the .js and css files. This means that there is a single look-and-feel across devices, and that the navigation will be consistant as well. Within jQueryMobile, there are a number of 'Themes': a, b, c, d, etc., which are color schemes developers can choose, based on their preferences.

What if you want device-specific look and feel?

There are two parts to this (and both are: you can do that). The short answer is: we have JavaScript calls in the API for determining the OS, and developers have access to the DOM, so they can get window.screen.height()/width(), so you can identify the form factor. So, you can include some device-specific CSS files, or write modifications to the jQueryMobile for each device, and then write a check in the beforeWorkflowLoaded() function to choose which CSS file you want to use.

So the CSS files are packaged as part of the web app?

Yes. You can copy CSS and JavaScript files to the app directory, and when the Eclipse tooling packages the app, those files are copied to the manifest. JavaScript files are auto-added to the HTML headers, and CSS files can be appended.

You said that you can modify the JavaScript function, and modify the CSS. So you can customize the code. Where is that code coming from, and how can you customize it?

First let's explain where it's coming from. Here is the basic development process:

(1.) You open the Eclipse tooling, create a mobile project, and connect to a data source. This could be direct to a database, a set of BAPIs, web services, REST services.

(2.) Drag-and-drop tables or views from a data source to the model diagram. These are the Mobile Business Objects that everyone has heard about. This is where you define exactly what values and objects will be available on the SUP cache, and how that cache data is partitioned to improve performance. Up to this point is pretty much the same, whether you're writing a native app, or a Container app.

(3.) This part is new and improved, and this is where the HTML5, JS, and CSS code comes from. In the Eclipse tooling, you get a screen designer. In the screen designer, you can drag and drop MBOs into the screenflow and auto-generate list-->detail screens. You can add some Menu Items buttons and add Query or Operation actions.

(4.) The screen designer is also where you can manage some of the features that are distinctly 'SUP'. One of the key features is the ability to make a screenflow 'Server Initiated' and/or 'Client Initiated'. This means that you can have some screens defined, for example:  an Approval List screen, and Approval Detail screen. You can use the designer to set two entry points to the app. One could be 'Client Initiated', which means that the user opens the Container, selects the Container app, and goes to a 'Start Screen', from which you run a query, and point to the List screen. The other could be 'Server Initiated', which means that an engine on the server recognizes a business process event, executes a query and pulls a set of values, packages them as a message, and pushes the message to the Container on the device. That message on BlackBerry and Windows Mobile devices is opened from a plugin in the device Inbox. On iOS, because all the apps are sandboxed, it's in an inbox in the standalone Container app. Either way, the application can be defined as a single package of screen flows. This is one of the key defining features of the container, and for development, it's nice to know that the screens can be re-used for multiple flows and only a single package is needed.

(5.) Once you've used the designer in Eclipse to set your screen flows, there is a 'Generate' command that takes the screens you've defined, with the nested UI elements, and generates a HTML5 page. The screen elements are consistent with the jQueryMobile tags and classes. There are 5 or 6 JavaScript files that are created. They make up the JavaScript API, and include functions for making Online Requests, or submitting Operations, navigating from screen to screen, or accessing values from the encrypted cache. One of the major questions we get is: "how is this different or better than plain HTML5?" In addition to the server-initiated features, one of the key answers is that we've implemented an encrypted WebStorage cache that holds result sets, WebStorage being the spec for the offline data caching in HTML5. The fact of the matter is that our customers are really concerned about security, so this is an important feature that I'm sure will come up.

(6.)  Last, we include a set of CSS files that degrades properly across the earlier Blackberry OS and Windows Mobile devices. So that's the code: HTML5, JavaScript, and CSS. Straight out of the box, it will run with a standard look and feel across iOS, BlackBerry 6.x, and compatible 5.x, and Windows Mobile devices. The Android Container is coming as a patch later in Q2, so it will be available to SUP 2.0 customers.

What about Customization. Are these customizable? Can developers change the screens, or modify the JavaScript functions?

Yes. And we have made it simple, open, and straightforward, so that there is no problem with downstream modifications to the model, or to the screens in the Designer, or with the re-generation in Eclipse. What we've done first is to create a JavaScript file called Custom.js. This file contains a number of callbacks to the navigation functions in the API: beforeWorkflowLoaded(), beforeShowScreen(), afterShowScreen(), etc. The naming of the custom functions is very straightforward, for example, 'customBeforeWorkflowLoaded()'. You can make modifications in these custom functions, and return TRUE or FALSE, depending on whether you want the original behavior to be executed after your custom code. A very simple example of what you might do with customBeforeWorkflowLoad() is add a line of code to append a stylesheet to the HTML page header, based on device type. You can add an attribute to the menu buttons to give them icons, so you could use the Welter image set. If you have HTML links on the Start Screen styled as buttons, you could use customBeforeWorkflowLoad() to set the 'click' function, and call one of the native JavaScript API functions, or a custom function that you've created. So it's a generic place to handle some of the configuration you might do in your AppDelegate in an iOS app.

Can developers use the JavaScript API functions to access the MBOs and back end?

Yes. A good example is in an Inventory Lookup app that one of our partners, Liquid Analytics, built, and it's being included in the 2.0 release as sample code, so everyone will have access to it. Instead of using the MenuItems in the navigation bar, they wanted to have larger buttons in the center of the screen. So they added an HTML link, styled it, and pointed to the function call in the API for the Online Request for inventory data.

How do they access the data that comes from the back end?

We have a value called the 'MessageValueCollection'. The MessageValueCollection contains the latest values returned from an online request and cached. It can be traversed by key names or indexes. Keep in mind, if you generate an app and run it straight out of the box, all these values are already pre-bound to the screen elements, so you don't have to know anything about the MessageValueCollection in order to get data to the screen, or input back to the server. But the MessageValueCollection is how you get the data for sub-lists on a screen, or dynamically work with a result set on the device. It's really 'access to our WebStorage'. I like to think of it as similar to a FetchedResultController in Objective-C, if you're familiar with Core Data. It's not the same, but the results interface isn't too different.

Ok, so can you edit the HTML directly? Where are the boundaries of where you can customize?

Here is where the answer is 'yes and no'. The HTML5 page that we generate is fully functional HTML, and you can open in the web tool of your choice. I've written up a tutorial for using Adobe Dreamweaver to open our web apps for the container, directly from the root, and do customization there. But the thing to remember the main page of the app, the HTML file, will be re-generated when you go back to Eclipse to re-package.  Obviously you don't to want to overwrite any edits you would have made directly to the page. So there are two options that allow you to work with the HTML. The first one is to use JavaScript to build dynamic HTML, and use the tags of the screen to add it to the view. You have the freedom to add dynamic tables or elements, because you have access to the DOM, so this is regular web development. When the partner team built the Inventory Lookup app, they wanted to use the jQueryMobile list so they could demo the native jQueryMobile searchbar. They used the customBeforeNavigateForward() function in Custom.js to retrieve the values from the MessageValueCollection and then build the table view dynamically in HTML.

So the first option is use JavaScript to build HTML dynamically. The other option is using the HTMLView in the Designer. In the Screen Designer, you can drag-and-drop an HTMLview onto a scree, and then paste HTML code into the view. When Eclipse generates the HTML page, the code that you've pasted into the view will be published in-line, nested in the screen that the view is sitting on. So this is the way to statically customize the HTML page without worrying about being over-written. The code is a first-class member of the page, and can access all the JavaScript functions and CSS markups. So either way you prefer. I'm looking forward to getting input from the developers and users on this. I think there are improvements we can make to the HTMLView with respect to process, such as referencing files, as opposed to taking static values, say, but something we're very focused on as we continue to build on the platform.

Is there anything else we should be aware of?

Android support in the Container is coming later in Q2, as a patch to 2.0, so that functionality will be available to SUP 2.0 customers.

Where can I get a download?

A public developer edition is not yet available, but we are working to upgrade our processes to be more developer-friendly!  We will keep the community posted asap.  In the meantime, please go through the typical SAP and Sybase channels @ SAP Marketplace or SPDC.