01-21-2013 11:58 AM
This bug still exists in the latest internal version of the app so it is unlikely to be fixed by the time your app is released.
Keep in mind that if there were purchases in the cache the API would return them as expected. As well these error messages should not be displayed to the end user, so really if the errors were hidden the application would function fine and in either case you would still need to upload a new version with the error messages hidden.
01-21-2013 12:20 PM
I'll most likely completely remove IAP and let apps free. My four apps for BB10 were just test of the platform so there will not be huge loss.
Current implementation of IAP seems to me too hard to test (as far as I understood even Sandbox version does not remember bought goods as well as I didn't find way how to simulate various errors)
In Android it took tree versions of IAP API to make it developer friendly so I'll wait till there will me better tools for testing and debugging.
01-21-2013 12:27 PM
Improvements to IAP are on the way, so stability, fixes and new features will continue to come with future SDK releases. So, just as you mentioned, it will definitely get better with time.
Look forward to having you back once we get a few releases in!
01-22-2013 09:13 AM
Spent part of today by trying to bend sample code according your advice but I'm really unhappy with result.
Local mode is not very close to real network results (there are no delays) as well as it is difficult to distinguish various errors. Some of them can be safely ignored but some of the need to be reported.
It looks like various errors (already purchased, user canceled) has the same error code and there is NO WAY how to hadle these situations.
Documentaion for error codes is also not very helpful - https://developer.blackberry.com/cascades/referenc
Could you please update sample to be workarounding this issue with local cache?
I would also appreciate simple absolutely minimal bullet-proof sample of upgrading application from FREE to PAID.
Simple class with two public methods methods:
Nothing else but bullet-proof with handling multiple calls methods if previous call was not finished or ended with error. I'm sure such a example will improve popularity of IAP among developers and member of your team will make it in a few hours.
In this use case I really don't need all the bells and whistles you have in https://github.com/blackberry/Cascades-Samples/blo
01-22-2013 09:26 AM
Let me start by saying that the issue with the error being provided when no cache is available is a bug and I have logged it with development. It would not be terribly useful to update a sample to work with a bug when a fix is imminent, it would end up causing more confusion than necessary.
When checking local cache right now, if an error is thrown or 0 results returned you should be fine to assume that there are no purchases in cache. The next step would be to check the App World servers (passing 'true' into the past purchase request).
I am working on a freemium sample but it will not be ready until later in February. If you would like to work on implementing this yourself I would be happy to assist.
Basic workflow that I can think of:
1) App launches and checks for existing purchases (local QSettings, App World Cache, App World Servers)
If the purchase to upgrade to "Pro" exists fire a signal
2) Have a slot defined in your main app that is connected to the "proPurchased" signal which then unlocks your app
The proPurchased signal would also be fired if the user makes the purchase while using the app.
There are many ways this could be implemented and it really depends on how your app is structured and presented to the user, there will be no one-way solution that will work for all apps, but I will be creating a generic sample that will show this model which may be useful. Again, it likely will not be released until February.
01-22-2013 09:46 AM
I alredy tried to implement it in similar way but flow you suggested has following issues:
So it seems to be quite dificult task for beginner (I started with Cascades two month ago).
01-22-2013 09:56 AM
What you can do is store a value that lets you know if the app has ever been launched before. As well save any purchases made using QSettings. If the app has been launched before then you only really need to check QSettings for info on past purchases. You may want to allow the user to check manually in the event good were purchased by the same user on another device.
An ActivityIndicator is an easy way to let the user know your app is thinking and is used universally for this purpose in Cascades and BlackBerry 10.
Local cache will never fail for a network reason, it is local to the device. So if this fails with an error or returns 0 results then you can assume that there are no purchases in the cache, even if an error the message details can be displayed to the user to provide more insight into what the response was. If checking the App World server you can always present the error message details to the user if the call fails, this should include information about why the call failed.
I definitely agree that there is a huge need to make the error messages far more robust. Have you logged any of your concerns over in Issue Tracker? https://www.blackberry.com/jira/secure/Dashboard.j
And for sandbox mode, the latest version of the app should always be the one that is presented. There is, however, a cache used in the App World client meaning it may take a few hours to see the updated version.
01-22-2013 11:43 AM
01-22-2013 12:26 PM
01-22-2013 12:33 PM
There's no one "correct" way. If it works for your usage then it is correct
The sample does not look overly flexible however. It looks to handle purchasing as well ad freemium messaging, but it may be more usable in other use cases if these were split up.