Upgrade/Sidegrade/Downgrade subscriptions

[nexxuno]

Please take a moment to fill out the following:

Fixes #26 .

Changes Proposed in this pull request:
-aidl updated to latest version
-new method that makes sense only for android becuase upgrading downgrading on apple is supported natively in the store
-added new method to doc

[nexxuno]

There is a little typo in the UWP implementation which exception should say that Windows store doesn't support upgrades at the moment.

[nexxuno]

hi @jamesmontemagno , are you still working on this plugin or is it on hold? Maybe there are plans of integrating this in Essentials that I don't know of?

[jamesmontemagno]

No plans on Essentials integration as it is tricky with payments and isn't a good fit. I will add this to my backlog to test. Any changes you want to make @nexxuno ?

[nexxuno]

I've fixed a string typo. It should be good now.

Thanks.

[jamesmontemagno]

Is there no API to do this on iOS?

[StefAnglr]

Apple handles it on the backend with their "Subscription Groups," no device-side implementation necessary.

[nexxuno]

With Apple you define subscription groups and buying another subscrption from a group automatically triggers the upgrade/sidegrade. In windows there isn't this concept at all. I give hints about this in the exception messages of the 2 platforms.

…

________________________________ From: James Montemagno <notifications@github.com> Sent: Thursday, January 17, 2019 4:16:14 AM To: jamesmontemagno/InAppBillingPlugin Cc: Paolo Ferrazza; Mention Subject: Re: [jamesmontemagno/InAppBillingPlugin] Upgrade/Sidegrade/Downgrade subscriptions (#192) Is there no API to do this on iOS? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fjamesmontemagno%2FInAppBillingPlugin%2Fpull%2F192%23issuecomment-455027411&data=02%7C01%7C%7C387be35400914555041808d67c2a2467%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636832917768182408&sdata=b%2FOPGvn70%2FiB57WV1N6xiH5RtvEqoCc94pGEJzXEDrU%3D&reserved=0>, or mute the thread<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fnotifications%2Funsubscribe-auth%2FAOxBAFTv9lgolMepknlECqbGH4Dv_GkTks5vD-r-gaJpZM4YtelA&data=02%7C01%7C%7C387be35400914555041808d67c2a2467%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636832917768182408&sdata=voKeHGd0jW2KgoUMWjs6xpR16lpnMSKZEBRRL8z09WE%3D&reserved=0>.

[adamzucchi]

@nexxuno & @jamesmontemagno - Any idea when this is likely to be released?

[Gabriel1786]

I need this, when will this be made available?

[Zomby2D]

I needed it as well so I had to use the plugin's source projects in my solution instead of the Nuget package.
I also needed to disable proration in some cases, which led me to add an optional "proration" parameter

[adamzucchi]

Hello @nexxuno -
First thank you for contributing the PR for upgrades/downgrades. I've been playing with this branch for the upgrade/downgrade of subscriptions and have a question. Between iOS and Android I'm not sure what property or properties one can use to determine if a subscription is 'current' or the active subscription?

For example on Android the 'AutoRenewing' property does get set to true after a purchase however after upgrading to a different subscription the previous in-app product that was purchased is still marked as AutoRenewing true as well? On iOS AutoRenewing is always returned as false.

The PurchaseState property is another property I've been investigating and on Android this property is showing as PaymentPending for all previously purchased subscriptions and on iOS this property is showing as Purchased for all previously purchased subscriptions.

Any thoughts/ideas on this? Again just looking for the simplest way to determine what subscription is the active subscription for a user after numerous subscriptions have been purchased (whether upgraded or downgraded).

Thanks in advance!

[nexxuno]

Hi @adamzucchi ,
I'm using this
var owned = (await inAppBilling.GetPurchasesAsync(ItemType.Subscription)).SingleOrDefault(x => x.State != PurchaseState.Refunded);

and I didn't notice any problem.

[adamzucchi]

@nexxuno - Thank you for the reply!

I'm excited to try this approach with our next build and release : )

[yuv4ik]

@jamesmontemagno any plans on accepting this PR and making it available on NuGet?

[adamzucchi]

@nexxuno (cc @jamesmontemagno ) - I wanted to update you on my progress testing this PR. First thanks @nexxuno for posting this PR!

Earlier in this thread I asked @nexxuno how to get the current/active subscription for a user. He suggested the following:

var owned = (await inAppBilling.GetPurchasesAsync(ItemType.Subscription)).SingleOrDefault(x => x.State != PurchaseState.Refunded);

The issue I ran into with this is that multiple subscriptions at a time may evaluate to true which throws an exception - especially if you have multiple subscription groups that you've made purchases from. So I am having to do some custom sorting/filtering (to narrow the subscriptions I get returned to a single subscription group) and am using FirstOrDefault instead of SingleOrDefault.

My other piece of feedback is around the following use case example. Within a subscription group, if I purchase the least valuable subscription, upgrade to the next highest value subscription, and then attempt to downgrade to the previously purchased least valuable, I am experiencing some strange behavior. On iOS I get a "You're all set..." message which makes you think everything processed fine, however an exception is thrown by the plugin with error code 0 that it could not connect to the store.

After some research I found the following Apple forum post:
https://forums.developer.apple.com/thread/112663

From what I understand of this, this is actually the expected behavior from Apple? It appears Apple keeps you on the higher subscription and only takes you down the the downgraded subscription once the higher subscription runs out. Can anyone think of a way the plugin could handle this scenario more elegantly?

Has anyone else here experienced this? Have a solution?

Thanks in advance - and please let me know if you need further descriptions of any of this. I'd be happy to hop on a screen share and try to get this fixed/tested for the plugin.

Thanks!

Adam

[nexxuno]

Hi Adam,
Everything you are reporting is correct but it fits my business use cases. What I mean is that, as per design of my business logics, I imposed that A a user cannot but more than one subscrption, B cannot downgrade so I show them only sidegrades/upgrades. While the first condition may not fit your use case (and your solution is obviously correct), the second condition should be applicable for you too, just don't let your users downgrade their service level, if they want to they'll do that at the end of their current subscription period.

[StefAnglr]

Any hope of getting this merged?

[StefAnglr]

Guess that's a no?

[jamesmontemagno]

We will need to re-base this off the new master where I use the new NuGet for google play billing.

[WouterStraver]

Is this still planned to release any time soon?

[InquisitorJax]

+1 on waiting for this guy - so sad this is moving so slow :(

[WorldOfBasti]

Will this be added soon?

[mnxamdev]

Any thoughts on getting this merged in? Looks like there are merge conflicts. We could really use the Android subscription upgrade ability.

[jamesmontemagno]

It would be need to be re-based and re-implemented against latest APIs. iOS/UWP should be similar, Android I am not sure.