Skip to content
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: add basic eager initialization #124

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

buschtoens
Copy link

@buschtoens buschtoens commented Nov 2, 2020

Fixes #121.

Android implementation by @ahsanz024. iOS implementation by @SwenHutop. We use this at @ClarkSource for our new Capacitor app.

The code is structured rather weirdly, because we tried to apply the changes as a patch on top of the existing cordova_sdk changing only as little upstream code as necessary, to make merging updates back in easier.

How does it work?

Explaining for Android, because I understand that implementation best, but it's basically the same for iOS.

  • First we perform synthetic calls for all COMMAND_SET_*_CALLBACK handlers and register BufferedCallbackContexts for all of them.
  • Then we call COMMAND_CREATE and pass along our desired confifuration.
  • Once the web app boots and starts interacting with the Adjust plugin, it does not call Adjust.create(config), as we already did that from the native side.
  • If any of the registered handlers, e.g. onAttributionChanged, gets triggered, it will find a BufferedCallbackContext and call sendPluginResult(pluginResult) on it, as if it was a regular PluginResult.
  • The BufferedCallbackContext stores all calls to sendPluginResult(pluginResult).
  • Then once the web app calls e.g. Adjust.setAttributionCallback(cb), the BufferedCallbackContext will replay all calls to sendPluginResult(pluginResult) on the new "real" PluginResult. The BufferedCallbackContext is then destroyed and replaced by the new PluginResult, so that further callbacks are routed directly to JS, as if everything was normal.

The following would be left to do to make this mergeable:

  • Merge EagerAdjustCordova back into AdjustCordova.
  • Come up with a better paradigm for supplying the AdjustConfig to be used for eager initialization.
    .json file would be nice, I guess. Otherwise using an imperative call from the native code would be nice as well.
  • Make eager initialization optional:
    • Depending on whether eager AdjustConfig is present or the eager initialization call was made.
    • Prohibit calls to Adjust.create(config) then.
    • Only allow calling the new set*Callback(cb) methods when in eager mode.
  • Documentation & Tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Early / Eager SDK Initialization from Native Code
1 participant