Kindle Fire opened an Open source model for mobile

With rise of open source software platforms everyone was convinced that the Open source model will never go down. But start of 2007 Apple announced about their new innovative mobile technology ‘iPhone’. Apple came with an appealing and winning model, most of them agreed. 
What it also brought is closed and proprietary model that wouldn’t leave a scope for mobile open source platform. They said mobile and open source together would not work. That this market was too closed. That the carriers would not allow any openness. 


It turned out to be false, because Google made Android open source and it became the fastest growing OS of all time, passing Apple at a speed nobody expected. Here comes the ray of hope for mobile to go open source again, but again not everyone was optimistic about Android that time.
Today we hear about Kindle Fire and I am confident that it is going to be the biggest competitor for Apple in mobile space. Well, I wouldn’t term ‘kill’ as it is not going to suddenly drop Apple market but it will live with it for a while. Good question to ask is – how did Amazon managed to challenge Apple in a jiffy?


Open Source.


Think about it. Amazon took an open source mobile operating system (Android), forked it, changed the UI a little and added a few apps. With that, it is going to build the most successful tablet of our times.


Amazon couldn’t stand a chance without open source. It gave them speed and time-to-market. It gave them a stable and high-quality platform. The ability to compete and innovate. And maybe the biggest advantage of all: an enormous development community. All things we always said open source would bring to the table, making a huge difference.


The Kindle Fire is yet-another demonstration of the power of open source. The innovation is not going to stop here. Expect even greater things in the future. With the market moving towards HTML5 and the open web, we'll be talking about the dominance of open source and openness again and again. 


And yes, open source in mobile is doing way better than in the PC world. And yes, it is clearly showing to be the winning model. 

What is Open Source?

Open Source Software (OSS) is a computer software which is developed and distributed openly. The development can be undertaken by individuals, groups or communities, organizations,companies,educational institutions and all sorts of other combinations of developers.

The basic principles of Open Source Software are controlled by a number of different license types:

GPL - gnu General Public License - which, in very brief summary, says that the source code of the software must be made available, can be changed by anyone, provided that all copyright notices are left intact and that any on-provision of those modifications is covered by the same license;

BSD - Berkeley Software Distribution License - which, in brief summary, is very similar to the GPL license except that you do not need to on-provide the source code.

MPL - Mozilla Public License - which, in again brief summary, is similar to GPL but it allows redistribution of executable under separate license - so if you make a modification or a special version of a system you are able to distribute that in executable form only - but the devil is very much in the detail here big grin


There are many many more license types within the Open Source world.

But, Open Source Software does not automatically imply "Free".  Many valid and excellent Open Source projects ask an initial purchase price for their software - but, depending upon the license they are operating under, they may distribute that software with the Source Code so that you can then add to, enhance, or modify the software to suit your requirements - as long as you stick to the terms established in the original license.

Ultimately, all of this has a revolutionary effect on the software and the availability of software components for developing your own programs.

Total Cost of Ownership (TCO) and migration costs are lower, licensing costs and tracking are eliminated, your software is more likely to be secure, stable, future-proof - its better no matter the angle!

Navigation timing API

Introduction

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

The API will allow web application to gather performance metrics about various factors such as page redirect, DNS lookup, connection & secure connection statistics, request/response time, various events, etc. that were not possible with API script before.

Following is the graphical representations of a typical HTTP request response cycle for a web page.

Use case

Performance measurement has always been a bottleneck for web applications. The traditional way to calculate page load time is to write JavaScript to measure page load time. But in majority of cases they are unable to provide exact figures for user latency as in case of below script. It calculates the time it takes to load the page after the first bit of JavaScript in the head is executed, but it does not give any information about the time it takes to get the page from the server.

var start = new Date().getTime();

function onLoad() {

  var now = new Date().getTime();

  var latency = now - start;

  alert("page loading time: " + latency);

}

Examples

The previous example can be modified to measure a user's perceived page load time.

function onLoad() {

  var now = new Date().getTime();

  var page_load_time = now - performance.timing.navigationStart;

  alert("User-perceived page loading time: " + page_load_time);

}

Good question to ask is that the ‘Date’ object will rely on system date time set on user machine which can be easily tampered between the performance measurements. To resolve this, browsers will record monotonic time by recording system date time while starting performance calculation.

All new knockout JS will certainly knock you out!

Recently while I was going through my linked in news feeds I happen to come across a post from one of my friend which briefly mentioned knockout JS, my curiosity took me to its website.

Watching the 20 minute video from the founder; completely knocked me out. I must say I fell in love with this amazing JS library. 

Here are few interesting features that knockout JS provides, you would read the same on its website

1.  Declarative Binding
2.  Automatic UI refresh
3.  Dependency tracking
4.  Templating

With these features in place; and a strong MVVM design patter knockout JS stands out from other JS libraries.  

Apart from this, Knockout JS also has an excellent community support, which generally lacks with most of the libraries that hosted publicly.

Where do I go from here?

For more details, examples, source, and downloads, see the project’s homepage at http://knockoutjs.com

The Messaging API

Introduction

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.

Use case

To describe use case, first I would say many browser today already support messaging by supporting frequently used ‘mailto’, and not so frequently used ‘sms’ URIs. While the API certainly addresses a different use case (access from scripting code), it would be very useful to describe how the URI-initiated messaging is different or equivalent to the API-initiated messaging. For example, should browsers make sure that the user experience is always consistent across these two methods of messaging? Or is it acceptable if URI-based messaging uses an external user agent whereas API-based messaging uses a browser's internal capabilities?

At the very least, it would be useful to point out that URI-based messaging exists, and that page authors have the option of using URIs instead of having to write scripting code. in terms of accessibility and platform robustness, it will be quite a while until page authors could rely on the API alone; at least as a fallback solution, messaging URIs probably always are a good idea.

Since not all devices will have all messaging functionality (e.g. a phone may have only SMS and MMS while a PC may have only e-mail) there is a need to indicate that implementations need only expose available functionality.

Examples

The following code extracts illustrate how to create and send messages. Sending an MMS with an attached picture, if device supports it.

function successCB() {

   alert("The Message has been sent successfully");

}

function errorCB(error) {

   alert("The Message could not be sent " + error.code);

}

if (navigator.device.sendMessage) {

   picture = document.getElementById('attachment').files[0];

   navigator.device.sendMessage("mms:+460000000001?body=Welcome%20%to%Atlantis", [picture], successCB, errorCB);

Multiple Inheritances in java and the controversy

In my early bachelor's degree when I was starting to begin familiar with languages like C and C++, Our teachers use to point us to this unique problem of multiple inheritance and how it causes ambiguity in the inherited class, the solution was to use virtual functions/inheritance, it seem to be a fix that was added to C++ as it was not thought earlier while designing the C++ language.

Later during my master's degree, this new language called "java" starting to pick up waves and I was kind of impressed with it earlier being a new language and always wanted to explore it. I remembered how C++ solved the problem of multiple inheritances, and was curious of how java would play with it.

Most of them believe that multiple inheritances are possible in java through java interface. However I have a difference in opinion here.

According to me inheritance is

• Inheriting the implementation
• Inheriting the declarations

Inheritance of implementation is inheriting the actual code that does the work when the method is called which is done in case of C++ multiple inheritance and which is not possible to do in case of java

Inheriting only the method declaration and variables for one or many such classes for which the implementation will be written in its subclass is called inheritance of interfaces which is a bit different from the concept of multiple inheritances and it’s only possible in java. An interface defines all of those methods that an object exposes to either its subclasses or other classes.

When you inherit from a class in Java you get both inheritance of interface and implementation. All methods in the super class become part of the subclass's interface. However, when you implement an interface you only inherit interface and must provide implementations for each method.

When a Java class implements multiple interfaces you do run the risk of naming clashes. A class can implement two interfaces that share the same method name and return type. Say for example you have the following interfaces:

public interface MyFirstInterface{

                public void myFirstMethod();

}

public interface MySecoundInterface{

                public void myFirstMethod();

}

A class called MyFirstInheritance can come and implement these two interfaces at the same time without difficulty. However there may be a problem. Chances are if this happens the resulting class with not be able to provide an implementation that satisfies the expected behavior of both the interfaces at the same time. Even if you go ahead and provide and implementation for myFirstMethod() this may not make sense if you simply view the object as an MyFirstInterface or MySecoundInterface.

So what's the solution? If you have access to the source code the best course of action is to rename the methods in either of the above cases. If you don't have access, you are stuck.

HTML5 Web Storage API

Introduction

This specification allows web application to store the data in structured and persistence manner. This storage mechanism is similar to HTTP session cookies. But the web storage resolves the problems that are with cookies implementation like

• Storage limit: Cookies can store 4KB data only
• Performance issues: With every request cookies are transmitted to server
• Accessibility issues: Per domain there are numbers of cookies created by different browsers

The web storage can be categorized into session storage (per browser session) and local storage (persistent across multiple sessions).

Session storage: Web application can store data into session store which can be accessible by same application within any window opened in same/another browser session/instance. The data stored into this storage is cleared off when a browser window is closed.

Local storage: This storage type allows application to store data that can be persisted across multiple browser session or reboots. It can act as a permanent repository to store data that is required to be remembered by your computer unless user tries to clear the data using browser’s data clean up wizard.

While we think of power to store in better way the good questions to ask are what about security of data and what about storage limit/constraint. Though the data is stored per domain and will be restricted by browser to have access to that domain only there are going to be potential risks from cross-directory and DNS spoofing attacks. On the space limit, W3C specifies the ideal space limit to be 5MB but it can be up to the browser vendor to decide. In order to not navigate away from the theme to describe the API let’s move on to the user cases.

Use case

There could be many scenarios where one can think of using web storage to achieve some purpose, like storing data for sticky notes, remembering how many times user visited a page, bookmarking page number in a flip book application where user has left last time, language preference user selected during signing into an application and many more.

If we use cookies to remember how many items user has added it to a shopping cart for an eCommerce transaction then we might have cross-window transaction issues. If a user is buying movie ticket in two different windows, using the same site then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same movie without really handling the scenario. Session storage for this situation would solve this problem.

Another good example to use local storage is to cache the metadata information for a diagram creation tool. The tool can allow user to draw a diagram and add multiple components which user might just leave in the middle without actually pushing draft to server. When this happens tool might store information about components, their position, colors, settings, etc into a local storage so when user resumes the tool can re-apply design panel with same state of diagram that user had created earlier.

Example

http://html5demos.com/storage

Java design Techniques – Using Interfaces Part – 2

This article will talk more about role of interfaces and its usage while choosing between multiple inheritance and composition in your design I personally believe multiple inheritance implementations is basically inflexible. And this inflexibility maps directly to the inflexibility of inheritance as compared to composition.

By composition, I simply mean using instance variables that are references to other objects. For example, in the following code, class Apple is related to class Fruit by composition, because Apple has an instance variable that holds a reference to a Fruit object:

class Fruit {

    //...

}

class Apple {

    private Fruit fruit = new Fruit();

    //...

}

In this example, Apple is the front-end class and Fruit is the back-end class. In a composition relationship as a thumb rule, the front-end class always holds a reference in one of its instance variables to its back-end class.

Composition usually yields more flexible code. I identified the following flexibility advantages for composition:

• It's easier to change classes involved in a composition relationship than it is to change classes involved in an inheritance relationship.
• Composition allows you to delay the creation of back-end objects unless they're needed. It also allows you to change the back-end objects dynamically throughout the lifetime of the front-end object. However with inheritance this is not true, you get the image of the super class in your subclass object image as soon as the subclass is created, and it remains part of the subclass object throughout the lifetime of the subclass.

The one flexibility advantage I identified for inheritance was:

• It's easier to add new subclasses (inheritance) than it is to add new front-end classes (composition), because inheritance comes with polymorphism. If you have a bit of code that relies only on a super class interface, that code can work with a new subclass without change. This isn't true for composition, unless you use composition with interfaces.

In this above flexibility comparison, however, inheritance is not as secure as it might seem given its polymorphism advantage. That last clause above, "unless you use composition with interfaces," is very important. Basically, thanks to interfaces. Here's an example:

interface Peelable {

    int peel();

}

class Fruit {

    // Return int number of pieces of peel that

    // resulted from the peeling activity.

    public int peel() {

        System.out.println("Peeling is appealing.");

        return 1;

    }

}

class Apple implements Peelable {

    private Fruit fruit = new Fruit();

    public int peel() {

        return fruit.peel();

    }

}

class FoodProcessor {

    static void peelAnItem(Peelable item) {

        item.peel();

    }

}

class Example {

    public static void main(String[] args) {

        Apple apple = new Apple();

        FoodProcessor.peelAnItem(apple);

    }

}

Given the above set of classes, you could later define a class Banana like this:

class Banana implements Peelable {

    private Fruit fruit = new Fruit();

    public int peel() {

        return fruit.peel();

    }

}

Like Apple, class Banana has a composition relationship with Fruit. It reuses Fruit's implementation of peel() by explicit delegation: it invokes peel() on its own Fruitobject. But a Banana object can still be passed to the peelAnItem() method of class FoodProcessor, because Banana implements the Peelable interface.

As this example illustrates, interfaces allow you to get the best of both worlds. You get the flexibility of composition and the flexibility of polymorphism in one design.

HTML5 Web notification API

Introduction

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.

Let me first introduce you to the various types of the notifications so it will be easy to explain different use cases for.

• Ambient notification: A notification which appears and disappears automatically without user action.
• Interactive notification: A notification which can receive events from user actions and deliver them to the application which created the notification.
• Persistent notification: A notification which is displayed until the user explicitly dismisses it.
• Notification platform: A notification platform is a system outside the browser which provides desktop notifications. Examples include Growl on MacOS, NotifyOSD on Linux, and the Windows notification API.
• Simple notification: A notification which consists only of an icon and one or two lines of text.
• Web notification: A notification which consists of Web platform content, such as HTML or SVG.

This specification provides an API to generate simple notifications to alert users outside of the web page. When this specification refers to displaying notifications on the "desktop", it generally refers to some static display area outside the web page, but may take several forms, including:

• a corner of the user's display,
• an area within the chrome of the browser,
• the "home" screen of a mobile device

User case

When an application need to display email related notifications to user about ‘new email arrived’ it can display ambient notification with new email subject, from, etc. fields or it can display an interactive notification with an ability to return to inbox.

An application where it needs to display a upcoming meeting notification that the user might have set in his calendar or interactive notification that will allow user to snooze the meeting reminder for specific time interval.

Sometimes it can also span over wide range of notifications where say some one has posted on user’s comment, status on Facebook and user has opened multiple tabs in browser where Facebook needs to notify user about this activity.

Some application like Flicker or Picasa might want to notify user about his image upload completion progress by the time he has navigated away from the current tab.

One of the security aspects that need to be considered by an author is to make sure that the user has granted permission for a notification to appear on his platform.

Examples

Notification objects dispatch events during their lifecycle, which authors can use to generate desired behaviors. The show event occurs when the notification is shown to the user -- this may be at some time after the show() method is called in the case of limited display space and a queue. In the following example, this event is used to guarantee that regardless of when the notification is shown, it is displayed for only 15 seconds.

var notification = new Notification("mail.png", "New Email Received");

notification.onshow = function() { setTimeout(notification.cancel(), 15000); }

notification.show();

When a meeting reminder notification is acknowledged, the application suppresses other forms of reminders.

var notification = new Notification("calendar.png", "Meeting about to begin", "Room 101");

notification.onclose = function() { cancelReminders(event); }

notification.show();

HTML5 Server-Sent API

Introduction

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. It can also be used to implement connectionless Push notification as described in below use case.

When we would like to push data to web pages over HTTP or using some dedicate server-push protocol this API can be used. It offers the use of EventSource interface to implement this functionality. Using this API we will need to create an EventSource object and registering an event listener to show various readyState as CONNECTING (numeric value 0), OPEN (numeric value 1) and CLOSED (numeric value 2).

While the connection is alive with the server the user agent will be required to parse and interpret the event stream of MIME type text/event-stream

Use case

In case of Stock application when we would like to minimize the load on client especially if it is on the portable device like mobile to save battery power and reduce network load the push notifications can certainly help. This will require server side implementation to support pushing of data to client. This can be a good alternative rather than using XMLHttpRequest or an iframe.

The browsers on mobile handsets tied to specific carriers, may offload the management of the connection to a proxy on the network. In such a situation, the user agent will be implementing the connectionless push notification with the help of some ‘push proxy’.

For example, a browser on a mobile device, after having established a connection, might detect that it is on a supporting network and request that a proxy server on the network take over the management of the connection. In between two messages, the browser detects that it is idle except for the network activity involved in keeping the TCP connection alive, and decides to switch to sleep mode to save power. Here the browser will disconnect from the server and the "push proxy" service will contact the remote HTTP server and requests the resource and if available then it will convey the event to the mobile device, which wakes only enough to process the event and then returns to sleep.

This can reduce the total data usage, and can therefore result in considerable power savings.

The only challenge is if user is opening multiple pages from the same server that is using this API. In such cases isolated domain per page might be required to solve the problem or implementing push objects with the help of Webworker API.

Examples

The user agent will create the EventSource object as described below and have a listener for incoming data.

var source = new EventSource('stockupdates.cgi');

source.onmessage = function (event) {

alert(event.data);

};

On the server-side, the script ("stockupdates.cgi" in this case) will send messages in the following form, with the text/event-stream MIME type:

data: This is the X stock value for AAA stock option.

data: This is Y stock value for BBB stock option

data: with deviation from previous value as 4.