Is Android fragmentation an issue?

For consumers? No. 

Consumers want the best phone they can afford. Android does exactly that by providing lots of options in a the entire price range. Do they really care if the phone have 512MB of RAM, 1.4Ghz Duo CPU, or another phone with 1GB RAM and a 1.9Ghz? They can't really tell the real benefits provided by the different phones. And they certainly don't care of a specific app is not on a certain phone if it means to pay $100 more (provided that most of the most popular apps are compatible with most phones).

For developers? Yes, but not really.

No because most apps will work just fine if you follow the best practices for Android. Unless you are doing something wrong, you won't run into any issues. There is a lot of gotcha's but answers are mostly on StackOverflow. Porting apps to different Android devices are not nearly as hard as coding in another platform.

Yes, and if you run into weird problems, there is not much help you can get, especially if you are using the newer APIs. After developing a dozen apps in different categories, SleepBot and Vine accounts for almost all the hardest problems because they interact with Camera, MediaRecorder, MediaPlayer, and opengl components. On the other hand, Squarespace and the other apps had no problem adopting all the platforms and devices, and at most you will be dealing some mistakes made on database related issues. I remember that one of the features for Vine encountered a different problem on each flavor of S2s because some functions were not implemented according to the SDK. This has gotten significantly better with 4.1+ devices, which is why Instagram is only 4.1+ when video was released as well. 

That being said, if you are not using any special hardware components or the more specialized APIs, there is nothing to worry about. Making a todo app is just as easy on Android than on iOS. 

How to make in page margin animations smooth for ViewPager pages

tl;dr modify the setOffScreenLimit dynamically. ​

In order to keep a constant length ViewPager scrolls smooth, setOffScreenLimit(page.length)​ will keep all the views in memory. However, this poses a problem for any animations that involves calling View.requestLayout function (e.g. any animation that involves making changes to the margin or bounds). It makes them really slow (as per Romain Guy) because the all of the views that's in memory will be invalidated as well. So I tried a few different ways to make things smooth but overriding requestLayout and other invalidate methods will cause many other problems.

A good compromise is to dynamically modify the off screen limit so that most of the scrolls between pages will be very smooth while making sure that all of the in page animations smooth by removing the views when the user. This works really well when you only have 1 or 2 views that will have to make other views off memory.

@Override
public void onPageScrollStateChanged(int state) {
  if(state==ViewPager.SCROLL_STATE_IDLE){
    if(mViewPager.getCurrentItem()==INDEX_OF_ANIMATED_VIEW){
        mViewPager.setOffscreenPageLimit(1); 
    }else{
        mViewPager.setOffscreenPageLimit(OLD_PAGE_LENGTH);
    }
  }
}

The real problem with using HTML5 for native apps

Yes, lagging is such a big problem right now with HTML5 and there is much heated debates (most recent on on HN) going on in the tech community, the advocates say that the biggest advantage is to allow "one code base for the same damn thing on multiple devices" while others say that it is not ideal yet because of speed.

Yes, speed is a big problem, but as we follow Moore's Law (and hopefully Koomey's Law as well), speed problems will go away even if Apple/Google tries to retard the mobile browsers (which IMHO they won't). 

​The real problem is that the same damn codebase cannot be used on multiple platforms. 

It just can't. Look at all the complaints Intagram got ​for its Android release because it didn't follow major Android guidelines. One of the major issues was the bottom tab bar. In iOS, that is totally ok, but for Android that is not an idea solution as the virtual/hardware keys are also right below. And this is just one of the major problems with fitting it. 

When we started designing SleepBot for iOS, we looked at so many apps for both platforms, and there are just so many differences that we have to do redesign almost all the major interactions and icons. (Notice how icons have a "realistic feel" in iOS, a modern feel in Android, and a futuristic feel in Windows Phone) 

That is Android, now let's take a step forward to Windows Phone 8. Can you even imagine directly porting an iOS app to it. It would look like SHIT and usability would be terrible because that is simply not how it works.  ​

What's gonna end up happening is that developers will start writing native bridges for performance tweaks and UI tweaks. These developers are usually not experienced in doing those as they usually have a web app background, so it ends up either wasting more time and more resources, for something worse. ​

Someone may argue that there will be "plugins" that will provide awesome native compatibility. Yea, I'd give those a shot, but good luck customizing your app. :) ​

If you want the best user experience for your users, at least within the next 5 years, go native. ​

(note: this is not about having a mobile version of your website and very simple one page apps that does not require complex navigation etc )​

P.S. If there is really someone that may disrupt everything, look at Parse's new feature:​

http://blog.parse.com/2012/09/11/welcoming-cloud-code-to-the-parse-family/​