Android-inapp-billing-v3: Question - Calling `loadOwnedPurchasesFromGoogle` on the main thread

[AllanWang]

From this async task you are launching loadOwnedPurchasesFromGoogle in another thread, but in the example, it is done in the main thread.

So is it safe for the main thread? And if there's any indication that it should best be done in the background, it should probably be documented.

[serggl]

Is is not good, I know. Just for simplicity of the sample

[AllanWang]

@serggl are you open to wrapping the call in an async function by default? This won't influence other users and calling loadOwnedPurchasesFromGoogle synchronously won't block the UI thread

[autonomousapps]

Changing this would be a breaking change, and so I cannot support it without updating the lib version to 2.0. If anything, we should simply document that the method may "take a long time", and should be done on a non-UI thread.

But I guess I don't exactly understand what you mean by "wrapping the call in an async function by default". How will changing the function's threading behavior _not_ influence other users?

My project, for example, offloads everything after onBillingInitialized() onto a separate thread. It is trivially easy to do, so let's just document it and provide some examples.

[AllanWang]

@autonomousapps oh actually you're right. Maybe I was thinking of something else. Wrapping it as an async task just means making it take in a callback to handle the results rather than handling the results shortly after. That way the internals can be done in another thread.

It is trivial to do ourselves, but why not add it into the library? The main billing v3 classes also have variants for synchronous and asynchronous calling.

I'm also fine with leaving it since I use Kotlin and we have our own coroutines, but this should definitely be at least documented as a potentially blocking method.

[autonomousapps]

I would be in favor of:

1. Documenting current behavior as "slow", and warranting special attention by clients.
2. Adding a new, or overloaded, method, that takes a callback.

We can't change the API of an existing method in a stable, non-experimental version.

[AllanWang]

I agree. I will likely submit a PR in a few days.

[AllanWang]

@serggl Can you do the following and send me an export of your code formatter?

It'll ensure that I have the same settings as you. I know I've already mentioned this, but it might be worth attaching the file somewhere on github as well so other contributors can keep the styling

[autonomousapps]

In my project, we recently discovered we could keep our code style in source control. If you edit your .gitignroe so that it does _not_ ignore .idea/codeStyleSettings.xml, then that style would be used by anyone using your project. You should ensure the style is a _project_ style and not the default IDE style, though.

[AllanWang]

@autonomousapps are you sure that isn't prone to be overridden though? That's a common problem with the idea files.

[autonomousapps]

Do you mean if another member of the project alters his or her project code style settings? In that case, it would be visible as part of a PR and we could reject it.

[AllanWang]

Yes that's what I mean. Makes sense so long as it's monitored

[serggl]

just added that file to the repo. Hope it will work

[AllanWang]

Still doesn't include everything. I manually included the changes for the braces but there's still indent and formatting differences.

1. Formatting removes the tabs in javadocs and aligns everything to the left
2. There may be paragraph tags when formatting the docs