Mobile html5 v2

Editor's Notes

• #2: \n
• #3: \n
• #4: \n
• #5: \n
• #6: \n
• #7: \n
• #8: \n
• #9: \n
• #10: \n
• #11: \n
• #12: \n
• #13: \n
• #14: \n
• #15: \n
• #16: \n
• #17: \n
• #18: \n
• #19: \n
• #20: \n
• #21: “tap” events are interpreted by the browser and have an inherent delay of ~300ms .. which makes your app feel slow and unresponsive.\n
• #22: They don't matter (yet) on phones. It's hard enough to get something working; why design for an audience that doesn't even exist yet? For example:\nUse <div> instead of <a> (try both). You'll notice that on some phones, the <a> will still link after you interrupt it, and you have to prevent all of these defaults happening. Plus, since you'll be listening to the ontouchstart, you won't have a default to interrupt.\n\n
• #23: Typical web dev + emulators and simulators + test devices\niOs: settings -> safari -> developer -> debug console: on\nAndroid: type about:debug in the URL bar (for most androids)\nset up the android crazy SDK bridge thing\n
• #24: ...or any other cross-browser library. The vast majority of your audience (iOS, Android, Blackberry, Palm) renders via the webkit engine. Mobile devices are still relatively slow. Mobile browsers are still very slow and light on resources like memory. There's no excuse to drop heavy cross-browser libs like jQuery into the mix. (Android: 18%, iOS: 54%, Blackberry: 3%, total: 75% ... other 25% = Java ME & Symbian / old phones )\n\n
• #25: They’re big, bloated, difficult to customize, and when you have problems with a control (or several controls) -- functionality, appearance, or compatibility with different devices -- there is very little you can do, and it’s typically a real headache to make significant updates since the frameworks have a high level of complexity.\n\nIf you don’t believe me, try the “kitchen sink” demo of jQuery mobile, Sencha touch, etc on a blackberry, an iPhone, and an old Android... and see what happens.\n\nNote: I haven’t tried the latest frameworks in several months, and I’m hopeful for progress.\n
• #26: - rendered with native controls so they don’t make an impact on your app’s footprint\n- rendered and interacted with faster\n- feel native, consistent\n
• #27: \n
• #28: These days, most developers working with web apps aim high and gracefully degrade. We have turned to the "make it work on real browsers... safari... chrome... firefox... and then shim it for IE... workflow." We've gotten used to aiming for a great experience and providing fallbacks for anything that can't support it. Unfortunately, the mobile browser landscape is closer to 2006 than 2012. The majority of Android users are on the Android versions from 2010. Only 1% are on the latest OS. Hundreds of devices exist with different form factors, operating systems, browsers, CPUs, GPUs ... the way to stay sane is to aim low and progressively enhance for selected platforms (like iOS 5).\n\n
• #29: If you're constantly testing with your iPhone, you'll be misled into the idea that things are working better than they really are. The iPhone set the golden standard for a mobile web browser, and it's still unchallenged. The latest version of Android with Chrome has edged closer, but it still falls short. Test with an Android on 2.2 to get the real picture. You can pick them up basically for free.\n
• #30: Design your app offline first, then add network capability\ncache.manifest\nJS on app load to check and refresh cache if required\nMake it easy to disable offline caching (adds an extra layer of testing complexity)\n\n
• #31: Controls the type of keyboard/interface that is presented\nCan get super annoying to have autocorrecting login for example\nProvides convenient characters (@ for email, / for url, etc)\n
• #32: Repainting elements, adding, removing elements = super expensive operations on a phone.\n
• #33: It’s incredibly slow on most phones, while CSS3 animations are GPU-accelerated on iOS.\n
• #34: GPU accelerated on iOS. Not all Androids have GPUs or browser-based acceleration, so turn it off for everything else.\n
• #35: Design your app offline first, then add network capability\ncache.manifest\nJS on app load to check and refresh cache if required\nMake it easy to disable offline caching (adds an extra layer of testing complexity)\n\n
• #36: 5MB limit\n
• #37: \n
• #38: \n
• #39: \n
• #40: The first time we field-tested GTG, we (developers) were all confident that it worked, because we had been testing it on our iPhones, and doing occasional lab tests on our stock of Androids. 30 minutes into the 4-hour event, half of the phones were dead. All of the dead phones were Androids. Why? Android doesn't disable background processes - even web pages! - when the app is closed - or even when the phone is sleeping in your pocket! - so if you, for example, are polling Ajax (as we were), the phone's battery will just disappear. Later, we discovered that *some* Androids even restore old tabs immediately when the phone is restarted, meaning that until someone specifically turns off their phone, charges it, turns it back on, opens the browser and explicitly closes your tab... their phone will die over and over and over.\n\n
• #41: \n
• #42: \n
• #43: \n