HTML5 Webworker API

Introduction

This specification defines an API for running scripts in the background independently of any user interface scripts. This allows for long-running scripts that are not interrupted by scripts that respond to clicks or other user interactions, and allows long tasks to be executed without yielding to keep the page responsive.

Workers (as these background scripts are called herein) are relatively heavy-weight, and are not intended to be used in large numbers. For example, it would be inappropriate to launch one worker for each pixel of a four megapixel image.

Generally, workers are expected to be long-lived, have a high start-up performance cost, and a high per-instance memory cost.

User case

As the web worker API allows us to implement multi threading behavior to a web application imagine a Stock application requires doing multiple things at the same time, getting stock updates on timed interval and finding quotes for specific stock option based on user search criteria. This can be a very good example to think about web workers to be used.

Another use case could be where the application is required to display different views for the map say regular map view, satellite view, hybrid view and 3D map view displaying same region at the same time. User can switch between maps to move map directions in any of the views where all the maps should get updated to show the respective region in their view.

Examples

http://www.whatwg.org/demos/workers/stocks/page.html

http://robertnyman.com/html5/webworkers/webWorkers.html

HTML5 JS API specification and use cases

We all know that the HTML5 is new hot thing in the industry which everyone is trying to write about it, know more concepts, downside and curious about future of the web going ahead with this innovative standard – technology.Some might embrace it or some might criticize it whichever side of the debate you are on it will surely change the web development platform giving the power to do more – which we as geeks weren’t suppose to even think about it. Being W3C standards the browser vendors are now getting leaned towards supporting different features of it that included Microsoft Internet Explorer 9 too.

Things like jQuery, YAML, formatting techniques, and design trends change very quickly throughout the web community. And for the most part we’ve all accepted that some of the things we learn today can be obsolete tomorrow, but that’s the nature of our industry. But keeping aside that fear of not learning new thing we are going to know more about HTML5. If you Google it you will find tons of articles and blogs about HTML5 features and demos, mainly tags and new additions to HTML5 than older versions.

This blog is an attempt to gather HTML5 JS API information in one place instead of going through the traditional concepts only. As the HTML5 is in draft mode and it will change quickly, it is likely that some information outline below might get outdated. If that is the case, please get in touch so that I can update accordingly.

Below is the list of APIs in draft version by the time I wrote this blog. I am going to link them to specific posts in the blog that I will be writing the introduction and explaining the use case of each.

Web Workers

This specification defines an API for web developers to implement multi-threading running scripts in the background independently of any user interface scripts.

For more information http://geeksinaction.blogspot.com/2011/03/html5-webworker-api.html

Server-Sent Events

This specification defines an API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS.

For more information http://geeksinaction.blogspot.com/2011/03/html5-server-sent-api.html

Web Notifications

Web notifications are the ability for an application to notify user even if they are not at the web page in the form of small notification popup box. This creates a great deal for the web applications where even if the interaction between the web application and user is not in synch they can have notifications reached to the end user.

For more information http://geeksinaction.blogspot.com/2011/03/html5-web-notification-api.html

Web Storage

This specification allows web application to store the data in structured and persistence manner using key-value format. The web storage can be categorized into session storage (per browser session) and local storage (persistent across multiple sessions).

For more information http://geeksinaction.blogspot.com/2011/03/introduction-this-specification-allows.html

The Messaging API

 This specification defines an API that provides access to messaging functionality in the device, including SMS, MMS and email. It includes APIs to create and send messages. These APIs complement what sms:, mms:, and mailto: URI schemes provide with:

• the possibility to attach files to messages,
• A callback on success / error when a message is sent

For more information http://geeksinaction.blogspot.com/2011/06/messaging-api.html

Navigation Timing

This specification defines an interface for web applications to access timing information related to navigation and elements.

For more information http://geeksinaction.blogspot.com/2011/06/navigation-timing-api.html

Contacts API

HTML5 Web Messaging

File API: Writer

File API: Directories and System

File API

Web IDL

Permissions for Device API Access

The Media Capture API

HTML Media Capture

RDFa API

The Widget Interface

Geolocation API Specification

XMLHttpRequest Level 2

Indexed Database API

XMLHttpRequest

Cross-Origin Resource Sharing

API for Media Resource 1.0

The System Information API

Uniform Messaging Policy, Level One

Selectors API Level 2

Programmable HTTP Caching and Serving

The Web Sockets API

Selectors API Level 1

Web Forms 2.0

Java Design Techniques – Using Interfaces Part - 1

Interfaces give you more polymorphism and design freedom than singly inherited families of classes, let us prove this statement. 

Consider an example of singly inherited families of classes.

abstract class Animal {

    abstract void talk();

}

class Dog extends Animal {

    void talk() {

        System.out.println("Woof!");

    }

}

class Cat extends Animal {

    void talk() {

        System.out.println("Meow.");

    }

}

class Interrogator {

    static void makeItTalk(Animal subject) {

        subject.talk();

    }

}

Given these set of classes and inheritance, it becomes mandatory for you to pass only objects of the family Animal to the makeItTalk() function. 

Remember a very good design never mandates you on any obvious scenario that might occur in future. As in case of the above example it does and hence it’s not a very good design to follow. This is where interfaces come and save you.

Using Interfaces make your design more flexible. Interfaces give you more polymorphism and design freedom than singly inherited families of classes, because with interfaces you don't have to make everything fit into one family of classes. 

For example:

interface Talkative {

    void talk();

}

abstract class Animal implements Talkative {

    abstract public void talk();

}

class Dog extends Animal {

    public void talk() {

        System.out.println("Woof!");

    }

}

class Cat extends Animal {

     public void talk() {

        System.out.println("Meow.");

    }

}

class Interrogator {

    static void makeItTalk(Talkative subject) {

        subject.talk();

    }

}

Given this set of classes and interfaces, later you can add a new class to a completely different family of classes and still pass instances of the new class to makeItTalk(). For example, imagine you add a new CuckooClock class to an already existing Clock family:

class Clock {

}

class CuckooClock implements Talkative {

    public void talk() {

        System.out.println("Cuckoo, cuckoo!");

    }

}

Because CuckooClock implements the Talkative interface, you can pass a CuckooClock object to the makeItTalk() method:

class Example {

    public static void main(String[] args) {

        CuckooClock cc = new CuckooClock();

        Interrogator.makeItTalk(cc);

    }

}

With single inheritance only, you'd either have to some how fit CuckooClock into the Animal family, or not use polymorphism. With interfaces, any class in any family can implement Talkative and be passed to makeItTalk(). This is why interfaces give you more polymorphism and design freedom than you can get with singly inherited families of classes.

New age Mobile application development using MVC

In recent days, the technologies have started to emerge quickly with the latest innovations and older computing methods are getting back stage in the software development. I believe that one of the software development methods Model-View-Controller (MVC) can become one of most successful architectural pattern for the mobile application development permitting independent development, testing and maintenance at ease as always. Popular in Web application development, MVC is now finding a new age in mobile app development. Despite being decades old, MVC is being applied to the latest trends in software development: Web and mobile applications.

MVC is especially appropriate for Mobile applications. It can typically have a substantially larger number of specifically purposed user interface modules. So the more rigorous attention to mobile development that is implied by good MVC design makes keeping the design more tightly focused on single-purpose units that are consistent in their abstractions and play well together. At the same time, this pattern helps partition functionality into modules that can more cleanly defined with solid coherence while being more precise about limited cohesion where it properly belongs.

There are few mobile application development frameworks based on MVC pattern available in market. Sencha Touch is a powerful way to build mobile apps, and, because it relies entirely on web technologies, we can easily host those apps on the web server and have users find and access them directly from their mobile browsers. Another one is the M-project that contains all UI and Core files to build jQuery Mobile based mobile HTML5 Apps.

To write mobile application we can think of either of the below cited options to achieve a business need.

1. Purely native application using mobile specific development platform and libraries.
2. Web based application to address the mobile version of web. In this case HTML5 can play vital role to provide greater capabilities like storage methods, offline cache, etc.
3. Hybrid application – developed using Webkit control of mobile platform to render the view using HTML and platform specific APIs to implement the business logic.

Model

The model can be a collection of Java script objects or platform specific classes that form a software application intended to store, and optionally separate, data. A front end object that can communicate with any user interface (for example: a mobile specific custom control that represents graphical user interface or a web component like HTML).

View

The view can represented either by the HTML/HTML5 components or platform tailored UI controls, with ability to view data being transported to the page in various ways.

Controller

The Controller communicates with the front end of the model and loads view with appropriate data.

We can depict the MVC architecture for above mentioned development methods as show in diagram below.