in-app purchase best practise: how to use what is downloaded - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Design (/forum-5.html)
+--- Thread: in-app purchase best practise: how to use what is downloaded (/thread-9311.html)
in-app purchase best practise: how to use what is downloaded - sefiroths - Aug 30, 2011 01:09 AM
simple example of the problem:
i have an app that can download backgrounds from in-app purchase.
so i download images (or a zipped image).
now that i have it on my iphone...how can my app knows the name of the image and can load as background of the game?
what i have thought is zip of the image+downloaded.plist;
downloaded.plist is a filename that contains the name of what i have downloaded, so my app loads that plist (i know the name because is always equal) and then the rest...
but now i have to save that information in another local plist that contains all add-on downloaded...
this is a very basic example, but i can in future load levels, character...so i'd like to know how to organize work to have it more general as possible...
what is the standard method to make this?
RE: in-app purchase best practise: how to use what is downloaded - OneSadCookie - Aug 30, 2011 09:24 AM
The recommended method for handling IAP is to have all the content in your app already, so that you don't have to do anything but enable it...
RE: in-app purchase best practise: how to use what is downloaded - sefiroths - Aug 31, 2011 01:24 AM
thanks for tha answer,
so, if i had understood well, if i want to make other levels or backgrounds ecc, after my first release, i'll put in apple store an upgraded version of the entire app with the other contents...isn't it?
why it is recommended this method?
RE: in-app purchase best practise: how to use what is downloaded - OneSadCookie - Aug 31, 2011 01:34 AM
Because it's simple and cheap. Your code is trivial, Apple covers the bandwidth for the content, and your customers don't have to wait after making an IAP to receive it.
RE: in-app purchase best practise: how to use what is downloaded - sefiroths - Aug 31, 2011 05:31 AM
thanks for explanations!
RE: in-app purchase best practise: how to use what is downloaded - sefiroths - Aug 9, 2012 08:23 AM
i continue from this discussion because i have similar problem:
i have an app with a plist containing 100 strings (word.plist).
if i use inapp purchase to download a list of strings (perhaps stored in a plist, newword.plist) and want to upgrade the old list with the new.
what are the basic steps to achieve this?
if i must upgrade with other words should i use the same name far all? i explain better:
i downloaded the first pack of word->newword.plist
i download another pack of word...(with the same name i suppose, so i know the name of the file that hold information)...
or what solution can you think?
RE: in-app purchase best practise: how to use what is downloaded - MattDiamond - Aug 13, 2012 04:04 AM
Why not read in more than one file? For example you could scan your app's directory for any files with the name starting with "WORDLIST" of some other string. Then read them all in.
This would let you easily add additional files for purchase in the future.
RE: in-app purchase best practise: how to use what is downloaded - OneSadCookie - Aug 13, 2012 06:47 PM
Also, why download the word files rather than ship them with your app and use a simple setting to control access to them?
RE: in-app purchase best practise: how to use what is downloaded - MattDiamond - Aug 16, 2012 04:11 AM
I was thinking of the downside: if you come up with more sets of words to purchase you have to release another version of your game. But now that I think about it getting it to be completely dynamic would only be worth it if you were planning lots of content drops, say a magazine or book service.
So yeah, don't download them, just ship them with the app. But reading multiple files from a directory is still not a bad way to do it. Or just have one file, but split it up internally.
One downside is if you ship the wordlist with the app as a plain text file, I believe it's not hard for people to open your app's package (using Mac or PC) and modify the list of words. Probably no big deal unless your app explodes in popularity, and/or has multiplayer. But you might think about adding a simple encryption or checksum to the final version of your app. I read that Words With Friends didn't lock down their list at first and had to add it later.