This may have minor performance improvements.
I don't see any value in hoisting all dependency versions so I removed
it for this dep. I also see an additional downside (additional indirection to
find values in addition to the indirection of storing all the dependencies in
a single file).
* For #9644: remove unnecessary leanplum maven repository.
The docs say it is [1] "only needed for Android SDK versions below 4.3.0".
That is API 18 and our min SDK is 21.
[1]: https://docs.leanplum.com/reference#android-setup
* For #9644: move buildscript block from :app to root project.
This will reduce the amount of duplication we need in specifying
restricted dependencies and centralize repository definitions. Since
we're a one project app, it shouldn't have a significant impact on
performance.
* For #9644: restrict dependencies following FFTV config.
However, there is a resolution error to be fixed in the next commit.
This is verbatim from FFTV except I removed the no-op "improve security
if code is refactored incorrectly" lines: these lines rarely changed and
I'm not that concerned. It might be better to simplify the
configuration.
Source:
62a2fa680c/buildSrc/src/main/java/org/mozilla/gradle/Dependencies.kt (L7)62a2fa680c/build.gradle (L31)
* For #9644: restrict firebase deps to google repo.
This fixes the resolution error from the previous PR.
I removed the version constant indirection for these items because I found it
challenging:
- it makes it harder to quickly identify which versions are in use
because it requires jumping to a new screen for each dependency
- it increases the length of the file, obscuring what's available
* For #8412: Passes error handling function to 'CustomTabWindowFeature'
Change required for showing error message when the app can't handle a specific
scheme. Implemented in AC:
https://github.com/mozilla-mobile/android-components/pull/6122
* Upgrade AC version
Co-authored-by: Sawyer Blatz <sdblatz@gmail.com>
Make sure that we actually lazily initialize our storage layers.
With this patch applied, storage layers (history, logins, bookmarks) will be initialized when first
accessed. We will no longer block GeckoEngine init, for example, on waiting for the logins storage
to initialize (which needs to access the costly securePrefStorage).
Similarly, BackgroundServices init will no longer require initialized instances of the storage
components - references to their "lazy wrappers" will suffice.
In practice, this change changes when our storage layers are initialized in the following ways.
Currently, we will initialize everything on startup. This includes loading our megazord, as well.
With this change, init path depends on if the user is signed-into FxA or not.
If user is not an FxA user:
- on startup, none of the storage layers are initialized
- history storage will be initialized once, whenever:
- first non-customTab page is loaded (access to the HistoryDelegate)
- first interaction with the awesomebar
- history UI is accessed
- bookmarks storage will be initialized once, whenever:
- something is bookmarked, or we need to figure out if something's bookmarked
- bookmarks UI is accessed
- logins storage will be initialized once, whenever:
- first page is loaded with a login/password fields that can be autofilled
- (or some other interaction by GV with the autofill/loginStorage delegates)
- logins UI is accessed
- all of these storages will be initialized if the user logs into FxA and starts syncing data
- except, if a storage is not chosen to be synced, it will not be initialized
If user is an FxA user:
- on startup, none of the storage layers are initialized
- sometime shortly after startup is complete, when a sync worker runs in the background, all storage
layers that are enabled to sync will be initialized.
This change also means that we delay loading the megazord until first access (as described above).
Arturo Mejia