Skip to Content

The value of HTML5 in the SUP Hybrid Web Container

I spend a lot of my time talking with developers and architects about how HTML5 fits into their mobile application strategy.  SUP’s Hybrid Web Container enables them to get the cross-platform advantage of HTML and JavaScript, and provides the security mechanisms, provisioning, and hooks to native device features they can’t get through the browser.

In the Hybrid App Designer, we bundle jQueryMobile as the User Interface (UI) framework.  The UI framework in an app is how a developer builds the app.  It includes building blocks like a table-view, which can then have a number of configurations to meet the developer’s use case.  For instance, configuration ‘a’ sets each cell in the table to have a bold-face label, and a smaller detail text label.  Config ‘b’ adds an icon to the left of each cell. Config ‘c’ adds a disclosure button to the right of each cell.  And so on.

jQueryMobile is what you would call a ‘JavaScript UI framework’, because it is written in JavaScript, for use in HTML5 applications.  It is a replacement (/supplement) to a native SDK, such as Cocoa Touch on the iOS platform.  (Technically a supplement, since it leverages the WebKit runtime in the native SDK, but that’s details…).  There are a few other JavaScript UI frameworks that are increasingly relevant in the mobile application development space–especially in hybrid apps (web + native / container)–because they optimize the HTML development experience for mobile.  There is a huge advantage to an SUP developer of using these JavaScript UI frameworks, because they tend to be open-source, have plenty of community, and allow really rich customization of SUP Hybrid Apps that run in the Container.

I wanted to show a few screenshots of some jQueryMobile-based hybrid apps we’ve developed in the Hybrid Web Container.  These apps are connecting through SUP to enterprise data, can be managed and secured using the native functionality for SSO & authentication, and can be remotely provisioned on a role basis with the administrative tool.


Here, the jQueryMobile table view is combined with a button to launch an interactive webview to GoogleMaps that plots the current device location and the location of the customer.


Here, a stock check is displayed in a table view, with a numeric indicator of the quantity, and a bar chart indicating quantity vs. target.

All of this customization is basic web development in HTML5 and JavaScript, and requires no knowledge of xCode, Objective-C, Android development, etc.  The same app runs across all supported platforms, and can be re-skinned to match whichever OS it’s running on.

You must be Logged on to comment or reply to a post.
  • Hi Stan,

    Thanks for your blog. I have a question relating to the use of the JQuery Mobile HTML5 Framework.

    JQuery Mobile is built on top of JQuery core and also leverages JQuery UI.

    When talking to SAP representatives at SAP TechEd about project Phoenix – which is a HTML5 tag library for the ABAP platform – I asked them why SAP was building its own UI elements rather than contribute to the JQuery UI initiative. For example SAP is building its own datagrid element completely separate to the datagrid element that is being developed by the JQuery UI team. The answer I got was essentially that the licensing model for JQuery UI was incompatible with what SAP was looking for.

    How does the SUP team view the impact of the JQuery UI and Mobile license model on their products? Why do they not see the same issues that the project Phoenix team do?

    Graham Robbo

    • Hi Graham,
      I can’t comment on the licensing side of things.  But I did ask the same representatives at SAP TechEd on project Phoenix (UI5) about what mobile widgets and support they were providing (really a baited question on whether they were looking to reinvent something like jQuery Mobile, since they are already building on top of jQuery). I am starting to wonder whether I heard wrong, but they told me that they are not looking at the mobile side of things and they are concentrating their framework on the desktop.  They said the reason why was that mobile frontends would be ‘handled by Sybase’. And since from a web container perspective Sybase has adopted jQuery Mobile, I interpreted this to mean that team was deferring to jQuery Mobile for the mobile framework.  If mobile really is the ‘new desktop’, I started to wonder how important project phoenix really will be if it doesn’t have a strong mobile focus?  Ironically (and this makes me question whether I heard wrong) when I look at TechEd slides on Phoenix, I am seeing images of mobiles with the framework.  This leaves me somewhat confused about the positioning of that framework.
      • Hi John,

        there is a lack of clarity around a lot of this stuff. I don’t think people are asking hard questions but there are very few answers – in the case of my previous comment no answer at all.

        I see no reason why SAP can’t say they are leaving their options open so they can delay committing to a specific direction until they have had more time to see what emerges.

        Maybe they have polished up the messaging for TechEd Madrid? I will be following closely.

        Graham Robbo