Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Designing True Cross-Platform Apps


Published on

Alexander Blom
Isle of Code


Some people consider responsive design to be cross-platform, and responsive design to be resizing for containers. However, this misses the distinction of fluid design & often leads to slow and bad programmatic implementations. This talk will cover the distinction and provide pointers on how to implement responsive apps that are also performant.

Attendees should understand a differing view on how to build cross-platform apps, and the difference between fluid & responsive design.

Target Audience

Programmers, designers & cssers who think a single page with lots of media queries is a good idea.

Five Things Audience Members Will Learn

What is fluid design?
The difference between responsive & fluid design
Why are responsive designs often slow?
How to implement responsive designs that are performant
Bonus points to be revealed in talk!

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Designing True Cross-Platform Apps

  1. 1. whoami @alexblom
  2. 2. Isle of Code • Toronto + Chicago based development; • Focused on Ember/Cordova;
  3. 3. Our Goal • After a preamble; • Use a single Ember app, and render desktop + mobile; • Re-use the same Ember App for native applications;
  4. 4. • Using one code base for multiple platforms; • vs. building custom code bases for each platform; • Also handle mobile desktop/web sizing;
  5. 5. Wrapped Apps are everywhere
  6. 6. ember-cordova
  7. 7. Good Code == Good Hybrid • Much of making effective mobile is simply writing good code. • Desktops let us be lazier;
  8. 8. WKWebView
  9. 9. A note on deviceready • You probably need to use it for any custom initializers; • Has special handling. Even if you register the handler after deviceready fires, it will still be triggered.
  10. 10. Smoke & Mirrors
  11. 11. Flexi
  12. 12. Responsive v Fluid
  13. 13. • Bootstrap's .col-md-push-* and .col-md-pull-* classes are classic examples of using reflow design. Reflow utilizes floats and positioning to re-arrange portions of your DOM (in this case columns) for different viewport sizes. Reflow includes the use of classes like .offset-xs-6 to adjust margins and spacing. • Reorder design is similar to reflow, but it accomplished by using the CSS order property to alter the position of items displayed using flexbox for layout. Reorder is "cleaner" than reflow, but both suffer from significant browser layout and paint time performance issues •
  14. 14. Manage Reflows • “Reflow is the process by which the geometry of the layout engine's formatting objects are computed. The HTML formatting objects are called frames: a frame corresponds to the geometric information for (roughly) a single element in the content model; the frames are arranged into a hierarchy that parallels the containment hierarchy in the content model. A frame is rectangular, with width, height, and an offset from the parent frame that contains it.” • reflow.html
  15. 15. What causes Reflow? • Resizing the browser window; • using JavaScript methods involving computed styles; • adding or removing elements from the DOM; and • changing an element's classes. • reflow
  16. 16. What causes reflow? •
  17. 17. Use CSS Transforms
  18. 18. visibility:hidden
  19. 19. <link href="disabled.css" rel="stylesheet" disabled> • often end up downloading 2-3 sets of assets;
  20. 20. TouchBase
  21. 21. Standard Ember Structure
  22. 22. Standard Ember Structure
  23. 23. Taps • Tap targets should be ~48px;
  24. 24. Hammer Example
  25. 25. Our components are the same • We can re-use the same logic, routes & components. The templates are only visually different;
  26. 26. Media Queries
  27. 27. media queries
  28. 28. Media Queries • # of different css files matter? • # of media-queries matter? • Inline vs separate? •
  29. 29. Problems • Expensive reflow; • Code gets confusing & hard to follow quickly; • Can’t do anything complex;
  30. 30. Same Problems
  31. 31. Problems • Still hard to maintain; • Canonically don’t know where to find mobile vs desktop; • Components either need classes, or containers need selective classes; • We’re introducing a lot of complexity that is not needed;
  32. 32. • "fluid" only understands viewport boundaries, but often needs to know about the boundaries of some smaller container • "reveal" slows down renders by weighing down the DOM tree • "reflow" and "reorder" cause expensive layouts and paints. • "reveal", "reflow", and "reorder" can be hard to see and reason about. • "restructuring" is just as messy, and likely less performant. • layout CSS you can't see makes maintenance hard and adds a taxing mental overhead to every project developer. • layout CSS you can see (via layout classes) is overly verbose, and often difficult to wade through.
  33. 33. When looking at just the layout, it differs the most.
  34. 34. Layouts change. Components are fluid.
  35. 35. Flexi
  36. 36. desktop.hbs
  37. 37. mobile.hbs
  38. 38. • Ditches reflow & reorder patterns;
  39. 39. Already easier to follow
  40. 40. Elements • screen: 100% width, min-height of 100vh; • page: 100vw & 100 vh; • fill / fill block: fills parent; • centered: • box: grows to match other items, but not container; • hbox/vbox: fills remaining space, align horizontal/ vertical
  41. 41. For Emberists: sustain
  42. 42. Further Optimization • In guaranteed mobile only environments, try not to download desktop assets; • Images can be resized per platform; • Use fingerprinting to expire older assets;