-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[Site design revamp] Preload MShots when the site creation activity starts #16584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Site design revamp] Preload MShots when the site creation activity starts #16584
Conversation
In order to make testing more convenient, this adds a temporary flag that can be toggled in the debug settings of the app. It also adds a hard-coded behavior to clear the Glide cache (memory and disk), for the purpose of testing the flow with a fresh start each time.
For some reason, deleting the Glide cache was not enough, and disabling the volley cache was still not enough to prevent a cache hit. I suspect that there is an additional cache later on the network side of things. Nevertheless, we may want to keep the volley cache disabled, to prevent 3 layers of duplicate cache.
The nested recycler views can only utilized a shared pool if they are given the same instance of the pool. We can either remove the line, or keep a reference to the instance at a higher level in the hierarchy, so that the children recycler views can share a pool of view holders.
…vamp--preload-mshots
|
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
|
You can test the changes on this Pull Request by downloading the APKs: |
Some thoughts about other approachesIt occurs to me that with this approach, we are submitting the request for site designs (themes) and their categories twice: once at the start of the activity, in order to obtain the list of thumbnail URLs to prefetch, and once when the fragment loads. There is an opportunity for optimization here: we can save the result from the first call and avoid the second call if the first call is received in time (i.e. before the theme picker fragment is loaded). Preload the whole fragment?Another possibility to explore is to load the entire theme picker fragment invisibly at the start of the activity. Since we don't have the intent information at that time, the fragment would not in an identical ui state when it is finally displayed, but it might be possible, nevertheless, to populate both the Glide original source cache as well as many of the relevant resized caches (except the recommended row, since we can't know that ahead of time as it depends on the intent). Such an approach may have implications for the lifecycle of the underlying fragment (and view model). One of the advantages of this approach is that we could be prepopulating both the original source image and the resized images generated by We could delay preloading until the intent is selected, but this leaves little time for preloading to be beneficial, since the picker is the very next screen shown. Later, with the site name screen re-enabled, this may put more weight towards such an approach. |
|
Great work @mkevins 👍
Maybe we can implement a caching mechanism on the network level similar to the one we have for the page layouts. I remember that we skipped this part in the original implementation because the users usually run this flow one. With the prefetching call though it makes sense to cache things. |
…vamp--preload-mshots
WordPress/src/main/java/org/wordpress/android/ui/layoutpicker/LayoutsRowViewHolder.kt
Outdated
Show resolved
Hide resolved
WordPress/src/main/java/org/wordpress/android/networking/GlideMShotsLoader.kt
Outdated
Show resolved
Hide resolved
WordPress/src/main/java/org/wordpress/android/ui/sitecreation/SiteCreationActivity.kt
Outdated
Show resolved
Hide resolved
|
Thanks for taking a look at this Antonis!
Good idea! I think this can be done in a followup PR. Wdyt? |
I agree since it would require a non-trivial amount of code and testing 👍 |
…vamp--preload-mshots # Conflicts: # WordPress/build.gradle
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @mkevins 👍
I've tested the build on an emulator (api level 32) and everything worked as described. The code changes look concise to me 🎉
Added a few suggestions and responses to your comments but nothing blocking for this PR 🙏
ps. I took the liberty to push minor changes to pash the CI test (lint, tests) 🙇
WordPress/src/main/java/org/wordpress/android/ui/sitecreation/SiteCreationMainVM.kt
Outdated
Show resolved
Hide resolved
…om:wordpress-mobile/WordPress-Android into feature/site-design-revamp--preload-mshots
| private val fetchHomePageLayoutsUseCase: FetchHomePageLayoutsUseCase | ||
| ) : ViewModel() { | ||
| init { | ||
| // TODO: Remove the duplicate {,un}registration in the picker view model |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the cancellation (interruption) flow, we need to have this in both places. The only thing left to remove is this comment, which I forgot to remove before merging 🤦♂️ .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Ovi!
🤦♂️ why did I not see this 😅 Thanks for fixing it @ovitrif 👍 🙇♂️ |
Fixes #16571
Description
This PR implements a preloading function in the main site creation view model, and invokes it when the site creation activity starts. It cancels the preloading before displaying the theme picker fragment so that the remaining images can load normally.
Preloading is done in the background via
Glide, without layout specified (so only the original source image would be cached). This seemed a decent middle ground, imo, since it seeks to mitigate potential network performance issues (image resizing is done locally). If it is desirable to also prepopulate the resized results, an alternative to explore would be loading the entire fragment, but I have not attempted this.To test:
Feature flag for convenience
Testing the behavior of this flow with and without the preloading can be tedious, since it requires clearing the cache every time. Also, there are multiple levels of cache, and it is difficult to get a fresh start without reinstalling the app for each test run. For convenience, I have added a temporary feature flag to toggle the preloading on and off. Also, each time the preloading (actually any feature flag is toggled 😄 ), the
Glidecache is cleared (both memory and disk). It is also necessary to clear the app cache manually from the app info screen.Precondition:
Start the app with the app inspection tab open, and the network inspector selected in Android Studio. It will be useful to monitor the traffic during the site creation flow.
Network inspector
It can also be useful to perform these steps in an emulator, with a low data rate, e.g. GPRS & Poor.
Changing the network type and strength
Clearing the app cache
clear-app-cache.mp4
Preloading off
Preloading on
Preloading interrupted
Regression Notes
Potential unintended areas of impact
Site creation flow
What I did to test those areas of impact (or what existing automated tests I relied on)
Manual testing
What automated tests I added (or what prevented me from doing so)
We don't currently have the needed integration test harness established to test this.
PR submission checklist:
RELEASE-NOTES.txtif necessary.