A beautiful idea: WebViews

No comments
Given the new paradigm of building Web applications to run natively, problems of how to encapsulate these applications and make them available to users in the form of closed and executable packages comes to the spotlight.



For instance, we do not want our application depending directly from a browser to work or, at least, we want to hide it and show only the final application to the user as if it were just an executable. Still, we want to offer our application on Google Play, Apple Store, etc.

For this, we can use the WebView idea: all of the major SDKs can run web applications in a native view. This solution has as a positive point the fact of being general: we could create a WebView for Android, iOS, Windows Phone, etc. And has as a negative point the fact that an application running inside a WebView is usually slightly slower than an application running in a 100% native environment. The scope of this post will not discuss this later fact: please search for the term "webview performance" on Google in order to find many related discussions.

We can build applications with a WebView following two approaches:
  1. The first one is to build a WebView using a crossplatform technology, therefore, once you construct a WebView code in a certainly environment, you will have it working on all platforms.
  2. The other one is to build a WebView for each of the target platforms: Android, iOS, etc.
We will adopt the second strategy because it requires less code to create a WebView so it will not give us a lot of work. And besides that, we can control all of the customization power that each SDK offers us in order to direct access the functions of each device.


We will limit ourselves in this post to build a WebView only for Android. So... first, using the Android SDK, let's create a main Activity, which is responsible for invoking the WebView Activity:

public class MainActivity extends Activity 
{

 public void onCreate(Bundle savedInstanceState) 
 {
  final Context context = this;
  super.onCreate(savedInstanceState);
  setContentView(R.layout.main);
  Intent intent = new Intent(context, WebViewActivity.class);
  startActivity(intent);
 }

}

This code above creates and start an Activity named WebViewActivity using the Intent object. The WebViewActivity code goes on:

public class WebViewActivity extends Activity 
{
 private WebView webView;

 public void onCreate(Bundle savedInstanceState) 
 {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.webview);
  webView = (WebView) findViewById(R.id.webView1);
  webView.getSettings().setJavaScriptEnabled(true);
  webView.loadUrl("file:///android_asset/cruxsite/index.html");
 }

}

We have three important concerns about this code:

  • Note that the WebView object was instantiated through the file whose id is “webview1”. This file is omitted here, but is nothing more than the XML representation of the WebView created; it also has other minor settings such as the height and width of the page.
  • Another important point to be mentioned here is the use of "setJavaScriptEnabled " function, which is essential to ensure that the WebView to run JavaScript.
  • Finally, we store the static content of our pages in the "assets" folder. In this example we load the index.html home page (welcome page) available in "cruxsite" folder. Our web content is available entirely in the "assets" folder.

With this we can now compile this code and generate an APK application, which can be distributed in GooglePlay. The source code for this example is here.

Finally, here's a key point to decide. As we are building a native application using a WebView, we can think of hybrid applications, that is: we can merge the native code of Android with the JavaScript functions of the application located in "assets" folder. The philosophy we follow at this moment is to use the form of hybrid application only when you really do not have an HTML5 implementation for the native feature which we are trying to access, note that this gap tends to decrease with time, since the HTML5 is gaining more space on the Web. Thus, we can ensure a more simple, unique and therefore more robust code.

Don’t forget, using WebView is a great idea and tends to be the bridge for running Web applications in a native likely way.

No comments :

Post a Comment

Cross-Device: Native x Web

No comments
Crossdevice applications are those built to run similarly in many devices such as PCs, tablets, mobile phones, TVs, etc. On the other hand, crossplatform applications are built to run on various computing platforms such as Windows, Linux, Android, etc. When we say that an application is crossdevice and crossplatform, we know that once you develop your code, this will run on all predicted devices and platforms, usually producing the same functionality and achieving the same ultimate goal.


Hardly a company will have the luxury of producing specific applications for each of its features and target platforms. It is in this scenario that enters the frameworks and tools that help us building these applications. In the case of mobile applications, we can create a unique code application to be executed in iPhone, Android devices, WindowsPhone, etc. For this, we rely on various frameworks like, for instance, PhoneGap, Appcelerator, Adobe AIR, Sencha, Unity, Corona, Mono, etc.

Although these frameworks are relatively recent, if you look at the big picture, we already have these crossdevice and crossplatforms technologies being developed for over 20 years! A Web application running on a browser like Chrome, Firefox, Internet Explorer, Opera, etc, is by definition crossdevice and crossplatform. We know that these browsers work in various devices (including TVs!) and also in various platforms. So... why reinventing the wheel?


The point where we must focus and where the Web is converging is to allow access to a device functionality directly from the browser. And who is behind this venture is HTML5, which is gaining ground every day in our daily lives. Through the evolution of HTML5, Web applications can behave like native applications and work exactly as if you were accessing the functionality of your device. For example, we can build transparent Web applications that can access the camera and vibration on your device, and even persist data without connecting to a server, working completely offline.

Thus, along with HTML5, we are revisiting the philosophy of focusing part of the application processing on the client, thereby building a fat client. Thus, there is a great challenge that is the maintainability of Javascript code. In fact, there is a steady increase in the complexity and size of the application code and this becomes a problem because the code in this language is not easily maintained and intelligible when it assumes large proportions.

This article starts a series of posts that intends to discuss these problems and some of its solutions we found to deal with. Stay tuned.

No comments :

Post a Comment