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