Non-backwards compatible changes. Closes #52, closes #90.

[hpique]

• IMPORTANT: Requests are now confirmed by default if you use the short version of requestPurchase or requestSubscription. Please make sure this doesn't break your app.
• Better support for server-side signature validation. Signature validation is now performed asynchronously.
• Store signedData and signature in the transactions database. This requires an update of the database, so please test thoroughly before updating.
• Added orderId to IBillingObserver.onPurchaseStateChanged. This is particularly useful to differentiate between different orders of the same unmanaged item, and in general makes it simpler to track orders.
• Bug fix: incorrect types for product id and developer payload in database (fortunately, SQLite didn't mind)
• Bug fix: rebind service on remote exception.
• A few more tests and minor refactoring.

[ludocrazy]

if i'm not mistaken, this (#92) would also close #49. correct?

[hpique]

@ludocrazy Not sure, will check. BTW, thanks for answering a few issues! You're awesome.

[ludocrazy]

i might be mistaken but i think it also closes #28. i'm not sure if i understand #28 properly, but to me it sounded like the author of that issue simply wanted to get all notifications to be autoreplied by the billing library and this is now the case withy our above changes. correct?

[thisisnottheaccountyourelookingfor]

Any reason not to pass the Transaction object to onPurchaseStateChanged instead of pieces? I recently made this change in order to add analytics and needed orderId and developerPayload.

On a related note, any reason for the public Transaction fields not to be 'final'?

[hpique]

@jgilbert42 Initially I wanted to keep onPurchaseStateChanged simple but given that it's fairly common to require the orderId or the developerPayload, it might be time to change this. Might do it before merging this pull request. Thanks for bringing this up.

Regarding using final for the Transaction fields, I don't see what could be gained from it. Do you?

[thisisnottheaccountyourelookingfor]

@hpique Regarding using final for the Transaction fields, I don't see what could be gained from it. Do you?

Not much really, but since AFAIK there's no reason they're modified directly it might help new developers to avoid mistakes if it is passed to onPurchaseStateChanged. Transactions appear to be stored before onPurchaseStateChanged is called anyway. More of a documentation in code type thought. A transaction does represent the signed payload that people shouldn't be modifying.

[jayschwa]

Hello, I am new to this library. I'm wondering if I should be starting with this branch rather than master. It appears to have some significant bug fixes not present in master. Can someone who is knowledgeable let me know the best repo/branch to start from? Thanks.

[hpique]

@jayschwa This pull request will be eventually merged with master, and as far as I know it doesn't introduce any new bugs.

There's still a few things I'd like to change before merging it, though, so it might be best to wait before using it in production code.

[Magnesus]

Is this library still supported? Or should be jump to using something else?

[hpique]

I haven't been able to update it in while, sadly.

I've seen a few forks that are active, and you're more than welcome to
submit pull requests. :)

Hermes Pique

Head Robot*
ROBOT MEDIA
Create memorable stories

Like us on Facebook: http://facebook.com/robotmedia
Follow us on Twitter: http://twitter.com/robotmedia

Twitter: @hpique
Skype: hermespique
Office: +34 936 760 014
Mobile: +34 690 745 505
http://www.robotmedia.net

Carrer de Nàpols, 187 9º
08013, Barcelona, Spain

• (not an actual robot)

Create Memorable Stories with Storybuilder! Request an Invite @
http://www.facebook.com/storybuilder

On Tue, Jul 16, 2013 at 5:11 PM, Magnesus [email protected] wrote:

Is this library still supported? Or should be jump to using something else?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/92#issuecomment-21048677
.