Common Mobile Architecture

As mobile development finds its way into the enterprise world, the applications become increasingly more complex.

Quick and dirty solutions lead to unmaintainable, and even erroneous code. By applying an architecture using design patterns and proven best practices we avoid these problems.

And thus the need for a good architecture becomes ever so important. In search of a good methodology we discovered that, not surprisingly, the needs in various environments are the same, and can be tackled in the same way. Whether it's Android, HTML 5/CSS 3/JavaScript, iOS and maybe even other mobile platforms, the main building blocks of this architecture might always come back. The gains of a common architecture is that the principals behind it only need to be explained once, and can be applied on different platforms.

We will give examples "from the trenches", showing the various problems, and work towards their solutions on different platforms.

Transcript

1. Common mobile architecture
2. Your hosts Mike Seghers (@mikeseghers) Filip Maelbrancke (@fmaelbrancke) Consultants at iDA MediaFoundry (@iDAMediaFoundry)
3. Why this talk?
4. First off... Why mobile architecture? What is it? How to implement?
5. Architecture
6. You = McGuyver
7. Avoid problems
8. Build up confidence
9. ! Nerdvana “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” Tony Hoare
10. Relation to enterprise architecture?
11. Layered architecture
12. Dependency Injection
13. Relation to rich client architecture?
14. MVC View Model Controller Data retrieval Data changes User Gestures View Selection Events
15. Mobile challenges
16. Remoting
17. Data handling
18. Remoting
19. Naive client GUI thread View Remoting logic Transformation logic Storage logic Presentation logic CRUD operations Save data structure Remote Local storage
20. The problems with the naive approach
21. Naive approach = Let your users wait
22. A less naive approach GUI thread View Presentation logic Background thread Remote Local storage CRUD operations Save data structure Service Remoting logic Transformation logic Storage logic
23. Working towards a layered architecture Communication with remote systems Caching data in local storage Translation of data Keeping state of the cached data Passing data to the view layer
24. Remoting Services Remoting Service Remote API HTTP/JSON/XML AMF ProtocolBuffers
25. Adaptors Remoting Service Remote API HTTP/JSON/XML AMF ProtocolBuffers Adaptor Entities
26. Storage Remoting Service Remote API HTTP/JSON/XML AMF ProtocolBuffers Adaptor Data Source Entities
27. Local Storage Service Remoting Service Remote API HTTP/JSON/XML AMF ProtocolBuffers Adaptor Data Source Entities Local Service
28. Data Synchronisation What is still missing? Something to tie the services together and communicate with the GUI layer. Something to keep track of the state of our local data. Eg. when do we need to refresh the data from the backend?
29. Dataprovider Remoting Service Remote API HTTP/JSON/XML AMF ProtocolBuffers Adaptor Data Source Entities Local Service Data Provider GUI Layer
30. Statekeeper Remoting Service Remote API HTTP/JSON/XML AMF ProtocolBuffers Adaptor Data Source Entities Local Service Data Provider State Keeper GUI Layer
31. Non-blocking? We now know that we will handle data using the data provider, which encapsulates all data handling logic. However, we still didn’t tackle the “my-main- thread-is-blocked-for-a-while” problem.
32. Making things asynchronous 1. Using Events/Notifications
33. Making things asynchronous: Events Pros: Loose coupling Easy to implement Cons: Hard to maintain Hard to follow where all events end up Event storms!
34. Making things asynchronous 2. Callback system
35. Making things asynchronous: Callbacks Pros: Loose coupling Easy to refactor Easy to follow and to maintain Cons: Little more complex then eventing
36. Making things asynchronous: Implementing a callback system Responders and Callhandles
37. Responder explained caller callee calls • on X • on Y • on Z immediately returns • on X • on Y • on Z • on X • on Y • on Z other actors • on X • on Y • on Z
38. Callhandles explained callee caller calls immediately returns • on X • on Y • on Z
39. Tying it up! Remoting Service Remote API HTTP/JSON/XML AMF ProtocolBuffers Adaptor Data Source Entities Local Service Data Provider State Keeper GUI Layer Responder/ Callhandle Responder/ Callhandle
40. Back-end communication technologies
41. Back-end communication? SOAP RMI REST
42. REST
43. Backend optimizations?
44. Compress!
45. DRY
46. Data handling
47. CRUD via REST Method Operation Change? Idempotent? GET GET / SELECT ✔ ✔ POST INSERT ✘ ✘ PUT UPDATE ✘ ✔ DELETE DELETE ✘ ✔
48. POST Data Provider + State Keeper Remote Service Data Source insert set STATE_INSERTING update clear STATE_INSERTING
49. PUT update set STATE_UPDATING update clear STATE_UPDATING Data Provider + State Keeper Remote Service Data Source
50. DELETE update set STATE_DELETING delete Data Provider + State Keeper Remote Service Data Source
51. GET insert new resources Data Provider + State Keeper Remote Service Data Source
52. Data Provider 1 Responder Callhandle 1 No local data Front layer Local Service 2 State Watcher 3 Remote Service 4 Responder Callhandle 4 5 State Keeper 6 7
53. Data up-to-date Front layer Data Provider 1 Responder Callhandle 1 Local Service 2 State Watcher 3 State Keeper 4
54. Data outdated Front layer Data Provider 1 Responder Callhandle 1 Local Service 2 State Watcher 3 4 8 Up-to- date data Remote Service 5 Responder Callhandle 5 6 State Keeper 7 Stale data
55. Conclusions Do not call backend logic inside UI threads Start long running operations from a background service Persist early and persist often Minimize the network usage
56. References
57. Suggested reading Design patterns: elements of reusable object-oriented software Gamma et al. (978-0201633610) Patterns of enterprise application architecture Fowler et al. (978-0321127426) The pragmatic programmer Hunt, Thomas (978-0201616224)
58. Suggested viewing WWDC sessions Google IO sessions
59. Q + A
60. Contact information iDA MediaFoundry info@ida-mediafoundry.be @iDAMediaFoundry Filip filip.maelbrancke@ida-mediafoundry.be @fmaelbrancke Mike michael.seghers@ida-mediafoundry.be @mikeseghers