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

android: Use LabelSync plugin #2281

Closed

Conversation

jonas-lundqvist
Copy link

Explicitly setting the "use_labels" setting in the Android code might be
antithetical to "plugins" but since there is no way to plug in or out
modules in runtime in Android we might as well hardcode when needed.

There are a couple of things to fix/investigate:

  • Currently the application has to be restarted when the settings have
    changed.
  • run_hook is not runned on main thread and a warning is printed. Is
    this a problem here?
  • Is a force upload/download option needed?
  • Should the 'android' part of the plugin, including the hooks, be more
    generically named? There isn't any Android specific things and other
    clients (iOS?) could use it...

Explicitly setting the "use_labels" setting in the Android code might be
antithetical to "plugins" but since there is no way to plug in or out
modules in runtime in Android we might as well hardcode when needed.

There are a couple of things to fix/investigate:
* Currently the application has to be restarted when the settings have
  changed.
* run_hook is not runned on main thread and a warning is printed. Is
  this a problem here?
* Is a force upload/download option needed?
* Should the 'android' part of the plugin, including the hooks, be more
  generically named? There isn't any Android specific things and other
  clients (iOS?) could use it...
@mhsmith
Copy link
Collaborator

mhsmith commented May 26, 2021

Explicitly setting the "use_labels" setting in the Android code might be
antithetical to "plugins" but since there is no way to plug in or out
modules in runtime in Android we might as well hardcode when needed.

Yes, as Calin said on Telegram, if the plugin is always present then the setting might as well always be present too. But I'm a bit confused about how the setting works. Why are there two names: use_labels and synchronize_labels? And I can't see anything that reads either of those settings, so how does it take effect?

  • run_hook is not runned on main thread and a warning is printed. Is
    this a problem here?

I don't think that matters.

  • Is a force upload/download option needed?

I'm not sure how this feature's supposed to be used: will it upload and download labels automatically, and if so when?

  • Should the 'android' part of the plugin, including the hooks, be more
    generically named? There isn't any Android specific things and other
    clients (iOS?) could use it...

Rather than creating new hooks specifically for Android, I suggest you reuse the on_new_window and on_close_window hooks, since it looks like those are the de-facto open/close wallet hook names used by Qt plugins. Then following that pattern, you can create an Android "window" class with a single "wallet" member, and any Android-specific stuff can be added to that class in the future.

But you might as well keep the "android.py" filename for the moment, since every other plugin file is named after its platform. If the iOS app uses it in the future, we can deal with it then.

@jonas-lundqvist
Copy link
Author

jonas-lundqvist commented Jun 17, 2021

Explicitly setting the "use_labels" setting in the Android code might be
antithetical to "plugins" but since there is no way to plug in or out
modules in runtime in Android we might as well hardcode when needed.

Yes, as Calin said on Telegram, if the plugin is always present then the setting might as well always be present too. But I'm a bit confused about how the setting works. Why are there two names: use_labels and synchronize_labels? And I can't see anything that reads either of those settings, so how does it take effect?

Ah, it should just be one and I fixed it in latest commits. And that setting is what enables the plugin. Any use_{plugin} boolean works as a switch, see INTERNAL_USE_PREFIX in plugins.py

  • Is a force upload/download option needed?

I'm not sure how this feature's supposed to be used: will it upload and download labels automatically, and if so when?

It will download when opening a wallet and upload when there is a change in any labels. There might be a sync problem when multiple instances of the same wallet is running with sync (for instance desktop and mobile) where it could be beneficial to explicitly resynchronize it.

  • Should the 'android' part of the plugin, including the hooks, be more
    generically named? There isn't any Android specific things and other
    clients (iOS?) could use it...

Rather than creating new hooks specifically for Android, I suggest you reuse the on_new_window and on_close_window hooks, since it looks like those are the de-facto open/close wallet hook names used by Qt plugins. Then following that pattern, you can create an Android "window" class with a single "wallet" member, and any Android-specific stuff can be added to that class in the future.

Please see latest commit.

But you might as well keep the "android.py" filename for the moment, since every other plugin file is named after its platform. If the iOS app uses it in the future, we can deal with it then.

Ack!

@cculianu
Copy link
Collaborator

I'm late to the party here but..

@jonas-lundqvist

run_hook is not runned on main thread and a warning is printed. Is this a problem here?

Hmm. My memory is fuzzy (it's been a few months since I looked at how the "hooks" work) -- but I remember explicitly adding that warning because if hooks didn't run on the main thread something bad could happen -- since the "contract" is that the hooks may modify the UI in some cases. Not sure if that's relevant here. Also not really sure how the Andrioid app is architected -- but if it does end up touching the GUI it should be on the same thread as the GUI thread (typically this is the main thread in most GUI systems -- again I am an Android ignoramus so maybe that's not the case on Android? If that's the case then the run_hook warning needs to change for Android to account for that...).

@mhsmith
Copy link
Collaborator

mhsmith commented Jul 5, 2021

Any use_{plugin} boolean works as a switch, see INTERNAL_USE_PREFIX in plugins.py

Ah, I see.

Currently the application has to be restarted when the settings have changed.

Yes, that'll have to be fixed, because there's no obvious way to restart an Android app process -- the user would have to to go into the settings and force-stop it. You could activate/deactivate the plugin using a settings observer like the one in the original commit.

run_hook is not runned on main thread and a warning is printed. Is this a problem here?

not really sure how the Andrioid app is architected -- but if it does end up touching the GUI it should be on the same thread as the GUI thread (typically this is the main thread in most GUI systems -- again I am an Android ignoramus so maybe that's not the case on Android?

Yes, Android has the same main thread rule. In this case the hooks don't actually touch the GUI, but the warning could be fixed by moving the hook calls from load_wallet and close_wallet (which are called on a background thread) to select_wallet (which is called on the main thread). When no wallet is open (select_wallet(None)), it would also be a good idea to set window.wallet = None so it can be garbage-collected.

There might be a sync problem when multiple instances of the same wallet is running with sync (for instance desktop and mobile) where it could be beneficial to explicitly resynchronize it.

OK, in that case, how about adding a label sync section to the settings, with the switch to enable the plugin, and two commands for force upload and download? The commands could use a TaskDialog subclass to run the network access on a background thread while keeping the UI alive. And the "dependency" attribute could be used to disable the commands if the plugin is disabled, as is currently done in the Fiat settings.

@mhsmith mhsmith added the android label Aug 3, 2021
@mhsmith mhsmith marked this pull request as draft July 19, 2022 14:23
This was referenced Nov 3, 2022
@jonas-lundqvist
Copy link
Author

The LabelSync plugin had been removed.

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

Successfully merging this pull request may close these issues.

None yet

3 participants