Hey, Nick. I have a few questions as I try to more thoroughly understand the cost/benefit from separating GeckoView out. I don't want to come off as challenging – I want to better understand so I feel more compelled to help! :) I pulled out what I thought were the benefits you mentioned:
On Mon, Mar 21, 2016 at 12:29 PM, Nicholas Alexander <[email protected] > wrote: > * reduces our code complexity -- we have more nicely layered architecture, > which makes assigning responsibilities easier and makes information flow > easier to assess; > There is overhead associated with this separation – e.g. spending time determining which class new code should go into, testing both configurations (GeckoApp & BrowserApp). Where is the reduction in code complexity? It is because the build system enforces strict dependencies between the two components? fwiw, I think the overhead I mentioned could be reduced with code architecture changes (e.g. make the main BrowserApp functionality an Object that doesn't extend GeckoApp because inheritance can cause some difficult to manage coupling). > * reduces our compile time -- we can compile and dex independent pieces of > the app in parallel; > Self-explanatory. :D Do you think the reduction will be significant? > * paves the way to write tests against GeckoView -- in essence, replacing > geckoview_example with functional tests; > Yay! * paves the way to publishing GeckoView as a real AAR using Gradle. > I'm not convinced there are many projects that would ship GeckoView over using the built-in WebView – e.g. there's an APK size overhead, you can't take advantage of platform features (though maybe google would keep those features open if there was an active competitor...). Do you disagree? Is it so we could use it internally? - Mike
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
