That is partly why spill shared this, I believe.raidho36 wrote:Maybe this can be implemented as core functionality instead, given that it's a fairly standard feature for mobile apps.
Working In-App Purchases for iOS
- slime
- Solid Snayke
- Posts: 3163
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Working In-App Purchases for iOS
Re: Working In-App Purchases for iOS
Now to implement something similar for Android... Given enough effort that could show up in the next minor version.
Re: Working In-App Purchases for iOS
That's what I'm currently working on. Right now, I'm trying to figure out how to add the appropriate billing helper module and wrap my head around the Android dev environment. Based on the iOS experience, it should take a couple of weeks to get it finished. In my ideal world, purchasing would be built into löve by default, and hopefully this work will lead to that, or at least help anyone else who wants to do IAP in the meantime.raidho36 wrote:Now to implement something similar for Android... Given enough effort that could show up in the next minor version.
I'd prefer suspending the lua code execution on the API call and returning the result of the purchase once it's finished (like love.window.showMessageBox() does) instead of having an SDL event because it makes the code a lot cleaner, as you can see here:bartbes wrote:Love's event queue is thread-safe, and you don't have to predeclare events either, that might be a good option.
Code: Select all
function button:onPressed()
if love.system.makePurchase("foo.baz.item1") == "success" then
ITEM1_UNLOCKED = true
end
end
Code: Select all
function button:onPressed()
pauseGame()
love.system.makePurchase("foo.baz.item1")
end
local dispatchTable = {
["foo.baz.item1"]=function(status)
unpauseGame()
if status == "success" then
ITEM1_UNLOCKED = true
end
end,
}
function love.purchased(purchaseID, status)
if dispatchTable[purchaseID] then dispatchTable[purchaseID](status) end
end
Re: Working In-App Purchases for iOS
On the flipsede it freezes the game for the whole duration, which may be a lot, especially if it has to timeout - up to 2 minutes. Freezing the app alone creates poor user experience since it becomes unresponsive and there is no progress indication, and sophisticated OS can detect it as hang (because that's what it is) and suggest kill the app or even do it automatically.
IAPs are fundamentally networking activity and you never do synchronous networking, period.
IAPs are fundamentally networking activity and you never do synchronous networking, period.
- zorg
- Party member
- Posts: 3465
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Working In-App Purchases for iOS
raidho36 wrote:On the flipsede it freezes the game for the whole duration, which may be a lot, especially if it has to timeout - up to 2 minutes. Freezing the app alone creates poor user experience since it becomes unresponsive and there is no progress indication, and sophisticated OS can detect it as hang (because that's what it is) and suggest kill the app or even do it automatically.
IAPs are fundamentally networking activity and you never do synchronous networking, period.
zorg wrote:Okay, but one could just not use the modal messagebox function, and just implement a visual one with löve itself, that way it may not block. (i.e. not freeze the whole game)
¯\_(ツ)_/¯Spill wrote:Actually no, Apple doesn't let you do that. Presumably in order to prevent apps from making deceptive or confusing purchase dialogs (or stealing the user's credentials, maybe?), the only way to make a purchase through Apple involves using their native purchase modal dialog. There's no way to request a purchase without popping one up. It also fills in the region/currency-specific pricing, which is something you wouldn't want to do by hand.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Re: Working In-App Purchases for iOS
I think he said Apple doesn't let you implement a visual purchasing window or anything, and you have to call the function to have the OS "window" pop up and request a purchase; that doesn't mean the background application has to hang, as you can draw a "working..." animation/something while the purchase is completed.
lf = love.filesystem
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
- slime
- Solid Snayke
- Posts: 3163
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Working In-App Purchases for iOS
Theoretically you can. But SDL's messagebox API is always blocking even though iOS allows for non-blocking message boxes, so you'd have to use the native iOS Objective-C APIs for it instead of SDL.
-
- Citizen
- Posts: 66
- Joined: Tue Jan 14, 2014 11:03 pm
Re: Working In-App Purchases for iOS
Hey, thanks a lot for this!
It's actually really good to study how to implement these different services.
I'm quite curious to see how the implementation would be using FFI. Keep hearing people it's a possible solution, but I haven't seen anything properly done this way yet (I mean a service like Vungle or Game Center). Just small examples of simple libraries.
@slime: hint hint a good tutorial would be great.
In the meantime I'm going to experiment and try and wrap Vungle or Unity Ads to see if I can work it out. Wish me luck!
Gian
It's actually really good to study how to implement these different services.
I'm quite curious to see how the implementation would be using FFI. Keep hearing people it's a possible solution, but I haven't seen anything properly done this way yet (I mean a service like Vungle or Game Center). Just small examples of simple libraries.
@slime: hint hint a good tutorial would be great.
In the meantime I'm going to experiment and try and wrap Vungle or Unity Ads to see if I can work it out. Wish me luck!
Gian
Who is online
Users browsing this forum: Bing [Bot] and 5 guests