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.

1. Multi View Constructed right
Eduardo M. Fleury
BossaConference 2010 - Manaus
Multi View Constructed right
Eduardo Madeira Fleury
BossaConference 2010 - Manaus

2. Agenda
1 Introduction
2 Proposed architecture
3 Example
4 Real world issues
5 Conclusion

3. Everybody wants code that is
• Easy to understand and learn
• Easy to maintain
• Easy to extend or modify
• Less prone to bugs

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. 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. Need to support new technologies
• Qt widgets
• Qt canvas (Graphics View)
• Qt Quick (QML)
• Other toolkits

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. Proposed architecture

9. Identify important concepts in your app
• Access data
• Use data
• Keep application state
• User input
• User output

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. 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. 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. Component relationship
Figure: Relationship

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. Example

16. Component relationship

17. Real world issues

18. Difficulties arise in practice
• Over-engineering
• Excessive complexity
• Poorly chosen interfaces / slice points
• Promiscuity between components
• Too much indirection in data flow

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. 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. 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. 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. 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. 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. 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. Bad Component relationship
Figure: Bad Relationship

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. 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. 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. 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. Questions
Questions ?

32. Thank you!
eduardo.fleury@openbossa.org
blog.eduardofleury.com