Hybrid Web Container (HWC) is Not the Answer

[Former Member]

The Problem

I have a problem with the Sybase Unwired Platform (SUP) Hybrid Web Container (HWC). When I first saw the functionality, I couldn't quite get my head around why it felt like such a "cheap" solution for a clearly globally fundamental problem. Before I dig into my analysis, let's talk about the reason this functionality exists in SUP. SUP, as it's positioned, is supposed to alleviate a lot of the pain that mobile development groups go through when trying to deliver mobile applications to their clients (the business, normally). The major pain points:

1. Developing for multiple back-ends
2. Developing for multiple devices
3. Developing for multiple front-end/GUIs

These are all large problems to do with one thing; accessibility. As Steve Yegge has rightfully pointed out "...Accessibility, and it's the most important thing in the computing world." So how does the HWC solve these problems:

1. You create Mobile Business Objects (MBO) so that the 'model' part of the mobile design is only design once and can be reused. In the case of HWC, the only real advantage here is that you can easily maintain and connect to popular back-ends (such as SAP, REST, JSON, etc)
2. It utilizes jQuery Mobile which fully supports a plethora of devices and platforms.
3. By utilizing jQuery Mobile it means that you can highly customize the design and UI. Also the HWC functionality allows you to easily add your own custom HTML/JS.

The HWC Solution

What does this mean for the end-user? They get a native app (iOS, Android, Blackberry, Win, etc) called "Workflow" which then lists the set of HWC apps that have been deployed to them. The developer then has the ability through the SUP environment to deploy these HWC workflow apps to specific devices. Effectively all the native app is doing is acting as a holder for a webview class. For example, in iOS development there is a class called UIWebView that does this. Which means there is very little native code in the app, other than really just calling this webview class. So what does this mean?

• It relies heavily on HTML5/JS
• It relies heavily on being connected to the server. Meaning, pretty much any navigation on the app must make a call to the web server (SUP Runtime) and wait for a response. (note - in some cases asynchronous AJAX calls are possible)
• Offline storing is extremely limited.

The HWC Solution Problem

So this sounds great right? I have a couple of issues with this setup:

Accessibility

Accessibility is absent when the end user has no connection. No connection == no accessibility. So the accessibility argument effectively gets thrown out the window even before starting. There are some ways around this using the HTML5 spec localStorage, but I have yet to see this functionality work properly and in the way that a native app works. In other words, I have to see an offline HTML5 spec that can compete with the functionalities of something like Core Data.

User Experience

While jQuery (and other platforms such as Sencha, PhoneGap, etc) has solved many of the issues around the UI being presented, it still doesn't represent the native app experience. People do not adopt smartphones for the smartphone itself, but rather for the apps that exist on them. Mark Zuckerberg recently came out and explained "the biggest strategic mistake we've ever made" was using HTML5 for their app. Facebook's app was slow, chunky, and for the most downloaded app in the world, had a measly 2-3 star rating in the iTunes Store.

The Real Solution

So what's the solution? I believe in the 80/20 Native/Hybrid approach. It's what Facebook, LinkedIn, and a plethora of other leading mobile companies are using to create their apps. Unfortunately what this requires is a lot of up front work in understanding how the mobile app is used. To be very clear; this is how the mobile app is being used, which is slightly different than the back-end app that is used on a PC. This is extremely important and many companies choosing to develop mobile apps will often underestimate this. The reason this is so hard is because it requires many iterations of usability testing (something that pretty much never happens in EnSW), specifically around how the app is used in low latency and offline situations.

The focus of the SUP platform for developers should really be on creating MBOs that allow the developer to provide an infrastructure for managing all the changes to model objects. Which would give automatic support for undo and redo, and for maintaining reciprocal relationships between objects, across all platforms, while balancing the model layer between HTML5 and native interfaces. As I dive deeper into the platform, I'll be finding more and more if that support is true.