-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat: Prevent local PouchDB modification to be replicated to remote DB #1243
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 tasks
zatteo
approved these changes
Sep 16, 2024
In previous commits we configured the application's cozy-client to use CozyPouchLink This link is configured for all react-native side queries, but not for cozy-app queries as they are served inside of WebViews and use a different cozy-client instance We want cozy-apps to benefits from the CozyPouchLink by redirecting their queries to the react-native side using the new FlagshipLink interface With this interface, all cozy-apps queries can be redirected to the react-native side using cozy-intent/post-me In order to intercept them, then we should declare `FlagshipLinkRequest()` method `localMethods` Related PR: cozy/cozy-client#1505
When a cozy-app's WebView is served offline, then the cozy-app bundle is served from local folder using the CozyProxyWebview, and since previous commits, the cozy-client's queries are served through `FlagshipLink` With those mechanisms, nearly all data are available offline except two things: - cozy-stack static assets (i.e. some css files, avatar, partners logos etc) - `fetchJSON()` requests This commit tries to handle the static assets part Those assets are often served with HTTP cache activated, and so the WebView should be able to load them correctly when the device is offline. However on Android, the WebView's cache seems not to persist after the application is closed Activating the `cacheMode=LOAD_CACHE_ELSE_NETWORK` seems to fix this behavior. But it prioritizes too much the cache over fresh data, so we want to activate it only when strictly necessary, which is when the application is offline This also allows to load partners logos that are not cached by the cozy-stack (as of today). But we expect to modify the cozy-stack to enable cache on them
With previous changes, we now expect the CozyPouchLink to be the last link of the chain, so forwarding the query would result to an exception thrown This mean we cannot forward the query when warmup queries are not finished yet So we want to allow CozyPouchLink to ignore the verification step and process the query independently of the warmup queries status To allow this we introduce the `ignoreWarmup` parameter. When set to `true` the CozyPouchLink will process the query even if warmup is not finished yet Related PR: cozy/cozy-client#1506
Some cozy-apps declare a data `schema` into cozy-client instance This schema is then used for processing queries As we now process cozy-app queries on the react-native side through FlagshipLinkRequest, we want to declared this schema in the Flagship app's cozy-client For now we only need to implement the one from cozy-home The ideal implementation would be to extract it from the cozy-app's bundle, but we did not implement anything to support this (we should first investigate how to do this). So for now it is hardcoded
By adding offline support through PouchDB, we expect database related bugs to happens in the future In order to ease debugging them, we want to allow exploring the local PouchDB files The easier way is to add the ability to extract them from the device and send them through email to cozy's support team
When the application is offline, we want the user to be able to access their files that are accessible offline To make this possible, we want the Flagship app to provide a new `downloadFileAndPreview()` interface that can be called from cozy-apps Internally this method should allow to download and preview files, but also to store them in the device's storage in order to make them accessible later even when the app is offline This method will be called from cozy-client through `file` model For now we make files accessible only if they have already downloaded once In the following commit we will make important files accessible in a proactive way
We want the user's important files to always be accessible offline To make this possible, we want the app to download them in background on startup We consider important files as files from `mespapiers` with specific qualification labels like passport, identification papers, vehicle registration, etc.
As we store offline accessible files in the device's storage, we want to prevent them to fill the entire device's storage We chose to keep only files that were accessed in the previous month. All other files would be deleted Important files are never deleted as long as they exist on the Cozy instance
`NetStatusBoundary` is used to display an `offline` error screen when the app is offline Now that we implemented offline mode, we now want to disable the `NetStatusBoundary` for cozy-apps as they should now be accessible when offline `NetStatusBoundary` is kept only on onboarding screens
In a previous commit we changed the return type for `getIndexHtmlForSlug()` We did not change the return objects for every execution paths This commit fixes that
For now offline mode has only been implemented in cozy-home and mespapiers apps This commit prevents other cozy-apps to be opened offline Later we will declare offline support in cozy-apps' manifests, so this hard coded condition is meant to be replaced in the future
Cozy-apps can be opened offline only when they support this mode but also when they have been opened at least one time to retrieve necessary data to make them run offline When those conditions are not met, we want to display an error message to explain the user why the app cannot be opened For now this message is in an Alert form, but later we may want to improve the UI for this part
In iOS, we disabled HttpServer for all cozy-apps as the WebView API may behave differently The side effect is that we cannot open those app when offline as we cannot inject minimal code to make them work without network access So we want to enable HttpServer on those apps when we detect the app to be offline Related PR: #486
For now we don't want to replicate local changes into remote PouchDB as we first want to ensure everything works as expected locally before activating two-way replication in the future
Ldoppea
force-pushed
the
feat/offline_error_screen
branch
from
September 24, 2024 10:43
aa2529c
to
7331f45
Compare
Ldoppea
force-pushed
the
feat/make_offline_readonly
branch
from
September 24, 2024 10:43
608539f
to
53df8f4
Compare
Ldoppea
force-pushed
the
feat/offline_error_screen
branch
from
September 24, 2024 11:09
7331f45
to
8f13a31
Compare
The commit has been cherry picked in #1209 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For now we don't want to replicate local changes into remote PouchDB as we first want to ensure everything works as expected locally before activating two-way replication in the future