bug: Allow setup when apply update like in code push

[riderx]

• 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

[riderx]

/bounty 100

[algora-pbc[bot]]

💎 $100 bounty • Capgo

Steps to solve:

1. Start working: Comment /attempt #411 with your implementation plan
2. Submit work: Create a pull request including /claim #411 in the PR body to claim the bounty
3. 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

[raphjutras]

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.

[algora-pbc[bot]]

Here are some steps and pointers to help you get started on resolving this issue:

Steps to Implement the Feature

1. Add a New Setting for Update Kind:

   • Introduce a new setting called updateKind in the configuration file (capacitor.config.json or capacitor.config.ts).
   • This setting should accept values like background, foreground, and appBoot.

2. Modify the Plugin to Check for Already Downloaded Bundles:

   • Update the CapacitorUpdaterPlugin.java to include logic that checks for already downloaded bundles when the app boots.
   • If a bundle is found, apply the update immediately.

3. Update the load Method:

   • Modify the load method in CapacitorUpdaterPlugin.java to check the updateKind setting.
   • If updateKind is set to appBoot, add logic to apply the update if a downloaded bundle is available.

4. 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 updateKind is set to appBoot.

Relevant Files and Code Snippets

• Configuration File:

  • Update capacitor.config.json or capacitor.config.ts to include the new updateKind setting.

    {
    "plugins": {
    "CapacitorUpdater": {
    "updateKind": "appBoot" // or "background" or "foreground"
    }
    }
    }

• CapacitorUpdaterPlugin.java:

  • Modify the load method to check for the updateKind setting.

    
    @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); } }

• 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

1. Security:

   • Ensure that the downloaded bundles are verified (e.g., checksum validation) before applying them to prevent malicious updates.

2. Stability:

   • Thoroughly test the new feature to ensure it does not introduce any instability, especially during app boot.

3. 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.java and CapacitorUpdater.java for downloading and applying updates to avoid code repetition.

• API Documentation:

  • Update the API documentation (api.md) to include the new updateKind setting and its possible values.

[adilkadivala]

wanna work on this issue #411, let assign it me..

[adilkadivala]

/attempt #411

Options

• Cancel my attempt

[raphjutras]

@adilkadivala Have you started working on this?

[adilkadivala]

@raphjutras i have left due to some reason ,, you can start. good luck...

[raphjutras]

@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

[adilkadivala]

I have canceled ,

here it is red...

[WcaleNieWolny]

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

[WcaleNieWolny]

Martin has explained this issue to me. I will be attempting to implement it today

[riderx]

here the reference of codepush: https://github.com/microsoft/cordova-plugin-code-push#installmode

[raphjutras]

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.

[WcaleNieWolny]

Hello, I just created a PR with an IOS implementation. I will work on android right away

[riderx]

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