Feedback: Great work with this!

[Jhonte]

Tried out this instead of the code-push lib that I could not get to restart after applying an update. Worked at once for both platforms!

Looking forward to future updates.

One thing to put on your radar, don't know how feasible it is - but since there is no manifest file logic going on here I just skipped the assets part to keep my .zip size down for smoother updates. But that came with the downside that the assets was not available over doing an OTA. Is there some way that it can just build up if there are new ones? Essentially a flow something like

• Copy original assets + bundle available from the first native release to somewhere you have control over
• When you get an OTA - just replace or expand the assets in the same folder (so it will grow if needed)
  This way you have a native release - and then just NEW assets (if any) with OTA updates. If that makes sense :)

Thanks again!

[vantuan88291]

Thank for your feedback, about the update flow of your ideal, its very good way to reduce the bundle size when we release OTA, I will think about it, but it not easy to manage the assets, I think need a mapping file for assets and control from native size and even control when export the bundle, btw still need to detect what we need to export from CLI, then control it from native size, seem a bit related to backend size as well to know how is the previous assets version to decide how we export the data of bundle assets 👯

[Jhonte]

Yes agreed that this job is usually made at the backend side - to make sure only new assets are in the .zip, but would be nice to have a way to rule out the backend completely and only have static .zip's if possible.

Yeah guess the logic is something like (client code)

• At first startup copy (or move) all assets and current bundle used to somewhere you have control over
• When a new OTA i applied, just overwrite that path with everything included in the OTA zip
• (Extra) Make a rollback option for the js-part, so you have a change to just reset the js-file

Downside is that this will grow and grow, but if you as a developer knows about the flow you can just release native-updates from time to time to get rid of now not used assets anymore.

[vantuan88291]

let me think about it later on, but now I am thinking about git version control on this library, we can pull the change of commit instead of download whole bundle file with assets, maybe just around 2-50 KB if less changing, it will save more time when do OTA, I am trying to integrate git engine into this library, and we can use git repository like GitHub / bitbucket... to store the bundle, no need backend anymore

[lavisar]

let me think about it later on, but now I am thinking about git version control on this library, we can pull the change of commit instead of download whole bundle file with assets, maybe just around 2-50 KB if less changing, it will save more time when do OTA, I am trying to integrate git engine into this library, and we can use git repository like GitHub / bitbucket... to store the bundle, no need backend anymore

Sounds great! Looking forward to this in the future!

[murtazakaz]

@vantuan88291 I just wanted to give a big round of applause for this! I was working on it and had already completed the iOS part when I stumbled upon your repo. You’re a lifesaver!