Best Practices for Cross-Platform Native Applications

2,471 views

Published on

Learn

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

No Downloads
Views
Total views
2,471
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
31
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Best Practices for Cross-Platform Native Applications

  1. 1. Best Practices for Cross-Platform Mobile Apps<br />Kevin Whinnery<br />Engineer and Platform Evangelist<br />Appcelerator, Inc.<br />@kevinwhinnery<br />
  2. 2. Kevin Whinnery<br />Engineer and Platform Evangelist<br />Appcelerator since 2008<br />Husband and father of three:<br />Web developer and JavaScript slinger turned mobile and desktop hacker.<br />http://kevinwhinnery.com<br />http://twitter.com/kevinwhinnery<br />http://github.com/kwhinnery<br />
  3. 3. Agenda<br /><ul><li>Cross-Platform UI Approaches
  4. 4. Component-Oriented Applications
  5. 5. Modular JavaScript Techniques
  6. 6. Code Walkthrough</li></li></ul><li>Cross-Platform in Titanium<br /><ul><li>Cross-Platform !== “Write Once, Run Everywhere”
  7. 7. Cross-Platform in Titanium means:
  8. 8. 100%* Non-visual code reuse
  9. 9. Lots of UI code reuse, depending on design
  10. 10. Best-in-class experience on every platform
  11. 11. “Write Once, Adapt Everywhere”**</li></ul>* This isn’t always true, but we’re working in that direction<br />** Term coined by Yehuda Katz, SproutCore, jQuery, and Rails contributor<br />
  12. 12. Cross-Platform Interface Guidelines<br /><ul><li>Maybe we’ll call this the C-PIG (pr. Sea Pig)?
  13. 13. The best Titanium applications are conscious of their target platforms, and meet user expectations
  14. 14. Cross-platform applications are useless unless they blend seamlessly with the best applications on a platform
  15. 15. Take the time to learn the UI conventions of the platforms you’re targeting</li></li></ul><li>Characteristics of iOS Interfaces<br /><ul><li>Touch centric
  16. 16. Gestures are central to hiding complexity
  17. 17. Uniformity in UI conventions is encouraged with rich controls and well-defined interaction models
  18. 18. HIG is required reading</li></li></ul><li>Characteristics of Android Interfaces<br /><ul><li>Touch and hardware interaction
  19. 19. Activities are central elements
  20. 20. Interfaces are less homogenous
  21. 21. Android Interface Guidelines is required reading</li></li></ul><li>Reconciling Cross-Platform UIs<br /><ul><li>Focus on the primary task
  22. 22. Sketch out an information architecture for apps on all platforms
  23. 23. Based on those exercises, pick out the common components for re-use</li></li></ul><li>Cross-Platform Approaches<br />
  24. 24. Schools of Cross-Platform Thought<br />Platform Identity<br />Brand Identity<br /><ul><li>Immediately Familiar to platform users
  25. 25. Self-evident navigation and interaction models
  26. 26. Polished look that makes an app feel like it belongs on the platform
  27. 27. Evocative of emotions around the brand
  28. 28. Able to create new, engaging experience not seen before
  29. 29. Not bound by platform UI conventions</li></li></ul><li>Platform Identity: GetGlue<br />
  30. 30. The Platform Identity Approach<br /><ul><li>Different designs and interaction models for each app
  31. 31. Individual UI components could be reused, the rest would be platform specific
  32. 32. Common UI conventions and components are used
  33. 33. Win for a developers: 100% non-visual code reuse, and 50% or better UI code reuse
  34. 34. Tradeoff: Less reuse, more is done for you (UI controls)</li></li></ul><li>Brand Identity: LNJF <br />
  35. 35. The Brand Identity Approach<br /><ul><li>UI is almost identical across platforms (immersive UI)
  36. 36. Small differences:
  37. 37. Android back button support
  38. 38. Transitions – iOS: animated transitions, Android: new activities
  39. 39. New UI conventions are created and must be learned
  40. 40. Win for developers: 100% non-visual code re-use, 80-90% UI code re-use, strong branded experience
  41. 41. Tradeoff: More reuse, less is done for you</li></li></ul><li>Which Approach is Right For You?<br /><ul><li>Depends on the primary goal of your app
  42. 42. If speed, data interaction, and utility are core to your app, a platform identity approach may be better
  43. 43. If emotional connection to brand and engagement are most important, a brand identity approach may be better</li></li></ul><li>Component-Oriented Applications<br />
  44. 44. Component-Oriented… What’s That?<br /><ul><li>A large app is made up of 100s of smaller, self-contained pieces
  45. 45. Really, just good OOP
  46. 46. Regardless of your cross-platform approach, this style of thinking and programming is important</li></li></ul><li>Advantages of a Component Arch.<br /><ul><li>100 small pieces are easier to understand and debug than 20 very large pieces
  47. 47. Easier to handle orientation changes
  48. 48. Easier to adapt cross-platform
  49. 49. Enhances reusability
  50. 50. Decouples your application, making it more adaptable to changing requirements</li></li></ul><li>Modular JavaScript Techniques<br />
  51. 51. Classic Module Pattern<br /><ul><li>Uses Ti.include to split modules into files
  52. 52. Requires steps to avoid polluting the global scope (Namespaces)
  53. 53. Can use constructor style or factory style</li></li></ul><li>Classic Module Style: Example<br />
  54. 54. CommonJS Module Pattern<br /><ul><li>Uses require to split modules into files
  55. 55. Secure by default – no self-calling function boilerplate or namespaces (strictly) required
  56. 56. Can use constructor style or factory style</li></li></ul><li>CommonJS Module Style: Example<br />
  57. 57. Walkthrough: Platform Identity Style<br />
  58. 58. Questions?<br />
  59. 59. Thank You!<br />

×