Hi all, The next phase in GeckoView development will involve the Display/Session split (bug 1415252; see below for a description of this work). The first step of that process landed in bug 1413698, which introduced GeckoSession.
GeckoSession contains most of what used to be in GeckoView, so the most significant change for developers is switching from using GeckoView APIs to using the same APIs in GeckoSession. See [1] for how that was done for geckoview_example. Other related changes include renaming GeckoViewSettings to GeckoSessionSettings, and moving GeckoView listener/delegate interfaces to under GeckoSession. Going forward, the GeckoDisplay interface will be added, and core functionality will be implemented in GeckoSession. The GeckoView class itself will essentially become a convenience class for using GeckoSession with a GeckoDisplay in the form of SurfaceView/TextureView. There are still many details to be worked out, such as how to handle input and how to support the dynamic toolbar feature. Please comment if you have any questions or thoughts. Cheers, Jim [1] https://hg.mozilla.org/mozilla-central/diff/1bb6b4ff9df2/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#l1.49 Display / Session Split Although GeckoView promises similar features and abilities to other web components, such as the built-in Android WebView, we have an opportunity to give Gecko some additional flexibility which will make it suitable for solving a larger set of problems. You can think of a web component as having two main parts. The Display, or frontend, is what’s responsible for getting the web content on the screen and interacting with the user. The Session, or backend, communicates with the Display and takes care of the heavy lifting. This is where the web engine lives, including the JS runtime, DOM, layout, networking, etc. Often these two pieces are conflated for ease of use or implementation simplicity, but for GeckoView we would like to make them explicitly separate. Gecko needs an Android Surface in order to start the compositor and composite web content. There are several ways to get a Surface on Android, all with their own advantages and designed use cases. If we decouple the Display from the Session, we can allow any of these methods to be used, enabling Gecko content shown in a variety of different ways. Examples: * SurfaceView for high-performance, untransformed output on the screen. * TextureView for transformed output, useful for creating transitions and animations. * SurfaceTexture to show Gecko output in an OpenGL scene, like a game or a VR/AR environment. * MediaCodec to stream Gecko’s output to a video encoder. * No Surface at all (or a dummy one) for a headless mode. A Display would use any of the above methods to create an Android Surface and give it to the Session. This is a tremendous advantage over traditional monolithic approaches (like Android WebView), and will let Gecko participate in new and innovative uses of the web on Android. You can basically think of a Session as a Java interface to the <browser> XUL element or a nsDocShell. It therefore exposes a similar API. The Session will be the entry point for loading a new URL, navigating within the history, reloading a page, etc. It will also allow the app to set delegate instances which allow Gecko to notify the app of things like page load progress or to show UI like alert() prompts. Initially we will have a 1:1 relationship between a Session and a Display, but there shouldn’t be too many hurdles if we want to have multiple displays per Session. This would allow you to, for instance, view a page on the phone screen and simultaneously encode the output to a video stream. Display instances are expected to be very lightweight, with their only responsibility being to create a Surface in some way and hand it to the associated Session instance. They can optionally handle user input, handing that off to the Session as well. An important point is that even though each Session may have only one attached Display, it is possible for that Display to change at any point. This means you can have the same Session displayed in several different Activities using any of the above means during the lifetime of the Session. For example, you could have a 2D browser that transforms into a 3D one when the user puts on their VR or AR headset. Session lifetimes would be controlled by the app itself and not that of any Display or Android Activity. They would, however, be restricted by the lifecycle of the containing process. _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
