search

tinypass / piano-sdk-for-android

Piano SDK for Android
https://docs.piano.io/mobile-app-experiences
Apache License 2.0
15 stars 11 forks source link

Adding support for creation of Multiple Instances of PianoId and Composer #47

Open akash-ramaswamy opened 2 months ago

akash-ramaswamy commented 2 months ago

Hi @DeKaN !

Currently we are developing a flutter application, which has 3 products as separate routes with 3 individual AID. We use flutter plugin to communicate with SDK (both composer and ID) but we are stuck with a singleton for both composer and ID. Is there a way we could use this SDK with multiple AID?

I thought that this would be possible, since we are initiating the PianoIdClient and Composer only when the respective AID product page is visited, and destroyed when done.

Thanks !

akash-ramaswamy commented 2 months ago

To make things clearer, I thought of somehow make the PianoIdClient null, so that it would be reset, and call the init method again so that the client could be initiated again with new AID.

Even a handy method for changing the aid property would work ig :)

This was my thought process, your inputs would be valuable on this @DeKaN :)

DeKaN commented 2 months ago

By design, one AID should be used for one app. Looks like, you have three apps in one. Can users switch between them without the app's restart, or can your app choose one AID and use it until restart?

akash-ramaswamy commented 2 months ago

Yeah, actually you can visualize those 3 apps as 3 different screens, and users can open each app as separate Activity. They cannot be in more than 1 activity at a time. And yeah they can use any of the three screens (any of the three app) without restarting.

All those three screens are in one single application :) And those three apps have different AIDs :)

Hope i was clear, please do let me know if you need more clarifications.

Thanks!

DeKaN commented 2 months ago

Hmm, one AID per screen looks like one AID per webpage (many AIDs for domain). Why did you choose many AIDs instead one?

akash-ramaswamy commented 2 months ago

yeah, we have 3 different products, which we wanted to manage under three different AIDs. And we had a requirement for a super app, which contains these three products that can be accessed from home screen.

akash-ramaswamy commented 2 months ago

@DeKaN any updates on this?

DeKaN commented 2 months ago

Hi @akash-ramaswamy,

The best solution is to use one AID (maybe a new one) because SDK saves some data in preferences. Also, ID user tokens will be different between AIDs, that can cause additional issues

akash-ramaswamy commented 2 months ago

Hi @DeKaN ,

Is there any other way? because I still think this would be possible, since at any point in time only a single AID would be invoked in a particular screen. We do not have any usecase to use multiple AIDs in same screen.

DeKaN commented 2 months ago

There are some restrictions: Composer backend sends some configuration data (which can be different between AIDs), that affects counting visits (We store configuration and temporary visited in preferences). ID backend sends user tokens, which are different between AIDs. Composer Show template uses Composer instance for tracking. C1X uses Composer instance for tracking. ID custom forms use Composer instance for tracking and ID instance for loading user info.

akash-ramaswamy commented 2 months ago

Thanks @DeKaN ! understood.

I have a question here. Let's say Im properly creating an instance (of both Piano and Composer) for each screen (each sub-app) and disposing it on exiting the respective screen (sub-app).

Now are we working under the restrictions properly? If yes, are there any way to achieve this? (like a dispose method so that we can re-init the client?)

DeKaN commented 2 months ago

Let's imagine, that you can recreate instance: User start app User visits screen A (AID=A), you init and call Composer, and it saves visitId=1 and settings from backend. User closes screen A, you destroy Composer instance. One minute later user visits screen B (AID=B), you init and call Composer, it loads saved visitId and settings and sends incorrect visitId to backend You got incorrect stats in Composer.

Another example: User start app User visits screen A (AID=A), you init and call Composer, and it saves visitId=1 and settings from backend. User closes screen A, you destroy Composer instance and remove its saved data. One minute later user visits screen A again, you init and call Composer, and it saves visitId=2 and settings from backend. You got incorrect stats in Composer (should be one visitId=1, but the backend got two ids).

And custom forms / show template bring some other issues

akash-ramaswamy commented 2 months ago

@DeKaN thanks for your detailed explanation. I could understand the intrcacies and the issues that would occur.

btw is there any other reliable way we could handle this? Because this is a crucial requirement for us, and the Piano Integration is the only pending thing for us to launch the application.

DeKaN commented 2 months ago

Looks like the issue with storage can be fixed by linking prefs to AID After that, it will be possible to add disposing, but issues with custom forms / show template can't be fixed easily.

akash-ramaswamy commented 2 months ago

Hi @DeKaN !

Thanks for the inputs! doesn't the linking prefs to AID solve the template issues too? Im curious to know why, since I could see here that each experience is initiated by passing the aid explicitly!

Thanks for your time on this!

DeKaN commented 2 months ago

Hi @akash-ramaswamy ,

templates/forms call track*** functions and there is no information about AID, but Composer instance has this data

akash-ramaswamy commented 2 months ago

Hi @DeKaN !

Thanks for your explanation. By anyways, does this feature request seem to be possible? If so, it would solve a major issue for us. Else we need to drop our project idea and think of some other way.