Page 2 of 2

Re: Working In-App Purchases for iOS

Posted: Sat Nov 12, 2016 5:02 pm
by slime
raidho36 wrote:Maybe this can be implemented as core functionality instead, given that it's a fairly standard feature for mobile apps.
That is partly why spill shared this, I believe. :)

Re: Working In-App Purchases for iOS

Posted: Sat Nov 12, 2016 5:05 pm
by raidho36
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

Posted: Tue Nov 15, 2016 12:32 am
by spill
raidho36 wrote:Now to implement something similar for Android... Given enough effort that could show up in the next minor version.
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.
bartbes wrote:Love's event queue is thread-safe, and you don't have to predeclare events either, that might be a good option.
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:

Code: Select all

function button:onPressed()
    if love.system.makePurchase("foo.baz.item1") == "success" then
        ITEM1_UNLOCKED = true
    end
end
vs.

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

Posted: Tue Nov 15, 2016 3:29 am
by raidho36
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.

Re: Working In-App Purchases for iOS

Posted: Tue Nov 15, 2016 4:51 am
by zorg
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.
¯\_(ツ)_/¯

Re: Working In-App Purchases for iOS

Posted: Tue Nov 15, 2016 8:29 am
by Nixola
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.

Re: Working In-App Purchases for iOS

Posted: Tue Nov 15, 2016 12:14 pm
by slime
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.

Re: Working In-App Purchases for iOS

Posted: Wed Nov 16, 2016 3:56 pm
by gianmichele
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