Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (15)
Ähnlich wie Mobile html5 v2
Ähnlich wie Mobile html5 v2 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Mobile html5 v2
- 1. Mobile Development with HTML5 Hunter Loftis @hunterloftis hunter@skookum.com
- 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. grain of salt: I’m not a mobile expert. I’m a JavaScript expert.
- 4. Status4: Golf gtggolf.com Realtime, distributed team scoring on iPhone, Android, and Blackberry.
- 5. Mobile HTML5 Open-Source github.com /madrobby/zepto /hunterloftis/backbone.viewmodel
- 6. So? Today, we’ll discuss and distill the lessons learned from these experiences into practical guidelines for building mobile HTML5 apps.
- 10. Before you jump in ask yourself three questions:
- 11. 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.
- 12. 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.
- 13. 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.
- 14. Starting the app The easy parts
- 15. Quick Start https://github.com/skookum/mobilehtml5 http://hunterloftis.com/mobile/ (demos are intentionally un-factored and verbose; apply proper engineering to real projects)
- 16. Install Stuff • iPhone Simulators (xcode) • Android SDK & debugging bridge: • adb logcat browser:V *:S
- 17. 1. Run offline 2. Present this page as an app. 3. Show icons and startup screens 4. Prompt to install to the home screen.
- 18. 5 Minutes In You have a container, now you need content and functionality.
- 19. Building the app A survival guide
- 20. Do touch yourself. ontouchstart, ontouchmove, ontouchend, ontouchcancel (soon in zepto.js)
- 21. Ignore standards and accessibility.
- 22. Debug on real devices. iOS: settings > safari > developer > debug console:on Android: browser > “about:debug”
- 23. Forget jQuery.
- 25. Use alert(). And confirm() and prompt(). Seriously.
- 26. Learn microlibs microjs.com, zepto.js, add2home, lawnchair, okay.js
- 27. Aim low.
- 28. Never use your iPhone.
- 29. Ignore feature detection. (usually)
- 30. Use specific forms. email, tel, url, date, number, range* placeholder, autofocus, autocorrect, autocapitalize
- 32. Never animate with JavaScript.
- 33. Animate with CSS3 (but only on iOS)
- 35. Store data locally session storage, local storage, websql, indexed, lawnchair
- 36. Keep it async. A RESTful JSON API over HTTPS is cool and full of acronyms.
- 37. Embrace geolocation navigator.geolocation.getCurrentPosition() navigator.geolocation.watchPosition();
- 40. Link to phones & maps “maps.google.com/*” “tel: (704) 123-4567” “sms: (704) 234-5678”
- 41. And have fun!
- 42. • 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/
Hinweis der Redaktion
- \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&#x2019;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&#x2019;s typically a real headache to make significant updates since the frameworks have a high level of complexity.\n\nIf you don&#x2019;t believe me, try the &#x201C;kitchen sink&#x201D; demo of jQuery mobile, Sencha touch, etc on a blackberry, an iPhone, and an old Android... and see what happens.\n\nNote: I haven&#x2019;t tried the latest frameworks in several months, and I&#x2019;m hopeful for progress.\n
- - rendered with native controls so they don&#x2019;t make an impact on your app&#x2019;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&#x2019;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