Hi,
I’m just started using Store plugin to integrate iap into my app.
I realized that store plugin is initialized with a single callback… all subsequent calls to store sends results to this callback…
How to modularize game so Store functionality can be accessed from multiple views (Storyboard scenes)?
Isn’t best to have individual callbacks for each call like network.request do?
Thank you.
Hi @backend,
Although the docs generally illustrate one callback function, it’s not required to configure it that way. You can declare various callbacks to handle different aspects of the store functionality.
Take care,
Brent
So… I can call store.init multiple times?
Hi @backend,
Well, the callback that you use for store.init() generally handles many things, but some store calls can have their own callback, i.e. .loadProducts(). Is there a specific reason why you want to separate this process out into many callbacks?
Brent
Hi @Brent, we have many scenes from wich user can buy things…
We need to detect when user has purchased the item to animate things on the scene based on item buyed…
How to do it?
For handling transaction requests, you are going to use the call back listener function you defined in .init(). You can use techniques where you have the function you want to actually handle the call be part of your scene and attach it to the storyboard object directly:
… somewhere in your storyboard scene …
storyboard.state = {} -- if you haven't already done this. function storyboard.state.handlePurchase( params ) ... end
Since you’re including storyboard in main.lua where your store.init() is, then in that transaction call back function would would call:
[lua]
storyboard.state.handlePurchase( whatever, params, need, passed )
[/lua]
Though a better way than using the storyboard object would be to use a global data table (that’s not a Lua global). See: http://coronalabs.com/blog/2013/05/28/tutorial-goodbye-globals/
That way you won’t run into namespace issues with storyboard. The reason I used the “state” table was in a previous tutorial we showed people how to use that table to pass globally visible items around, and we’ve avoided using .state as a member for our use. Now that storyboard is deprecated, you can use anything that won’t clash with an existing API call. But if you switch to Composer or some other method, we can’t guarantee that “.state” is safe. By using the globally available table in that tutorial you future proof your code and get the same benefits.
Rob
Rob
Hi @backend,
Although the docs generally illustrate one callback function, it’s not required to configure it that way. You can declare various callbacks to handle different aspects of the store functionality.
Take care,
Brent
So… I can call store.init multiple times?
Hi @backend,
Well, the callback that you use for store.init() generally handles many things, but some store calls can have their own callback, i.e. .loadProducts(). Is there a specific reason why you want to separate this process out into many callbacks?
Brent
Hi @Brent, we have many scenes from wich user can buy things…
We need to detect when user has purchased the item to animate things on the scene based on item buyed…
How to do it?
For handling transaction requests, you are going to use the call back listener function you defined in .init(). You can use techniques where you have the function you want to actually handle the call be part of your scene and attach it to the storyboard object directly:
… somewhere in your storyboard scene …
storyboard.state = {} -- if you haven't already done this. function storyboard.state.handlePurchase( params ) ... end
Since you’re including storyboard in main.lua where your store.init() is, then in that transaction call back function would would call:
[lua]
storyboard.state.handlePurchase( whatever, params, need, passed )
[/lua]
Though a better way than using the storyboard object would be to use a global data table (that’s not a Lua global). See: http://coronalabs.com/blog/2013/05/28/tutorial-goodbye-globals/
That way you won’t run into namespace issues with storyboard. The reason I used the “state” table was in a previous tutorial we showed people how to use that table to pass globally visible items around, and we’ve avoided using .state as a member for our use. Now that storyboard is deprecated, you can use anything that won’t clash with an existing API call. But if you switch to Composer or some other method, we can’t guarantee that “.state” is safe. By using the globally available table in that tutorial you future proof your code and get the same benefits.
Rob
Rob