Web, Hybrid, Native Part III—Hybrid

In our first two posts we learned about a web application and a native application.  This is the last blog in our series and we are going to learn all about hybrid applications.

Hybrid Application:

By definition, a hybrid application is simply an application that can be installed on a device the same way as a native application but contains what is called a webview that renders HTML code either via a web request or via static HTML that is loaded as a resource in the application.  This definition covers a variety of different types of applications that could be hybrid apps.  Because of this, it makes more sense to breakout hybrid apps into three different categories; Thin Hybrid, Full Web Hybrid, and Full Device Hybrid.

Thin Hybrid:
By the definition laid out previous, any native application that incorporates a webview could be considered a hybrid application.  A thin hybrid is an application that contains mostly native code but certain aspects of the application are contained within a webview.  There are a number of reasons to build an application in this manner.  One example would be a shared login screen across platforms that simply points to a website which takes care of passing the authentication information between the login server and your application.  Another example would be to incorporate logic or layouts from an existing website into an application.  This can save time from having to re-write complex JavaScript or CSS across platforms.  It is possible to just contain it within a small portion of the application giving the users the illusion of a consistent native experience.

Full Web Hybrid:
A full web hybrid application is an application that can be installed as a native application.  The entire native application is a webview.  The webview is a view that can render HTML code the same way the device’s browser can.  The webview will then point to an HTML5 web application that resides on a web server.  The benefits of a full web hybrid application is that once installed, it is possible to update the code base in one place, the web server where the application resides, and instantly, all of the users will have the updated software.  The downside to this type of application is much the same as a web application in that speed is a big issue.  The users device has to download the entire interface and data each time it needs to render anything.

Full Device Hybrid:
Much like the full web hybrid application, the full device hybrid is a native application that contains only a webview for displaying it’s data.  The difference with the full device hybrid is that it’s entire UI (view) and controller logic is contained within the binaries of the installed native application.  Essentially, the HTML, JavaScript, and CSS files for displaying and accessing the data are installed within the native application and reside and are rendered on the device.  This mirrors the a full native data driven application in that the application takes care of all of the layout and accessing the data via API’s.  The full device hybrid uses JavaScript remoting and AJAX to make callouts to API’s to receive the data needed to display within the layouts.  The benefit of this over the full web hybrid is that there is a lot less data being passed between the device and the web server.  While not as fast or responsive as a native application, this method will provide the best results from HTML5.

As you can imagine, there is a trade off for each type of application.  These trade offs have been listed in these three blog posts.  I hope this clears up any speculation you may have had on the subject.  If you would like a more comprehensive look at these different technologies including examples and how they affect the business check out a white paper I have on the subject.

I look forward to your comments and questions!

This entry was posted in Technology and tagged , , , , , . Bookmark the permalink.