ping @jared
So, here’s a newly edited version of my yesterday’s numerous thoughts, suggestions, and questions on the matter:
I
It seems that server log function blocks are missing from the tutorial, and the logging part might also be missing from the cloud side (unless you count the logging function for Google Cloud, which is there). However, the bigger question to my mind is do we really need the logging part as of now, as it tends to make the blocks & cloud code more complicated. I’d advocate for using merely regular alerts on the app side to indicate successes / problems with the process.
II
The sequence of presenting different steps is a bit awkward as you really can’t implement the steps following them from the very beginning. And some steps are even missing, such as being explicit about creating different Web APIs for different platforms. This becomes very clear if you try to do one concrete thing, such as begin by implementing one-time purchases for Android, which I’d advocate to be the first lesson (as an example), and then add details to this later on. If you do this (one-time purchases for Android), the sequence should be something like the following:
-
Prepare all the required blocks and functions on Thunkable at the same time, beginning from the very beginning, i.e. from creating the needed variables, and continue from there. I might also recommend avoiding utilizing separate functions as it makes learning a bit cumbersome, even though coding-wise it’s naturally elegant. Also, for the blocks (and the code with the cloud), as noted, I’d leave out the logging part and rather replace it with basic alerts on the app side. Also, as noted, there’s a need to be more explicit about steps along the way such as creating the Web API (for Android calls in this case).
-
Create a closed testing on Play Store and publish app to there. Also include testers & licencing for them.
-
Create a test item on Play Store & include it on the IAP component on Thunkable.
-
Create the Google Cloud backend, preferably without the logging part as this would make it simpler. Also, you should indicate exactly what parts of the codes for the cloud should be changed to match the user’s own info, such as the user’s package name.
-
Make a test purchase & restore the purchase with the app. For this you should test if the blocks really work currently. I was able to do a test purchase alright, but not the Get Purchase History, which might have been my fault or maybe there’s something wrong with the block, indeed. So, could you please try out that the block is actually working currently? Following your example, my app crashed with this block, and with further, simplified testing, I merely got an empty [ ] response with the block. I’m using the old editing interface, if this makes any difference.
Furthermore, I just heard from @muneer that this block might not work for one-time purchases yet, only for subscriptions. But that the team said earlier that enabling the Get Purchase History block for one-time purchases was in the works. As the tutorial seems to take it for granted that it will work for all kinds of purchases, I was wondering if the block has been upgraded now to work for one-time purchases too? And if it doesn’t work for one-time purchases (only for subscriptions), after all, will this be addressed anytime soon? It would be really good if it worked for all kinds of purchases, as without it, things such as restoring purchases to the user become way more complicated and would involve some kinds of cloud functions (which are beyond my skill level to create…).
III
Small detail, but important if you follow the example given (which is the easiest thing to do in the beginning), is that it seems that the property “removeAdsTransactionId” of stored variable storedPurchaseInfo is utilized here and there, but in the beginning this property is introduced merely as “removeAdsTransaction”. So I guess it should be corrected to “removeAdsTransactionId” when it’s introduced.
IV
Also, as @muneer pointed out earlier in a different thread (In App Purchase help - #7 by namitnagar), I’m wondering if you should first get the products info before proceeding with a purchase, at least @muneer said it was mandatory for Android. Currently, you don’t have this not reflected with the blocks as far as I can tell.
V
As noted already, the guide should be more explicit about creating different Web API’s for different platforms, just wanted to highlight this again.
VI
In terms of security, I’m worried about the possibility of reverse engineering of the app & man-in-the-middle attacks. Particularly troubling to me seems to be the fact that you’re including App Store app password with the app. Shouldn’t this password be rather on the cloud side (overall, isn’t the whole point of using your own server in the middle to control such things)? So I’d modify the Cloud code to reflect this (contain the app password there instead of the app side).
Overall, I’d urge to think through other such issues. As this concerns the payment structure, I’d really emphasize being careful here with these matters. Also, it would be good to address the question of what kinds of limitations you should impose on your cloud functions on the cloud side (for example, besides limiting use cases, can you also limit the usage?).
VII
About the cloud code, moreover, as noted in passing already, the tutorial doesn’t indicate where the user should modify the code to her own case (i.e. change package names etc.). So this should be addressed.
VIII
As I already noted in my previous message, as to layout, the color for the links in the tutorial is light grey, which makes them hard to read. Hoping this was changed. Also, as I noted before, as many Thunkers are using the old editing interface, it wouldn’t hurt to have screenshots from this side too if there are differences with the two interfaces (usually not in this case, but good to keep in mind).
–
Afterthoughts
So, that’s it. I’m really looking forward to implementing IAP and I’m really happy for all the great work done on the tutorial, but there’s still some way to go. Hopefully these things would be cleared soon, as we’re so close to getting IAP actually working for most Thunkers, which would obviously be a huge, huge boost for everyone on the platform.
I would also be very happy if someone like @muneer could participate and help out here and share your full experience, from A to Z, with implementing the IAP (including details such as your cloud code etc) if in any way possible. That would be awesome. 