bug: Allow setup when apply update like in code push
- on background
- on foreground
- on app boot (after a kill)
It should be available in a setting like updateKind. The goal here is to change the moment where update is applied, not when downloaded
/bounty 100
๐ $100 bounty โข Capgo
Steps to solve:
- Start working: Comment
/attempt #411with your implementation plan - Submit work: Create a pull request including
/claim #411in the PR body to claim the bounty - Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts
Additional notes:
โน๏ธ If something is not clear ask before working on it, otherwise your chance to rework it is high ๐ฅ To claim you need to provide in your PR a demo video of the change ๐จโ๐ฉโ๐งโ๐ฆ Join the Discord to get help ๐ Check all Bounty rules
Thank you for contributing to Cap-go/capacitor-updater!
Add a bounty โข Share on socials
| Attempt | Started (GMT+0) | Solution |
|---|---|---|
| ๐ด @adilkadivala | Aug 2, 2024, 2:54:02 PM | WIP |
I would like to provide further clarification on the issue we just discussed with @riderx . We would like the app to install the update when the app boots, but only when there is an already downloaded bundle waiting.
The current behavior of CapGo for direct update is: Capgo fetches (downloads) the bundle from the server and installs the update in one step. This adds a delay since the round trip time to the servers add up. (avg. time 5s for most cases).
The proposed behavior is: allow Capgo to determine if there is an already downloaded bundle (on device, ready to be installed) and use that bundle to install the update next time the app is killed/restarted instead of always applying it on background/foreground action. This solutions eliminates the round-trip to the server. (avg. time to install reduced to 1-2s)
The update would be applied on app boot, and much faster.
Here are some steps and pointers to help you get started on resolving this issue:
Steps to Implement the Feature
-
Add a New Setting for Update Kind:
- Introduce a new setting called
updateKindin the configuration file (capacitor.config.jsonorcapacitor.config.ts). - This setting should accept values like
background,foreground, andappBoot.
- Introduce a new setting called
-
Modify the Plugin to Check for Already Downloaded Bundles:
- Update the
CapacitorUpdaterPlugin.javato include logic that checks for already downloaded bundles when the app boots. - If a bundle is found, apply the update immediately.
- Update the
-
Update the
loadMethod:- Modify the
loadmethod inCapacitorUpdaterPlugin.javato check theupdateKindsetting. - If
updateKindis set toappBoot, add logic to apply the update if a downloaded bundle is available.
- Modify the
-
Implement the Logic to Apply Updates on App Boot:
- In
CapacitorUpdater.java, add methods to check for downloaded bundles and apply them on app boot. - Ensure that this logic is triggered only if
updateKindis set toappBoot.
- In
Relevant Files and Code Snippets
-
Configuration File:
- Update
capacitor.config.jsonorcapacitor.config.tsto include the newupdateKindsetting.
{ "plugins": { "CapacitorUpdater": { "updateKind": "appBoot" // or "background" or "foreground" } } } - Update
-
CapacitorUpdaterPlugin.java:
- Modify the
loadmethod to check for theupdateKindsetting.
@Override public void load() { super.load(); // Existing code... String updateKind = this.getConfig().getString("updateKind", "background"); if ("appBoot".equals(updateKind)) { checkAndUpdateOnBoot(); } } private void checkAndUpdateOnBoot() { // Logic to check for downloaded bundles and apply the update BundleInfo downloadedBundle = this.implementation.getDownloadedBundle(); if (downloadedBundle != null) { this.implementation.applyUpdate(downloadedBundle); } } - Modify the
-
CapacitorUpdater.java:
- Add methods to get downloaded bundles and apply updates.
public BundleInfo getDownloadedBundle() { // Logic to check for already downloaded bundles // Return the bundle info if found, otherwise return null } public void applyUpdate(BundleInfo bundle) { // Logic to apply the update using the provided bundle info }
Potential Implications
-
Security:
- Ensure that the downloaded bundles are verified (e.g., checksum validation) before applying them to prevent malicious updates.
-
Stability:
- Thoroughly test the new feature to ensure it does not introduce any instability, especially during app boot.
-
Potential Bugs:
- Ensure that the logic to check and apply updates does not interfere with other update mechanisms (e.g., background or foreground updates).
References
-
Existing Methods:
- Refer to existing methods in
CapacitorUpdaterPlugin.javaandCapacitorUpdater.javafor downloading and applying updates to avoid code repetition.
- Refer to existing methods in
-
API Documentation:
- Update the API documentation (
api.md) to include the newupdateKindsetting and its possible values.
- Update the API documentation (
wanna work on this issue #411, let assign it me..
@adilkadivala Have you started working on this?
@raphjutras i have left due to some reason ,, you can start. good luck...
@raphjutras i have left due to some reason ,, you can start. good luck...
Then can you cancel your attempt so that others can take the bounty? Thank-you
I have canceled ,
here it is red...
The proposed behavior is: allow Capgo to determine if there is an already downloaded bundle (on device, ready to be installed) and use that bundle to install the update next time the app is killed/restarted instead of always applying it on background/foreground action. This solutions eliminates the round-trip to the server. (avg. time to install reduced to 1-2s)
I think android does that already (?). I am not sure, but I think so from what I have observed
Martin has explained this issue to me. I will be attempting to implement it today
here the reference of codepush: https://github.com/microsoft/cordova-plugin-code-push#installmode
Thank you to both of you @riderx and @WcaleNieWolny I will keep following this issue closely ๐ We will test the feature as soon as it is available.
Hello, I just created a PR with an IOS implementation. I will work on android right away
So after much research, it seems multi-play is doing what is requested, but was broken on Android.
It's now fixed on v6.0.65.
In V7 we will make multidelay more consistent and Apply update depending on installMode