Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Web and Native in 2012
Similar a Web and Native in 2012 (20)
Último
Último (20)
Web and Native in 2012
- 1. Web plus Native in 2012 @jhugman – James Hugman
- 2. Who is this guy? • Software Engineer • Programming: 20y, Mobile: 4y • Won awards for apps • Technology agnostic @jhugman
- 3. Order of Ceremonies • Latest results in Web v Native • Issues in cross platform development • Interesting projects • Predictions @jhugman
- 4. Web vs Native • Web: Developer friendly (except, when it’s not) • Native: User friendly (except, when it’s not) @jhugman
- 5. Web • Cross platform* • Existing libraries • Faster to develop* • Buzzword compliant • Massive developer mindshare @jhugman * Caveat emptor
- 6. Native • Better user experience • Tight device integration @jhugman
- 7. Gartner Hype Cycle Peak of Inflated Expectations Plateau of Productivity Slope of Enlightenment Trough of Disillusion Technology Trigger @jhugman
- 8. Cross-platform fallacies • “Write Once, Run Anywhere” • HTML5 is the answer @jhugman
- 9. Web based UIs • PhoneGap • Trigger.io @jhugman
- 10. Building UI with HTML • Webkit fragmentation • Desktop ≠ Mobile • High profile failures @jhugman
- 11. Write Once, Run Anywhere • UI metaphors differ between platforms • Negative messages to users: • “We don’t care [enough] about you” @jhugman
- 12. Important exceptions • When app is document focused • When utility trumps usability • Games @jhugman
- 13. Why Cross Platform? • For developers: • Less to learn • Less code to write • For business: • Lower cost of ownership @jhugman
- 14. Why Cross Platform*… Sucks? • For developers fewer tools • For users UX is compromised • For designers Design is compromised @jhugman
- 15. Something better • Native, platform specific UIs • Share as much other code as possible @jhugman
- 16. Architecture Sketch Presentation Layer Application Logic Layer Native API Layer @jhugman
- 17. Architecture Sketch • Implementation language • Execution language @jhugman
- 18. Technologies • Titanium JS • Ejecta UI in code • Kirin Portable Biz Logic • Calatrava • j2ObjC @jhugman
- 19. Javascript based
- 20. Building UI in Code Presentation Layer implemented in Javascript Application Logic Javascript Native APIs Native @jhugman
- 21. Titanium • The big hitter • Implement everything in Javascript • Execute UI in native @jhugman
- 22. Titanium + Good coverage of native APIs + Reasonable docs - Implement UI in JS, so crappy tools - Lists are hard to get right - Not easy to style @jhugman
- 23. Ejecta • HTML <canvas> and <audio> APIs • Implement in Javascript • Executed using native OpenGL and OpenAL @jhugman
- 24. Ejecta + Lots of existing libraries (e.g. Three.js, processing.js) + Faster than WebView’s <canvas> - Incomplete APIs for Graphics & Audio - iOS and Web only @jhugman
- 25. Honourable mention • MonoTouch & MonoDroid @jhugman
- 26. Mixed languages
- 27. Heterogenous Teams • Multiple people • Different skill sets • Only small overlaps in skill sets @jhugman
- 28. Shared App Logic Presentation Layer implemented in native Application Logic shared Native APIs Native @jhugman
- 29. Shared App Logic Obj-C Java HTML Application Logic shared @jhugman
- 30. Calatrava • Application logic in Javascript • Rubyist & Web developers version • Progressively enhance screens @jhugman
- 31. Calatrava + Start with HTML. Switch to native when needed. - Limited interaction between JS & Native - Not very extensible - Limited access to APIs - Bundles a JS engine per app @jhugman
- 32. Shared App Logic Your Obj-C Your Java Calatrava Your Shared Javascript @jhugman
- 33. Shared App Logic Your Obj-C Your Java Kirin Your Shared Javascript @jhugman
- 34. Kirin • Native mobile developers version • Designed for multi-disciplinary teams • Designed to be friendly to both ecosystems @jhugman
- 35. Kirin + Very extensible + Built on top of node.js and npm. - Limited access to APIs (currently) @jhugman
- 36. Shared App Logic Presentation Layer implemented in native Application Logic shared Native APIs Native @jhugman
- 37. j2ObjC • Java -> Objective C compiler • Google 20% project • Write in Java, execute natively on two platforms @jhugman
- 38. j2ObjC + GWT + Great tooling + Very extensible - Alpha release; Buggy - Not a tool suite @jhugman
- 39. Predictions • HTML5 on mobile will get better, slowly • Good but not great cross-platform solutions continue in small shops • Building multiple native clients will be accepted as the cost of doing business @jhugman
- 40. Summary • Business need will drive cross- platform • HTML UIs still difficult to make nice • Fertile ground for experimentation @jhugman
- 41. Thanks James Hugman – @jhugman
- 42. Links • Titanium: appcelerator.com • Ejector.js: impactjs.com/ejecta/ overview • Calatrava: calatrava.github.com • Kirin: github.com/kirinjs/kirin • j2objc: code.google.com/p/j2objc @jhugman
Notas del editor
- \n
- \n
- \n
- \n
- * caveat emptor\n
- This year, has been different. Both sides has given ground to the other, but most importantly the users needs have been taken into consideration\n
- Where is 3d printing? Drones?\nAugmented Reality, HTML5? \n\nMention \nFinancial Times measured success.\nfacebook HTML5 failure\n
- \n
- All with implementation languages/tools of HTML, CSS, JS.\nAll with execution languages of HTML, CSS, JS.\n\nVery popular, due to low barrier to entry. \n
- Are web UIs for mobile ready for building non-trivial apps yet?\n * Webkit fragmentation still a problem\n * Webkit on desktop browsers really good, so easy to mistake.\n * Touch events are still horrible\n * position: fixed still not widely implemented.\n * High profile failures. (Facebook)\n
- * UI metaphors differ between platforms.\n * Despite what your boss thinks, users notice and dislike this.\n * It's confusing. \n * It's jarring. \n * It says "We don't care enough^H^H^H^H about *you*". \n * It's nothing positive.\n * This is a problem if you have a Buy button anywhere in your app.\n
- * Users will forgive stylised web pages \n * if web metaphors are very well established (e.g. document focused), and \n * the users'/client's care about utility above every else. i.e. "good enough" is "good enough".\n e.g. Google Maps versus iOS6 Maps. \n e.g. Any website you don&#x2019;t care enough about their app.\n * Or you're building a game.\n * Or maybe your brand is so strong.\n
- \n
- * First generation Cross platform, including html\n\n
- \n
- \n
- Implementation Language: What language/tools does the app dev use? \ne.g. You write Titanium apps&#x2019; UI in Javascript \nExecution Language: What language/tools does the underlying implementation use\ne.g. Ti UIs are rendered natively.\n
- All of these projects make claims about how much time\n
- Optimizes for javascript access. \nOften at the expense of the other language.\n
- UIs Implemented in code: \nPoor tooling compared to native.\n- e.g. Easy to get wrong for different screen sizes\nLots of traffic between JS & native; either slow, or prone to memory leaks.\n
- \n
- Any time you&#x2019;re implementing in JS, lists will be hard to get right.\nPromises WORA, although doesn&#x2019;t do a great job\n\n\n
- \n
- This is really just for Games.\nPossible to extend, but not for the faint hearted.\nNo text. \n\nEarly days for the project.\n
- \n
- \n
- Stretch the skills of a single developer.\n
- Realistic \n
- \n
- Named after Santiago Calatrava, famous for his bridges.\n
- Very early stages of development\nDocs are not very good.\n\nContributions welcome.\n
- Calatrava is a very web centric.\n \nCurrently a very limited javascript to native bridge\nNeeds changes to the core to add extra features that use the bridge\n\nThis will make device access slow to add.\n
- Much more generalized js to native bridge.\n
- Named after the river creature from Japanese myth. A chimera with the body of dragon and a tail of a deer.\n
- Documentation lacking.\nContributions welcome.\n
- Realistic \n
- \n
- Currently a standalone compiler. Not a tool suite.\n
- \n
- \n
- \n
- \n
- \n