0
Mobile Development      with HTML5                      Hunter Loftis                     @hunterloftis              hunte...
Hunter Loftis• Director of Technology at Skookum DW• JavaScript nerd• (2001) Print illustration• (2003) Flash animation• (...
grain of salt:I’m not a mobile expert. I’m a JavaScript expert.
Status4: Golf          gtggolf.com  Realtime, distributed teamscoring on iPhone, Android, and          Blackberry.
Mobile HTML5  Open-Source          github.com        /madrobby/zepto/hunterloftis/backbone.viewmodel
So?Today, we’ll discuss and distill the   lessons learned from these    experiences into practical  guidelines for buildin...
Before you jump in   ask yourself three questions:
Can I build this natively?• You know (or have time to learn) the  language and APIs.• You can target a single platform.• Y...
Why mobile HTML5?• You are a front-end web expert (or team).• Support for many current & future devices.• Faster, cheaper ...
Mobile web, or hybrid?• web: URLs, browser security model, and  immediate deploys/updates• hybrid: app stores, device secu...
Starting the app    The easy parts
Quick Start    https://github.com/skookum/mobilehtml5         http://hunterloftis.com/mobile/(demos are intentionally un-f...
Install Stuff• iPhone Simulators (xcode)• Android SDK & debugging bridge:• adb logcat browser:V *:S
1. Run offline 2. Present this page           as an app.  3. Show icons and     startup screens 4. Prompt to installto the ...
5 Minutes InYou have a container, now youneed content and functionality.
Building the app    A survival guide
Do touch yourself.ontouchstart, ontouchmove, ontouchend,             ontouchcancel          (soon in zepto.js)
Ignore standards and    accessibility.
Debug on real devices.iOS: settings > safari > developer > debug console:on          Android: browser > “about:debug”
Forget jQuery.
Avoid frameworks.
Use alert().And confirm() and prompt(). Seriously.
Learn microlibsmicrojs.com, zepto.js, add2home, lawnchair, okay.js
Aim low.
Never use your iPhone.
Ignore feature  detection.     (usually)
Use specific forms.       email, tel, url, date, number, range*placeholder, autofocus, autocorrect, autocapitalize
Limit DOM updates.
Never animate with    JavaScript.
Animate with CSS3     (but only on iOS)
Assume you’re offline.
Store data locallysession storage, local storage, websql, indexed, lawnchair
Keep it async.A RESTful JSON API over HTTPS is cool and full of                  acronyms.
Embrace geolocation navigator.geolocation.getCurrentPosition()   navigator.geolocation.watchPosition();
Protect your state.
Turn yourself off.
Link to phones & maps       “maps.google.com/*”       “tel: (704) 123-4567”      “sms: (704) 234-5678”
And have fun!
•   Qs? @hunterloftis or hunter@skookum.com•   slideshare.net/HunterLoftis/mobile-html5-v2•   github.com/Skookum/mobilehtm...
Mobile html5 v2
Mobile html5 v2
Mobile html5 v2
Upcoming SlideShare
Loading in...5
×

Mobile html5 v2

2,363

Published on

Published in: Technology, Design
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,363
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
25
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • “tap” events are interpreted by the browser and have an inherent delay of ~300ms .. which makes your app feel slow and unresponsive.\n
  • 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
  • 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
  • ...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
  • 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
  • - 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
  • \n
  • 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
  • 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
  • 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
  • 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
  • Repainting elements, adding, removing elements = super expensive operations on a phone.\n
  • It’s incredibly slow on most phones, while CSS3 animations are GPU-accelerated on iOS.\n
  • GPU accelerated on iOS. Not all Androids have GPUs or browser-based acceleration, so turn it off for everything else.\n
  • 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
  • 5MB limit\n
  • \n
  • \n
  • \n
  • 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
  • \n
  • \n
  • \n
  • Transcript of "Mobile html5 v2"

    1. 1. Mobile Development with HTML5 Hunter Loftis @hunterloftis hunter@skookum.com
    2. 2. Hunter Loftis• Director of Technology at Skookum DW• JavaScript nerd• (2001) Print illustration• (2003) Flash animation• (2004) Web design & development• (2006) Web apps• (2012) Mobile apps
    3. 3. grain of salt:I’m not a mobile expert. I’m a JavaScript expert.
    4. 4. Status4: Golf gtggolf.com Realtime, distributed teamscoring on iPhone, Android, and Blackberry.
    5. 5. Mobile HTML5 Open-Source github.com /madrobby/zepto/hunterloftis/backbone.viewmodel
    6. 6. So?Today, we’ll discuss and distill the lessons learned from these experiences into practical guidelines for building mobile HTML5 apps.
    7. 7. Before you jump in ask yourself three questions:
    8. 8. Can I build this natively?• You know (or have time to learn) the language and APIs.• You can target a single platform.• You have the resources to support and maintain per-platform code bases.• Your audience will commit to your app.
    9. 9. Why mobile HTML5?• You are a front-end web expert (or team).• Support for many current & future devices.• Faster, cheaper dev cycles.• Daily platform improvements for free.• You accept the 50% performance penalty.
    10. 10. Mobile web, or hybrid?• web: URLs, browser security model, and immediate deploys/updates• hybrid: app stores, device security model, and gated deploys/updates• you can do both, but it’s harder than you think.
    11. 11. Starting the app The easy parts
    12. 12. Quick Start https://github.com/skookum/mobilehtml5 http://hunterloftis.com/mobile/(demos are intentionally un-factored and verbose; apply proper engineering to real projects)
    13. 13. Install Stuff• iPhone Simulators (xcode)• Android SDK & debugging bridge:• adb logcat browser:V *:S
    14. 14. 1. Run offline 2. Present this page as an app. 3. Show icons and startup screens 4. Prompt to installto the home screen.
    15. 15. 5 Minutes InYou have a container, now youneed content and functionality.
    16. 16. Building the app A survival guide
    17. 17. Do touch yourself.ontouchstart, ontouchmove, ontouchend, ontouchcancel (soon in zepto.js)
    18. 18. Ignore standards and accessibility.
    19. 19. Debug on real devices.iOS: settings > safari > developer > debug console:on Android: browser > “about:debug”
    20. 20. Forget jQuery.
    21. 21. Avoid frameworks.
    22. 22. Use alert().And confirm() and prompt(). Seriously.
    23. 23. Learn microlibsmicrojs.com, zepto.js, add2home, lawnchair, okay.js
    24. 24. Aim low.
    25. 25. Never use your iPhone.
    26. 26. Ignore feature detection. (usually)
    27. 27. Use specific forms. email, tel, url, date, number, range*placeholder, autofocus, autocorrect, autocapitalize
    28. 28. Limit DOM updates.
    29. 29. Never animate with JavaScript.
    30. 30. Animate with CSS3 (but only on iOS)
    31. 31. Assume you’re offline.
    32. 32. Store data locallysession storage, local storage, websql, indexed, lawnchair
    33. 33. Keep it async.A RESTful JSON API over HTTPS is cool and full of acronyms.
    34. 34. Embrace geolocation navigator.geolocation.getCurrentPosition() navigator.geolocation.watchPosition();
    35. 35. Protect your state.
    36. 36. Turn yourself off.
    37. 37. Link to phones & maps “maps.google.com/*” “tel: (704) 123-4567” “sms: (704) 234-5678”
    38. 38. And have fun!
    39. 39. • Qs? @hunterloftis or hunter@skookum.com• slideshare.net/HunterLoftis/mobile-html5-v2• github.com/Skookum/mobilehtml5• github.com/hunterloftis/backbone.viewmodel• http://hunterloftis.com/mobile/• “Safari Web Content Guide”• http://microjs.com/• http://zeptojs.com/
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×