BlackBerry® World™ Development

[thubalek]

Why do you thing it is better to split it? How do you recommend to split it?

For me purpose of this class is to hide complexity of IAP into one class with very simple public interface, easy to integrate to any app that requires Free/Paid functionality via IAP.

[gbeukeboom]

If the only goal of your sample is to allow apps to upgrade from free to paid then your solution could work, it just makes it very strict and prevents models that allow more payment flexibility (selling other goods etc).

[thubalek]

Do you think that there will be more levels of Premium functionality? Like FREE, GOLD, PLATINUM? Is this common on BB?

According my experience this would confuse users. Users understand very well FREE/PAID and everything else needs comparision of the versions, looking at web pages, ...

[gbeukeboom]

I'm not talking about more levels of functionality, but what I am saying is that if the app would still like to sell more goods apart from the premium app upgrade it would not be able to use your model (ex if the app is a game and they sell outfits for your character, you may want to unlock the full app including all levels as well as sell outfits).

[thubalek]

This is EXACTLY what I DON'T NEED.

I need boolean switch between FREE and PAID app (or TRIAL/FULL). Please let me know if this is not legit usage of InAppPurchase.

Not sure what is ratio of  freemium games/games/normal apps in BB World is but I'm almost sure that majority of apps needs this simple usage of IAP and developers spend hundreds and maybe thousands hours reinventing wheel. I belive simple single purpose class delivered by BB could solve their nightmare.

WP7 has even support for trials built in AppHub with quite simple API, I wish BB had the same.

[gbeukeboom]

You can create a sample that just has a switch, I'm just saying it won't be useful for other scenarios, it becomes a sample tightly coupled to checking for one purchase only.

[thubalek]

Hello,

I implemented it as you suggested but seems that it can't be tested locally:

- Existing purchases response success (local).
- Existing purchases response success (local). (No purchases)
- Existing purchases response error (remote). Code( 1 ) Text( "Get existing purchases (network) not supported in tes
t mode." )

Does it mean that I can test it in Sandbox only? So I need to upload app into BB World?

[gbeukeboom]

It can be tested in local mode for purchases made during the lifecycle of the application. As soon as the application is closed all past purchases are lost.

[thubalek]

So why it returns an error 

Code( 1 ) Text( "Get existing purchases (network) not supported in test mode." )

if I invoke 

mPaymentManager->requestExistingPurchases(true) ?

But I tried this on my app that I already have in AppWorld and it seems to be working. Unfortunately I already own virtual good (I bought it in the pas) so I could just verify that it restores  previous purchase.

Thanks for your help

Tom

[gbeukeboom]

It doesn't work because you are trying to pull from App World. Pulling from local cache will work.

Your app can only communicate with App World if installed through App World.