AngularJS (Angular) is the hot new kid on the JavaScript (JS) frameworks block.  It supports single-page applications and unlike some other frameworks it has a concise Model-View-Controller setup.  Coming from a strong Adobe Flex background, Angular felt like home with its easy two-way data-binding, service models and dependency injection.  Over the past few weeks I’ve done a deep dive into Angular and this demo application is just one part from the fruits of my labor.

The application utilizes the Rotten Tomatoes API to display the top 50 box office movies, allows progressive filtering, local pagination, inspecting movie details and favoriting movies with local storage.  Feel free to browse the source code.  I built this in about 3 days, so you’ll have to excuse a few rough edges here and there, but I’m pretty happy with the results overall.  It uses jQuery, Bootstrap, Angular, Angular UI, Bootbox, LessCSS and Modernizr.  Note that I’m not compiling my LessCSS down to css prior to execution.  In a normal production environment you’d want to do this, but for demonstrative purposes I like to keep it all out in the open for quick updates.

I’ve marked up the source code heavily with comments to describe some of the details of the implementation.  I’m in the process of rebuilding the application using BackboneJS and will write up an extensive blog comparing the development pros and cons of each framework.  Place your bets now on which one you think will win!

I’ve been playing around with HTML5′s new Canvas tag and trying to convert some of my old Flash particle and proximity experiments.  My favorite of these trials has always been the web spinning art (which unfortunately is no longer working on the blog).

By using a grid-based proximity manager, you click and drag your mouse across the canvas.  As you drag, particles are created at your point of contact.  They have a random direction and velocity.  Particles are slightly attracted to each other, so depending on how much velocity they have, they will turn inward towards each other.  There is also friction in the environment that cause the particles to slow down and eventually disappear.

While the code (especially the proximity manager) is pretty ugly, I do take advantage of some new features of the canvas tag, as well as use object-pooling to speed up object creation.

If you are unfamiliar with object-pooling its pretty simple.  When I create a particle, it runs it course and is no longer needed, rather than wait for garbage collection to clean up the particle, I move it to a dead-particles array.  When a new particle is requested, rather than instantiating a new particle (and thus using more memory), I first check if there are any dead particles that can be reused and grab one of those.

I have two versions of the web spinner, a mouse-only desktop version and an multi-touch version for tablets & phones.  The multi-touch version does not use the ‘lighter’ blend mode or multiple random colors to help speed up performance.  Also note, that since these are experiments, I’ve done no testing on browsers outside of Chrome or optimized to make touch/mouse events interchangeable.

var aGlobalProperty = "I'm global!";

{
     var aBlockScopedProperty = "I'm block scoped!";
}

console.log("aGlobalProperty" + aGlobalProperty);
console.log("aBlockScopedProperty" + aBlockScopedProperty);
// I'm global!
// I'm block scoped!

/*If JS had block scope, this would result in 'undefined' 
  for our aBlockScopedProperty since it should have existed
  only within our brackets above.

  Unfortunately JavaScript does not provide blockscope, and 
  consequently, it can be difficult to organize code in a
  manner that does not allow for easy access and manipulation 
  of properties. Thankfully, JS does provide functional scope. 
  Properties created within a function are private to that 
  function and its descendants. */

var aClosureFunction = function() {
     var aFunctionalScopedProperty = "I'm functionally scoped!";
     console.log(aFunctionalScopedProperty);
     // I'm functionally scoped!
};

/* Here our property has printed out as normal since it has access to it
   from within the function. */

  If I tried to do any of the calls commented out below, I would get
  either a TypeError undefined or a ReferenceError since the property
  isn't visible from outside the function. (note that there is more
  wrong with the commented out log statements than just the scope) */

//console.log("outside function: " + aFunctionalScopedProperty);
//console.log("or from function: " + aClosureFunction.aFunctionalScopedProperty);

Functional scope does allow us to do some clever tricks to help encapsulate our properties and protect them from outside meddling and colliding property names.  Lets take a look at a few types of the common closures.

var aGlobalVariable = "I'm global!";
function myGetterFunction() {
   var notGlobal = "I'm not global!";
   return function() {
     return notGlobal;
   }(); // self executing
};

/* Now if I were to try to access 'notGlobal'
   from outside the function, I'd get an error.
   However, I can still access it by executing
   the myGetterFunction function and setting
   the result to another function */

var firstAccess = myGetterFunction();

console.log( firstAccess ); // I'm not global!

/* The resulting function now gives the rest of
   our application access to the value of notGlobal in
   our myGetterFunction.

   Lets take this idea one step further and allow
   the properties to be modified via global getter and
   setter functions */

var getVar;
var setVar;
(function() {
   var notGlobal = "I'm a different not global property!";
   getVar = function(){
      return notGlobal;
   }
   setVar = function(value) {
      notGlobal = value;
   }
})();

console.log( getVar() );
// I'm a different not global property!

setVar("You've changed me.");
console.log( getVar() );
// You've changed me.

/* Our closure is complete because our global functions getVar
   and setVar still keep access to the anonymous self-executing
   functions notGlobal variable. We are able
   to update and modify it at will with our getVar() and setVar()
   functions that were passed back in returned object map.

   We're able to do this bit of cleverness due to
   JavaScript's awesome, and sometimes frustrating, ability
   to treat nearly everything as a transferable piece of
   data - even functions! */

console.log( firstAccess );
// I'm not global!

/*  */

Also notice that even though both ‘myGetterFunction’ and the getVar/setVar functions both have properties named ‘notGlobal’ they are both unique. We have prevented them from being global through the use of our functional scope closures.

Now lets take it one step further and create a utility class that creates new string generating functions.

function addSurname(surname) {
	var name = surname; // this actually isn't necessary as we'll see later
	return function( firstname ) {
		return firstname + " " + surname;
	}
}

var makeLannister = addSurname("Lannister");
var makeStark = addSurname("Stark");

var theQueen = makeLannister("Cersei");
var theImp = makeLannister("Tyrion");

var theHand = makeStark("Eddard");
var makeBestCharacter = makeStark("Arya");

console.log('The Queen: ' + theQueen);
// The Queen: Cersei Lannister
console.log('The Imp: ' + theImp);
// The Imp: Tyrion Lannister
console.log('The Hand: ' + theHand);
// The Hand: Eddard Stark
console.log('The Best Character: ' + makeBestCharacter);
// The Best Character: Arya Stark

Neato! You should now be getting a better feel for how closures can help simplify your code and protect your properties from meddling. Unless our new function ‘makeLannister’ gets overridden, we never have to worry about it’s hidden ‘name’ property being changed.

Lets take a look at one final practical example where we use closures to help extend objects.

function makeWarrior( name, weapon, armor) {
	var life = 100;
	function _fight() {
		return (name + ' swings his ' + weapon );
	}

	function _defend() {
		life = life - 25;
		return (name + ' takes a hit on his ' + armor);
	}

	function _getLife() {
		if( life > 0 ) {
			return (name + ' has ' + life + ' points.');
		} else {
			return (name + ' is dead.  So sad.');
		}
	}

	return { fight:_fight, defend:_defend, getLife:_getLife }
}

var sandorClegane = makeWarrior('The Hound', 'great sword', 'heavy armor');
sandorClegane.fight();

var bronn = makeWarrior('Bronn', 'sword and dagger', 'light armor');
bronn.fight();

console.log( sandorClegane.fight() );
// The Hound swings his great sword
console.log( bronn.defend() );
// Bronn takes a hit on his light armor
console.log( bronn.defend() );
// Bronn takes a hit on his light armor
console.log( bronn.getLife() );
// Bronn has 50 points.
console.log( bronn.defend() );
// Bronn takes a hit on his light armor
console.log( bronn.defend() );
// Bronn takes a hit on his light armor 
console.log( bronn.getLife() );
// Bronn is dead.  So sad.

/* Lets make a new warlock that uses
   closures to extend our warrior function */

function makeWarlock( name, type, weapon ) {
	var uber = makeWarrior(name, weapon, 'mage robes');
	_defend = uber.defend;
	_uberFight = uber.fight;

	uber.fight = function() {
		return (name + ' uses his ' + weapon + ' to avoid fighting directly.');
	}

	function _castSpell() {
		return (name + ' casts an ' + type + "'s spell");
	}

	return { castSpell:_castSpell, fight:uber.fight, defend:_defend, uberFight:_uberFight};
}

var pyatPree = makeWarlock('Pyat Pree', 'illusionist', 'cunning');
console.log( pyatPree.castSpell() );
// Pyat Pree casts an illusionist's spell
console.log( pyatPree.fight() );
// Pyat Pree uses his cunning to avoid fighting directly.
console.log( pyatPree.defend() );
// Pyat Pree takes a hit on his mage robes
console.log( pyatPree.uberFight() );
// Pyat Pree swings his cunning

Through the use of our ‘uber’ object that keeps a reference to our original warrior object we can continue to access its properties in their original form.  We assigned our original warrior’s fight function to _uberFight BEFORE we overrided it with our own fight function. This is a bit convoluted, but it demonstrates how REFERENCES are passed around. Had I created our new uber.fight function BEFORE assigning uber.fight to _uberFight, they would both print out the same message.

We aren’t designating any new properties to store the passed in arguments used by our warrior or warlock functions.  This works because we are passing in primitive string objects.  If our functions were to take objects, the passing by reference of object may cause problems if those objects were modified outside of our function.

I hope this helps clarify closures!

What is a “Classical Object Oriented model?”
Many people believe that the word “classical” in “classical OO” has something to do with tradition, or a history of OO programming. This is actually incorrect. The word classical in this instance actually refers to the base word “class,” which in OO means a data structure that allows one to create unique instances of objects through classes.  If you are familiar with Java or ActionScript3, you have most likely used classes.

How is “prototypal inheritance” different from “classical inheritance?”
Classes can inherit from other classes by extending them. When one class extends another, the extended class is often referred to as the base, super or parent class. For the purposes of this article, I will refer to them as a parent and child relationships when referring to inheritance. The child class inherits a specified set of methods and properties from the parent class.

Prototypal inheritance is based off an an actual instance of an object – not the construct to create that instance. So when you create your parent object with all its specific properties and methods, the child inheriting from the parent gets all the original objects values. They’re live and will change automatically for the child when its created.

I like to think of classical inheritance as blue-prints. You ‘construct’ things from blueprints, and each one will be unique and different. When a child gets a hold of the original parent’s blue-print, it can add on rooms and make changes, but it won’t affect any of the objects already created with either child blue-prints, or their parents.  It also does not require any parent objects to be created in order to create children.  They can be created directly from their own blueprints.

Prototypal inheritance on the other hand is like building with sheets glass. You create a new huge sheet of glass, and specify all the properties that object will need. Your child then is another sheet of glass put on top of the original. You can keep adding sheets of glass for other children to lay on top of the original. When a change occurs to the original parent sheet of glass though, its automatically seen by all the other child layers of glass on top of it. Thats because our prototype inheritance is live and uses real object instances!  The important thing to note is that the child cannot function without an instance of a parent – without that initial sheet of glass, the other layers of glass break.

Lets see prototypal inheritance in action!

// Create my base person object
var BasePerson = function( ) {
     this.sex = 'male';
     this.occupation = 'worker';
     this.name = 'John Doe';
}

var myBasePerson = new BasePerson();
BasePerson.prototype.whoAmI = function() {
     return 'A ' + this.sex + ' ' + this.occupation
             + " named " + this.name + '. \n';
}

console.log('myBasePerson: ' + myBasePerson.whoAmI() );
// basePerson: A male work named John Doe.

// Lets create our base artist object to inherit from
var BaseArtist = function() {
     this.media = 'mixed';
     this.artStyle = 'various';
     this.occupation = 'artist';
}
BaseArtist.prototype = myBasePerson;
BaseArtist.constructor = BaseArtist;
var myBaseArtist = new BaseArtist();
myBaseArtist.occupation = 'artist';

/* TIP: If you completely replace a prototype, its good
practice to reset the constructor back to the
the object you are defining - as I did above */
var dcholth = new BaseArtist();
dcholth.name = 'D.C. Holth';
console.log( dcholth.whoAmI() );
// A male artist named D.C. Holth.

console.log( myBasePerson.whoAmI() );
// A male worker named John Doe.

/* Note that both my objects are still able to use whoAmI()
and that they both still access this.occupation, even though
they are not the same .occupation in memory anymore. The 'this'
declaration points to our new instance, not the prototype or
global space */

// Painters are another subsection of artists.
var BasePainter = function() {
     this.paintingStyle = 'Traditional';
}
BasePainter.prototype = myBaseArtist;
BasePainter.constroctor = BasePainter;
// You can also attach properties to the prototype
// by putting them directly onto the property in
// literal notation
BasePainter.prototype.media = 'paint';

// Now lets create some instances of our painters
var monet = new BasePainter();
monet.artStyle = 'impressionistic';
monet.name = 'Monet';

var maria = new BasePainter();
maria.artStyle = 'abstract';
maria.name = 'Maria Cosway';
var dali = new BasePainter();
dali.artStyle = 'surrealist';
dali.name = 'Dali';
// Sending some information to our console we can see that
// our prototype and its children are working correctly.
// We have 'artists' with their own unique 'art style'.

console.log('Monet's occupation: ' + monet.occupation );
//Monet's occupation: artist

console.log('Monet's style: ' + monet.artStyle + '\n' );
//Monet's style: impressionistic

console.log('Maria Cosway's occupation: ' + maria.occupation );
//Maria Cosway's occupation: artist
console.log('Maria Cosway's style: ' + maria.artStyle + '\n');
//Maria Cosway's style: abstract

console.log('Dali's occupation: ' + dali.occupation );
//Dali's occupation: artist
console.log('Dali's style: ' + dali.artStyle + '\n' );
//Dali's style: surrealist

// When we ask our function to execute whoAmI() it is still
// using our original whoAmI function from myBasePerson
console.log( dali.whoAmI() );
// A male artist named Dali.

// Lets update so that all our artists get access to a more
// specific whoAmI dealing just to artists.
BasePainter.prototype.whoAmI = function() {
     return this.name + ' is a ' + this.sex + ' ' + this.occupation
     + ' who uses ' + this.media + ' to make '
     + this.artStyle + ' artwork \n';
}
console.log( dali.whoAmI() );
// Dali is a male artist who uses paint to make surrealist artwork

console.log( maria.whoAmI() );
// Maria Cosway is a male artist who uses paint to make abstract artwork
// Wait a second? Maria isn't a MALE artist!

// now I'm sure you know by now that you could simply
// do maria.sex = 'female' and all only she will become
// female. But lets have a little fun here.

// By changing the prototype from which BasePainter's inherit,
// all the way down to myBasePerson, we can have
// EVERYONE be female automatically!
myBasePerson.sex = 'female'

console.log( dali.whoAmI() );
// Dali is a female artist who uses paint to make surrealist artwork

console.log( maria.whoAmI() );
// Maria Cosway is a female artist who uses paint to make abstract artwork

console.log( myBasePerson.whoAmI() );
// A female worker named John Doe.

// Also note again, our whoAmI() function didn't change
// for our myBasePeron object

/* Suddenly we have changed the sex of ALL our people!
This is because of that 'glass analogy' I used earlier.
When the underlying parent glass is changed, it shines
through to all our objects! So when we changed the sex
of our very early prototype object 'myBasePerson' all
the children that inherited from it also became female! */

// lets go ahead and switch everyone back to male, and just
// make Maria female
myBasePerson.sex = 'male'
maria.sex = 'female';
console.log( dali.whoAmI() );
// Dali is a male artist who uses paint to make surrealist artwork

console.log( maria.whoAmI() );
// Maria Cosway is a female artist who uses paint to make abstract artwork

console.log( myBasePerson.whoAmI() );
// A male work named John Doe.

You may have noticed that I never used the keyword ’new’ in the above code block.  I have mixed feelings on using ‘new’ to stamp out objects.  In one respect, I view it as a hold-over to make JavaScript appear to be more classical in its nature.  The fact is, its not a classical language, and trying to mold it into something its not can confuse the mental process needed to understand its prototypal nature.   Using ‘new’ isn’t bad in the right instances, but in my opinion one should find alternatives when ever possible.

Hopefully through the examples above you can see how prototype-inheritance can help  you organize your code and create more efficient prototype-inheritance objects!

Reference/Credit: http://www.intohand.com/post.php?s=2011-02-17-android-debug-bridge-not-just-working-on-mac

Whipsersync for Voice (WfV) and the combination of Kindle & Audible.com allows one to have almost non-stop reading.  When it is available on a title, its like magic!  I might pick up my Kindle in the morning before work and read a few pages.  When I’m finished reading, my position is automatically updated to the cloud.  If I hit the gym over lunch, I can fire up Audible on my phone and it jumps me to where I left of reading on my Kindle.  In the evening before bed, it takes me to where my Audible audio book left off!  This is the perfect companion of those who enjoy the convenience of being able to multitask with audiobooks, but also enjoy reading when they have the time.

Many of the titles that are available with WfV allow you to buy the Audible book and Kindle book at a reduced rate together.  I’ve found the average price of both the e-reader version and the audiobook are usually equivalent to the cost of a hardcover print edition.  Still a great value for the convenience.  Amazon has a separate category for Whispersync enabled titles, but I still wish they would add more titles and make it easier to tell which titles are enabled.  Amazon also provides a number of free e-reader titles with only small fees for the audio version ($2-3) to test out the service!

Since not every book is available with WfV, I have a few tips on making going from audiobook to e-reader easier.  If you have finished listening to the audiobook, note the last few words that were spoken.  Back on your e-reader, do a quick search for those words and it should jump you right to where you left in the audiobook.  Be careful for spoilers here, if you pick a phrase that may be common throughout the book, you might accidentally jump to the wrong location.

There isn’t a fantastic way to go from e-reader to audiobook, since the chaptering is often inaccurate in the Audible table of contents. However, they usually are broken into some form of chaptering, so if you finish your reading at a natural break you should have at least an easier time finding your spot… And thanks to my other favorite new feature of Paper White even that should be easier.

Built into the Paper White is chapter and book time estimation.  Based on ones average reading speed for a given title, it tells you how much more time you have for the entire book or chapter.  This is awesome for those nights when I’m really engrossed in a book, and a chapter ends on a cliffhanger, I can decide whether or not I want to start into the next chapter without skipping ahead to see how much more is left.

Another benefit of a Kindle e-reader versus a print book is the addition of x-ray.  This lets you explore the architecture of a book, highlighting characters, events and locations with summaries and graphs of their usage.  This is great for long, involved books, like Game of Thrones where there seems to be a new character every fifteen pages, or forget about certain characters when they appear many chapters later.  Hit the x-ray button, and you are given information about key words (character names, titles, locations, etc) on the current page- click on them and get more information.  You need to be a bit careful about spoilers here, but it certainly has been a great help when necessary!

As far as the Paper White goes as an e-reader, its light, responsive and the backlight is a great addition for reading in the dark or just in dim light.  The official case adds nice protection without much bulk.  I couldn’t ask for much more.  My only complaint has more to do with Amazon than the quality of their product and services.  It would be nice to have better filtering and notifications for which titles are available with Whipsersync for Voice.  Perhaps a wish-list feature that would notify you when a book is available.  I recently purchased all the Game of Thrones books since their Audible credit price was reduced from two (~$30) to 1 (~$15) thinking I could whip through them all by listening and reading.  Unfortunately, none of them are WfV enabled yet.  Other than that, I am very satisfied with the service and products.

Some of my recent reads using Whipsersync for Voice are shown below.

Our founding fathers created this great country with a few simple principles. One of those is freedom of religion. Part of the first amendment is the Establishment Clause, which states that “Congress shall make no law respecting an establishment of religion.” This works two fold in regards to the “Defense of Marriage” amendment.

The Establishment Clause works to the benefit of those religious establishments who feel they are defending marriage, it prevents the state from forcing them to do things against their beliefs, such as marrying gay couples or recognizing said marriages. Regardless of the passage or defeat of this amendment, that will remain true. However, it also prevents the state from establishing laws which would *prevent* churches from being allowed to marry gay couples if they so chose. While many Christian religions prohibit same-sex religious unions, there are many other religions and non-religious organizations that do not. Even if every religion prohibited it, that’s not the point. Our constitution isn’t supposed to be a codification of the bible or any religious teaching. It’s supposed to be devoid of specific religious influence, and protect the basic civil and human rights of its people.

While the essence of democracy is majority rule, our founding fathers were foresighted enough to put protections into our government system to ensure that the majorities rule could not encroach onto the rights of others. The passage of this amendment would violate one of the very principles of our constitution by preventing religious expression of those establishments that accept same-sex unions.

Next year I’ll be marrying the person I love: a wonderful asian woman. As recently as 1966, this would have been illegal. Many states had Jim Crow laws which prohibited marriage between races. In the case of Loving v. Virginia of 1967, it was determined that marriage was a “basic civil right of man.” My thanks goes out to those brave men and women who stood up to the persecutions of the past, so that I can marry the love of my life now. Denying marriage based on race was wrong then – denying it based on sexual orientation is wrong today.

The “Defense of Marriage” campaign is focused on opposing a “redefinition of marriage” to exclude same-sex couples. When our founding fathers laid out the constitution of our great country, the idea of a “civil union” was hardly a concept, let alone something one could outwardly practice. The word “marriage” was the obvious choice for describing unions between two people, and to establish the benefits thereof. I believe wholeheartedly that if they had seen todays outcome of using the word “marriage,” they would have opted for “civil union” for everyone – you would have gotten “married in a church” and “unioned” in the state.

However, even with the formation of civil unions as an alternative to marriage in some states, Minnesota does not allow civil unions between same-sex couples. Furthermore, in states that allow civil unions, the couples engaged in them are still be denied benefits at both a state and federal level. For a complete outline of exactly what benefits they are excluded from, check out the link below.

By legally defining the word “marriage” to strictly require a man and a woman, we will have excluded same-sex couples from hundreds of laws and benefits that are predicated on the word “marriage”. This would include all the federal and state benefits that apply to marriages. Modifying the laws to include “civil unions” and “marriage” would not only be difficult, it would ultimately create the “separate but equal” situation deemed unconstitutional during the civil rights movements of the past.

Other states have passed similar amendments. California and Massachusetts are tied up in expensive legal battles regarding the passage of similar “Defense of Marriage Amendments.” They have been deemed unconstitutional in both state courts, are on their way to the US Supreme Court.

This amendment issue *not* about the redefinition of a word. Its about continuing the conversation on expanding the meaning of that word to everyone – love, commitment and family. And that is why, this November, I am voting no to the “Defense of Marriage” amendment.
Boston Court rules Defense of Marriage unconstitutional
http://www.ca1.uscourts.gov/cgi-bin/getopn.pl?OPINION=10-2204P.01A

Loving v. Virginia, 388 U.S. 1
http://en.wikipedia.org/wiki/Loving_v._Virginia

Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof.
http://en.wikipedia.org/wiki/Establishment_Clause

An Overview of Federal Rights and Protections Granted to Married Couples
http://www.hrc.org/resources/entry/an-overview-of-federal-rights-and-protections-granted-to-married-couples

It is done in oils and is 24×30 inches.

Below are the sequential shots of the paintings progress after each of the nine painting session.

One of the greatest benefits of Android is that it gives customers the ability to chose a device with a UI and hardware most appealing to them.  This is also its greatest curse since it causes fragmentation in the Android ecosystem, a problem much more difficult for Google than it is for Apple and BlackBerry because Google doesn’t control the hardware.  The Android Update Alliance was created to guide device-makers and carriers towards updating their customers more quickly, but so far it seems dead in the water.   The small tweaks that carriers make to the OS help their devices stand apart, not just from other operating systems but other Android phones as well.  These differences make updating them much more difficult since the device makers need to ensure that every aspect of their customized version works on the latest update.  On top of that, the hardware-makers don’t see another dime from goods and services sold within the Android ecosystem, so there is little incentive for carriers to keep older phones up to date.  (Although I know I would have brand loyalty and be much more likely to continue buying a specific line of devices if the carrier guaranteed me the latest updates every time, but that’s a topic for a different post entirely.)

To make matters worse, two of the worlds most popular Android-based tablets are built on top of extremely dated versions of the OS.  Amazon’s Kindle Fire and Barnes and Noble’s Nook Tablet are both running customized versions of Android 2.3.  This forces developers to ask very difficult questions: “do we lower the features of our applications and potential quality to make one app that will run on all tablets, create two applications or ignore devices with older versions of the OS?” These are questions that iOS developers generally don’t need to ask themselves, thanks to Apple’s strict control over the hardware.  For a visual reference of just how much variation there is in Android versions out there, check out Michael Degusta’s chart, linked at the bottom of this post.

The bottom line is that Google needs to apply more pressure to carriers and device-makers to keep their customized versions in sync with the latest version of Android.  When a customer goes into the store, they should be able to look at a phones capabilities, hardware and customized UI without having to worry about whether or not their favorite apps will work on the device due to tweaked or outdated Android software.  It’s an incredible benefit to iOS users that Apple keeps much of its older hardware on the latest version of the OS, and I believe that’s one of the huge appeals of Apple’s ecosystem.  Google needs to give its user base that same assurance.

It’s my stance that phones should get the latest version of Android within two months of its release, and continue to receive updates for at least 2 years (This works in the USA where customers are typically offered a discounted phone upgrades at the end of a 2 year contract.  I’m not sure if this would be a good solution for customers outside the USA).  Tablets should get updates for at least 4 years from their release.   I realize that is forever in technology, but tablets are more expensive and beginning to replace laptops.  If I were a student who opted for a tablet over a laptop, I’d like to believe it will function fully for me through my college career.

My final thought – When a carrier no longer wants to provide updates to its customized versions, then they should open up their boot-loaders to allow the developer community to keep a device alive and up-to-date.  This will help give Android phones that are no longer in service contracts a second life as MP3 players, development devices and iPod touch equivalents.

- Android Orphans: Visualizing a Sad History of Support | October 26, 2011