Category Archives: HTML5/JS

Viewport Meta Tag

Default Meta Tag

This is the default meta tag required to display the HTML5 app as it is without scaling, i.e. a scale of 1.0.

<meta name="viewport" content=" user-scalable = no, target-densitydpi = device-dpi, initial-scale=1, maximum-scale=1, width=320"/>

Note that we have used ‘device-dpi’ for ‘target-densitydpi’ as the default. Other values are ‘low-dpi’ (120dpi), ‘medium-dpi’ (160dpi), ‘high-dpi’ (240dpi).



An app built for the iPhone usually follows the ‘medium-dpi’ setting and if the device-DPI of a phone/tablet is lower than the ‘medium-dpi’, the HTML5 UI will appear larger (scaled up) which is generally acceptable. However, if the device-DPI is higher than the ‘medium-dpi’ that the app is developed based on. The HTML5 app will shrink and look too small compared to the physical screen dimensions, and this is not acceptable. To correct this, we need to set the ‘target-densitydpi’ value from ‘device-dpi’ to ‘medium-dpi’ for devices with higher resolutions.

In Javascript, we can use window.devicePixelRatio for Webkit browsers. A value of 1 is a 1:1 ratio of a virtual pixel to a physical pixel, a value >1 represents a high-density display.

If we do not want our HTML5 app to appear smaller than the DPI that the HTML5 app was designed for, the meta for ‘viewport’ will need to be altered dynamically as below:

if (window.devicePixelRatio>1) { // DPI higher than medium-dpi
var metatags = document.getElementsByTagName('meta');
for(cnt = 0; cnt < metatags.length; cnt++) {
var element = metatags[cnt];
if (element.getAttribute('name') == 'viewport') {
element.setAttribute('content','user-scalable = no,target-densitydpi = medium-dpi,initial-scale=1,maximum-scale=1, width=320');


Tagged ,

HTML5 Offline Solution

Although PhoneGap is an offline solution where the HTML, CSS and JS files etc are held in the assets/www folder within the app, there are some cases where you might want the app to point to a remote server where the HTML5 file and its CSS/JS are located. They can be downloaded onto your device and ran as offline files when the device has no Internet connection.

The requirements to trigger the HTML5 offline cache are detailed below and each requirement must be implemented with care, otherwise it will not work:

1) The MIME Type for a Manifest file.
This is very important. Previously I have followed a solution to add a mime type by using a .htaccess file and place it together with index.html of my HTML5 app, but it didn’t work.

In my case, I was using the Tomcat server and the surefire way that the .manifest file will be correctly used by the server, is to modify “/conf/web.xml” and add in the mime mapping as below:

2) Specify the Manifest File
This is a standard configuration. For every HTML file that wants to use the cache manifest, they have to update their tag to

3) Configure the Manifest File
The manifest file is a text file that you have configure to tell the HTML5 app what is to be cached for offline use. A sample file is below:

# Version 0.1

# Explicitly cached entries

# All other resources (e.g. sites) require the user to be online.

* note that the manifest file only caches static resources such as .html, .js and images, so files like JSP pages will not be applicable here.

***VERY IMPT: Each entry to be cached must be correctly named and if the entry is there, the physical file must be there, otherwise the whole caching will fail!

4) For iOS, steps 1-3 are sufficient for HTML5 offline caching to work. However, in the case of Android, we need to fix the Android Shell Native App to enable HTML5 caching:

In your class, there are these lines of codes to be added as part of the solution to enable HTML5 caching:
public class App extends DroidGap {
public void onCreate(Bundle savedInstanceState) {





Tagged , ,

HTML5 App Within a Native Shell App

The 2 previous postings were about getting the native apps up and running for their respective Android and iOS environments. The official guide takes you to a Hello World index.html which merely displays a static message. In reality, the app that your user will interact with is the UI of the index.html or the HTML5 app. The underlying native app that runs the index.html is what I call a Shell Native App.

So, the actual primary app is a HTML5 file with various supporting web libraries to fulfill the functions of a full-fledged mobile app. Generally, it should have the following supporting technologies to give it the native look and feel and experience:

1) jQuery (
2) AJAX (With AJAX, our mobile application can send data to and retrieve data from a server asynchronously (in the background) without interfering with the UI experience of the existing page.)
3a) jQTouch (
3b) jQuerymobile (

As for the Shell Native Apps, they host the app icon, the splash screen, PhoneGap libraries and other native information. If you require certain native functions, it is inevitable that you will need to modify the natives codes for your Shell Native Apps. A good example would be the implementation of Push Notifications for both iOS and Android, you are unable to do this in the HTML5 app, which means you have to put in codes in your Shell Native App.

In summary, PhoneGap is a bridge that allows the HTML5 app to call PhoneGap Javascript (JS) methods which will call PhoneGap native methods in your Shell Native Apps, of course there are native events that can call JS events which you can use in your HTML5 apps. Not all native methods can be called from JS, so some native programming would be expected depending on your app requirements.

Tagged , ,