I want to throw in another video from last year's Android Dev Summit in Mountain View:
Android Application Architecture https://www.youtube.com/watch?v=BlkJzgjzL0c I've been looking at MVVM too but I haven't fully used it in an Android app to have an opinion. Regarding libraries that introduce new patterns: I'm reserved - They make life simpler at times but they come with a cost: You need to learn how to use them. New volunteers might not be able to contribute without learning the frameworks (in comparison to "vanilla android"). Dagger, for example, is a great library for dependency injection. But I have seen Junior developers struggling with understanding where the dependencies come from, where they are retained and at what point they are created by what code. And the frameworks change - the Android world doesn't follow hip frameworks as fast as the JavaScript community though. :) However migrating an existing app from Roboguice (Back then "the" dependency injection library, Today: "Why does my app take 10 seconds to start?") to Dagger 1 was one of the most painful code migrations I did. The other thing is having all this code already: Having a mix of libraries/patterns can be cumbersome. We may already have this and at our size it's something that we will have to live with. I'd make different decisions about using a library if I'd start with a new app as opposed to developing an already existing app. I just realize that this sounds all negative: I'm definitely for exploring new patterns and libraries - Let's find the best ones where we are confident that we won't drop them for something better in 2017 (Actual helpfulness over syntactic sugar). On Tue, Apr 12, 2016 at 8:17 PM, Steph Leroux <sler...@mozilla.com> wrote: > >> - Isolate state. >> - Pursue immutability and idempotency. >> - Separate state changes from presentation changes. >> - Don't be afraid of transforming state into the minimal >> representation necessary for display. >> >> > Just wanted to briefly chime in and mention a great architecture video > from a previous WWDC: > > *Advanced iOS Application Architecture and Patterns: > https://developer.apple.com/videos/play/wwdc2014/229/ > <https://developer.apple.com/videos/play/wwdc2014/229/>* > > It's kind of iOS specific but expands on a lot of the points Richard > mentioned in his bullet point list as well as framing a lot of those > objectives around 'sources of truth' in your application. > > On Tue, Apr 12, 2016 at 1:49 PM, Richard Newman <rnew...@mozilla.com> > wrote: > >> Emily has recently been exploring state-driven frontend design on iOS for >> her menu work; I'd like to see her chime in here with her experiences. >> >> My 2¢: >> >> >>> I've noticed that these patterns are not something that we've been >>> explicitly doing on this team but could potentially benefit from – does >>> anyone have experience with them? It would be great to hear some of the >>> trade-offs and I'd be curious to see which parts of the code could benefit >>> from a more formalized architecture. Experience with these architectures on >>> other platforms (e.g. MVC in web dev) would also be useful to hear! :) >>> >> >> To raise the level of abstraction here for a moment: architectural >> changes over time have been about recognizing incorrect couplings and >> resolving them. >> >> For example, one of the shifts between old-school MVC and more modern >> approaches like React/Redux and MVVM is the recognition that one Model >> doesn't fit all. MVVM transforms a model into a view model; React chops an >> app state into simpler component properties as it filters down the tree. >> >> We see/saw this incorrect coupling throughout our apps: the broken >> Site/Table concept on iOS, for example. Anywhere you see lots of >> optional/nullable fields and a symmetric API, you have a poorly fitted >> model. (This is one of my criticisms of simple ORMs >> <https://160.twinql.com/trivial-sql-orms-considered-harmful/>.) >> >> Eventually this shift leads to concepts like CQRS and event sourcing, >> where we acknowledge that the actions your user takes, the persistent >> storage, and the data your frontend needs are all quite different, and can >> be related by a transform pipeline. >> >> Jeremy Miller noted re CQRS >> <https://jeremydmiller.com/2014/10/22/building-an-eventstore-with-user-defined-projections-on-top-of-postgresql-and-node-js/> >> : >> >> “In a way, CQRS just explicitly calls out a large part of software >> development efforts that is often overlooked. If we simply accept the idea >> that different consumers and producers of the persisted state in our system >> naturally have different needs as far as how the same information is >> written, structured, and consumed, CQRS isn’t really “crazy talk” or extra >> work.” >> >> >> Another example: iOS developers noticed that controllers — in part >> because of the delegate/datasource pattern — end up huge >> <https://twitter.com/Colin_Campbell/status/293167951132098560>. You have >> a tiny model (an array of records), a generic table view, and a gigantic >> controller that looks up records, issues new queries, builds cells, handles >> clicks, shuttles things between threads, and so on. >> >> Massive view controllers (e.g., BrowserViewController on iOS, BrowserApp >> or GeckoPreferences on Android) are hard to test and hard to understand, >> and they often start to take on a hybrid role as a kind of persistent model >> themselves, which makes things even worse. >> >> One of the central benefits of tools like Redux and approaches like MVVM >> is the isolation of state and changes to it: eventually the concept of a >> controller/presenter is whittled down, because actions are handled >> externally (reduced into a new state), and components simply present >> themselves based on each new state. You can test your actions and your >> components separately! >> >> I would be hesitant to recommend trying to retrofit MVC/MVP (or even >> MVVP, or…) into Fennec. Instead I'd suggest following the *principles* that >> each of these architectural evolutions is inching towards: >> >> - Isolate state. >> - Pursue immutability and idempotency. >> - Separate state changes from presentation changes. >> - Don't be afraid of transforming state into the minimal >> representation necessary for display. >> >> The right architecture for the situation will drop out from the >> application of the right principles. >> >> -R >> >> _______________________________________________ >> mobile-firefox-dev mailing list >> mobile-firefox-dev@mozilla.org >> https://mail.mozilla.org/listinfo/mobile-firefox-dev >> >> > > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
