Hack and Tell - wtf is the core mobile divide
•Download as PPTX, PDF•
0 likes•317 views
All our apps have at least two modules /core/ and /mobile/. Just a little refresher about the aim & values of these two modules. What behaviour belongs in core and how we don't always get it right but we always learn.
Recommended
More Related Content
Similar to Hack and Tell - wtf is the core mobile divide
Similar to Hack and Tell - wtf is the core mobile divide (20)
Recently uploaded
Recently uploaded (20)
Hack and Tell - wtf is the core mobile divide
- 1. WTF is the core/mobile divide
- 2. image
- 3. core is testable & mobile is not ...
- 4. image
- 5. Android is a library
- 6. image
- 7. image
- 8. A brief history of architecture Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. It is the set of structures needed to reason about the software system.
- 9. image CORE MOBILE Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. It is the set of structures needed to reason about the software system.
- 10. image Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. It is the set of structures needed to reason about the software system.
- 11. image Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. It is the set of structures needed to reason about the software system.
- 12. image Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. It is the set of structures needed to reason about the software system.
- 13. Why bother
- 14. image
- 15. image
- 16. image
- 17. image
- 18. image
- 19. core
- 20. image
- 21. image
- 22. image
- 23. image
- 24. image
- 25. mobile
- 26. image
- 27. image
- 28. image
- 29. divide
- 30. image
- 31. drawbacks
- 32. image
- 33. image
- 34. this sh*t is hard
- 35. image
- 36. image
- 37. image
- 38. image
- 39. summation
- 40. Android is a wrapper around our real application Architecture is a way to reason about software & used for guidance Learn from the past; successes & failures core is for client business rules & client domain having business rules all in one place is a big benefit getting mobile module right will come once you get core right mobile is for Android ‘mobile’ considerations & MVC MVP framework thoughts always be conscious when crossing the divide it’s not always easy to get right! TLDR
- 41. image
Editor's Notes
- All our apps have two modules /core/ and /mobile/. Just a little refresher about the aim & values of these two modules. What behaviour belongs in core and how we don't always get it right but we always learn
- W T F. Who likes the divide? Who dislikes the divide? Who thinks they understand the divide? Who has no clue what the divide is about?
- whilst this is ~correct, it is the wrong way to think about it
- Android is implementation detail, android sdk vs android as a language. Talking about the SDK
- Who cares that we program on Android any more, clients don’t care, users don’t care, dom doesn’t care, we don’t care!
- Android is just a wrapper around our REAL application. Android is the gold wrapper and we code teh juicy chocolate inside
- the high level structures of a software system. done
- the discipline of creating such structures. It gives us some rules and continuation, everyone loves patterns in their life.
- and the documentation of these structures. We do document I’m just trolling.
- It is the set of structures needed to reason about the software system. It makes us think - why is this like this, why am I being pushed in this direction, what is the reasoning behind this - which leads to further questions but they turn into questions about the domain and about our REAL application.
- Why even bother with any type of architecture, or trying to split our code into two code bases - it’s so annoying when you can’t reference some code that you need. Many people have trodden this path before, they must be onto something right ...
- A lot of clever people care about this way of working.
- It is the set of structures needed to reason about the software system. It makes us think - why is this like this, why am I being pushed in this direction, what is the reasoning behind this - which leads to further questions but they turn into questions about the domain and about our REAL application.
- Jeffery Palermo's "Onion Architecture"
- we should be following in the footsteps of our predecessors
- we should be learning from what people have done before. Just because Android didn’t exist doesn’t mean knowledge of large systems did not exist. 1905 Also not remembering success codemns you to NOT repeat it!
- module:core
- The core is the core of the application. “the part of something that is central to its existence or character.” That is to say “it is core to the value of the application”. It’s where everything specific to the application about client business rules & client domain should sit.
- Business Rules A business rule is a rule that defines or constrains some aspect of business and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business. Business rules describe the operations, definitions and constraints that apply to an organization. Business rules can apply to people, processes, corporate behavior and computing systems in an organization, and are put in place to help the organization achieve its goals. For example a business rule might state that no credit check is to be performed on return customers.
- Domain Driven Design - eric evans implementing domain driven design - vaughn vernon Domain Driven Design Quickly - InfoQ (Abel Avram)
- Just because it looks like a duck (and quacks like a duck) doesn’t mean it’s a real duck! Just because it’s a java only class does not mean it belongs in the core module.
- Just because it’s intrinsic to the application does not mean it’s implementation sits in core. For example: doing http requests should not sit in core. Perhaps an interface declaring how the core wants to do requests could sit there, but not the code itself. The declaring interface can be called a Port and the implementation (outside of core) the adapter. This is like in nature where a plant has a specific flower shape to allow for it to be pollinated. The flower NEEDS the humming bird but the hummingbirds implementation is outside of the core plant.
- module: mobile For me Mobile is less of a worry and it falls into two camps.
- 1 . It is the great unknown. If you get core right, either we’ll learn what we want to do with mobile or it will just fall into place itself.
- 2 . Android is in charge you should be considerate of the platform you’re on, optimisations etc
- Mobile is where you would discuss, architectures like this.
- nothing lives in the divide, but you still have to considerate. You are constantly crossing whenever you’re writing code, although it doesn’t physically exist you have to be aware of where you are.
- drawbacks of division .. or are they
- You can’t just do whatever you want, you have to constantly be thinking where should this code sit. This is a good thing!
- You notice that something is different. You want to use an Android helper class, but you’re in core at the moment! This is annoying, but also it’s a code smell that something is wrong. Something is living at the wrong level of abstraction. Perhaps this class has too many responsibilities. Perhaps a business rule is missing. Perhaps there is a java way to do the same thing! (your leaning on Android unnecessarily)
- yes, yes it is. It’s about learning and evolving
- Talking about it, discussions can give new insights
- trying new things to get over problems to embrace change
- learning from mistakes. We must have been through 10 apps with this idea, and each time the idea evolves or we find out something that doesn’t quite work or does work!
- we learn together, from our failures & our successes