Multi View Constructed Right

1,692 views
1,632 views

Published on

Developers have been facing increasingly stronger requirements
regarding application interfaces. Current UIs have to support
different resolutions, match different devices and be
themeable. Besides that, the technology used is ever-changing thus
trying to keep such applications with a fresh look may require a lot
of rework.

Many theories have been proposed for this problem but the actual
solutions not always work due to failures in real world
implementations.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,692
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Multi View Constructed Right

  1. 1. Multi View Constructed right Eduardo M. Fleury BossaConference 2010 - Manaus Multi View Constructed right Eduardo Madeira Fleury BossaConference 2010 - Manaus
  2. 2. Agenda 1 Introduction 2 Proposed architecture 3 Example 4 Real world issues 5 Conclusion
  3. 3. Everybody wants code that is • Easy to understand and learn • Easy to maintain • Easy to extend or modify • Less prone to bugs
  4. 4. We need code that • Can be created in parallel by the team • Assume look and feel of multiple platforms • Is future-proof regarding new GUI technologies
  5. 5. Need to support new devices • There is a lot more than re-compiling • Screen size and viewing distance • Environment of use • Looks / Platform integration • Input methods
  6. 6. Need to support new technologies • Qt widgets • Qt canvas (Graphics View) • Qt Quick (QML) • Other toolkits
  7. 7. A good architecture helps • Reduce the number of code-paths • Define relevant / semantic components • Do not define too many components • Define good component API and keep them independent
  8. 8. Proposed architecture
  9. 9. Identify important concepts in your app • Access data • Use data • Keep application state • User input • User output
  10. 10. Create component to access data • Handle DBs • Parse file meta-data (EXIF, ID3, etc) • Access different data sources (network, other apps) • Watch for data modification
  11. 11. Create component to handle program ’core’ • Use data (play a song, interpolate an image) • Keep application state • Respond to high level user requests • Provide high level user output data
  12. 12. Create component to handle user interaction • Listen to low level user input events • mouse click, keyboard pressed, remote control • Output information to user • Draw song title on the screen, beep when new message arrives
  13. 13. Component relationship Figure: Relationship
  14. 14. Expected result • Each component can be created in parallel by different people • Interface component can be modified to support new device • Interface component can use new technologies
  15. 15. Example
  16. 16. Component relationship
  17. 17. Real world issues
  18. 18. Difficulties arise in practice • Over-engineering • Excessive complexity • Poorly chosen interfaces / slice points • Promiscuity between components • Too much indirection in data flow
  19. 19. Over-engineering • We are brilliant at identifying patterns • We fail miserably when dealing with large number of items • Harder to make mental model of, or harder to understand • Harder to maintain and extend
  20. 20. Over-engineering Ask yourself • What is the use case? • What problem am I trying to solve? • What potential of growth does this application have? • Do I really need that now?
  21. 21. Excessive complexity • Default use cases are usually easy to handle • Corner cases together mean lots of code • Are such corner cases worth the extra effort? • Lots of features, lots of bugs too...
  22. 22. Excessive complexity Ask yourself • Some people are fetishists about useless features, avoid that! • Avoid bloatness as a whole • Define priorities, use your time wisely • Remember: • What is the use case? • What problem am I trying to solve? • Do I really need that now?
  23. 23. Poor component interfaces • Leads to an ’artificial’ division • Require data to be moved around • Poses obstacles to component replacement • Harder to be used and mentally modeled
  24. 24. Poor component interfaces Ask yourself • Public API should be thoroughly thought of • Look at the problem from above • Try and make analogies with real world situations • Find a whiteboard, think before you code • Discuss your architecture with your peers
  25. 25. Components inter-dependency • Components need to include other components • Components are not replaceable • Programmers cannot look at one class and understand it • Some patterns are well known and easier to recognize
  26. 26. Bad Component relationship Figure: Bad Relationship
  27. 27. Components inter-dependency Ask yourself • Is this class a provider or consumer? • Use Qt Signal/Slot do decouple components • Consider an abstract public API
  28. 28. Data-flow indirection • Data goes through several classes to reach its destination • One reading the code needs to imagine where does that come from • API gets dirty due to methods that mostly move data around • It can also be inefficient performance-wise
  29. 29. Data-flow indirection Ask yourself • Think about your whole application • Where is data coming from? Where is it going to? • Consider a high throughput link between consumer and producer • Find a good compromise between interdependence and indirection
  30. 30. Conclusion • There’s a need for good architectures • Good ideas exist • Many projects suffer from bad implementation of such ideas • Learn from yours and other’s mistakes • Homework: Find an useless feature in your favorite software
  31. 31. Questions Questions ?
  32. 32. Thank you! eduardo.fleury@openbossa.org blog.eduardofleury.com

×