Current storage format doesn't preserve session order, and snapshot processing
is a bit vague around the various edge cases.
This patch changes the storage format to use an ordered list (vs a set), and firms
up creation, processing and restoration of snapshots. Guiding principles are:
- be explicit,
- be lenient about what we accept, and strict about what we produce.
Storage format version isn't bumped out of simplicity: there are no production
consumers of this (that we know of) that we'll need to migrate, and so let's
do the simple thing this time.
This patch introduces an idea of a SessionsSnapshot, which is a representation of
SessionManager's state that's suitable for persistance. SessionStorage's APIs read/write
APIs are changed to operate over the snapshot.
A public `restore` method was added to SessionManager, along with onSessionsRestored observer method,
which allow restoring a SessionsSnapshot.
When creating new session from an existing session, we need to the
relationship between two sessions. For example, to click a href link in
web-page to open new tab.
This commit add parent id to Session. If a session is added without
parent, it will be append to tail of sessions. Otherwise it will sit
next to parent.
Problem this is trying to solve:
SessionManager doesn't own its "empty" state (no selected session, no sessions at all).
Components which rely on the SessionManager may make assumptions about what happens
when SessionManager becomes "empty", and current approach is for some component to "take charge",
and be responsible for adding a "default" session when there are none left.
This doesn't bode well for composing components. We can get into a kind of "action at a distance"
situation, when various components make certain assumptions (say, SessionManager must always have
a selected session), but none of them actually take charge and populate the manager when appropriate.
Since components aren't necessarily aware of each other, and ideally are arbitrarily composable,
this graph of implicit dependencies becomes problematic.
This patch:
A naive solution to this is to get the SessionManager to owner its "empty" state.
This patch allows "default" behaviour to be specified at creation time, supplying a lambda
which produces a default session. Not supplying this lambda is equivalent to allowing SessionManager
to be empty.
Fixes https://github.com/mozilla-mobile/android-components/issues/764.
* Adding captureThumbnail to EngineSession
* Updating TabViewHolder to add thumbnail
* Adding thumbnail to Session
* Adding a new product flavor for systemEngine
This only includes the implementation for the SystemWebView that's based
off of what we currently do in Focus/Fire TV. Since this is needed for
those apps now, we can work with this implementation until GeckoView
provides us with a nicer API to do the equivalent for it. (Bug 1489669)
We also don't notify any observers since there isn't any
confirmation/information available that we can propagate to cients.
* Adding desktopMode property to Session
* Adding onDesktopModeChanged in Session
* Renaming RequestDesktopSite to RequestDesktopSiteUseCase to follow
the convention
* Implementing onDesktopModeChange in EngineObserver
Renaming:
On EngineSession.Observer
from onDesktopModeEnabled to onDesktopModeChange
from setDesktopMode to toggleDesktopMode
On Session
from onDesktopModeEnabledChanged to onDesktopModeChanged
Adds the ability to stop loading a session that would have already
started.
Some considerations were made about whether
`EngineSession.Observer#onLoaingStateChanged` should be called. In our
current `SystemEngine` and `GeckoEngine` there isn't any explicit
callback for handling a stop loading event so there wouldn't be any way
to do this.
Without that observers listening to onSessionRemoved() would be notified while the session manager
is in an inconsistent state (session removed but selection index not updated).
