On Mon, Mar 21, 2016 at 2:00 PM, Michael Comella < michael.l.come...@gmail.com> wrote:
> 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 < > nalexan...@mozilla.com> 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? > This is a valid point in general, but the specific example is perhaps not the best example of it. If I understand correctly, GeckoApp and BrowserApp was the split devised to handle WebApps. With WebApps gone ( https://bugzilla.mozilla.org/show_bug.cgi?id=1235869) and b2gdroid on the way out (https://bugzilla.mozilla.org/show_bug.cgi?id=1256401), there will be no consumers of GeckoApp, and we will again have a single functional Fennec activity. We could roll the two back together, if we choose to. So the two configurations you speak of will not likely be an issue (at least for testing). The reduction in code complexity I envision will come from making Fennec *and anything else that follows* rely on a new, independent GeckoView library. When Fennec wants a feature from Gecko (say, to send and receive WebPush Notifications), we will have a natural forced evaluation process: is this a GeckoView thing -- does it make sense to expose it to non-Fennec consumers? If yes, how do we expose it to general GV consumers? How do we expose it to Fennec? Right now, we can largely punt on those choices, since it's all the same ball of mud; but every decision is tangled. To summarize: the architecture win is GeckoView -> {Fennec Activity, other Activity (ReaderMode?), other Activity (SearchActivity?)}. What we had before was GeckoView -> Shared Activity -> {Fennec Activity, WebApps Activity}, which was very hard to navigate. > 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). > I mostly agree. There's a lot that can be done to simplify the existing activity code organization that does not include splitting the monolith. Splitting the monolith, however, is the best way to be able to test things about our web rendering engine independently of Fennec-the-App. That's a huge simplicity benefit. > * 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? > I have high hopes. In theory, we should run two processes that each take roughly 40-60% of the original time. It's virtually impossible to test this in advance, however. In automation, Proguard will remain the long pole, since it's a global analysis. > * 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? > Independent of any external consumers, I think this ship has sailed on this approach. I will just point to https://github.com/crosswalk-project, which does exactly what GeckoView would do -- but with a Chrome WebView! There's a demand for controlling the web rendering engine you ship :) So pleased to see this get traction! Nick
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
