In App Purchase product sequencing

One last minute change I had to make right before submitting Monster Cache for review was that the In-App Purchasing products on iPhone were displaying in what seemed like a random sequence.  For iOS, you send a request to the App Store for your available products, then it returns you a list of your products.  I iterated through the list in the order it was sent, and the order was not the sequence I wanted.

What was really happening is they were sorting based on their hidden product ID.  Well, I put numbers in those representing numbers of coins, like coins50, coins100, coins500, coins1000, etc.  As many people know from sorting music tracks with numbers, they don't sort numerically, they sort alphabetically, so 100 comes before 50 because it starts with 1 which is less than 5.

Once I figured that out, I considered trying to sort the array that they returned before I iterated through it, but it wasn't just the product ID's, it was an array of objects.  That seemed like too much hassle, so I just deleted and recreated half of my in app purchasing products to give the product ID's leading 0's, like coins0050. (You can't change a product ID once it has been set, which is why I had to delete and recreate).

Pricing

Started a conversation about pricing for our In App Purchasing today.  All of our In App Purchasing products will be bundles of coins.  The question is how much to sell each bundle of coins for.  Here were my thoughts on it today:

We definitely want to offer better value for higher amounts.  My first idea was:

$3.99 - 100 coins

$5.99 - 300 coins

$7.99 - 500 coins

But now I think that is too high.  With 100 coins, you can currently buy 13 nets (10 nets for 70 coins and then 3 single nets at 10 each).  So that means $4/13 nets = 30 cents / net.  That seems like quite a bit to charge.  Especially since people have been easily getting 13 in a week or two at the start.  So I'm thinking either 2.99 or 1.99 for 100.  I like $1.99 because its little enough that I think people will do it. Maybe

$1.99 - 100 coins = 2c / coin = 15c / net

$3.99 - 300 coins = 1.3c / coin = 10c / net (or less with bigger net packages)

$5.99 - 600 coins = 1c / coin

$8.99 - 1000 coins = .9c/coin

If we also have bulk buying options of nets for coins, then someone could probably buy about 200 nets for 1000 coins / $8.99.  I like the idea that if you're willing to spend $8.99, you can play *almost* indefinitely   Matt has gone WELL over 200 nets with his GOD account though, so the real dedicated users may still have to pay more.

----------------------

Kent agreed that $1.99 is a good starting point.  He indirectly brought up the issue of consumables vs. non-consumables.  Since our Silver and Mirror items do not diminish, we could sell them as non-consumables in the app store.  But I kinda like keeping it consistent with just selling coins.  We'll see.

Phonegap In App Billing plugin for Android - v2 API

Yesterday I got motivated to make my first PhoneGap contribution.  I planned to add some calls to a couple of API functions that weren't implemented in the plugin.  I don't know Java, but I hoped that I could just copy some parts that were making other API calls and just make the changes for the calls that I needed.

As I started looking at the Java code in the plugin, I noticed that there was basically just one API call being made with a different command message being sent as a parameter.  That wasn't what I was expecting to see.  So I started looking back at the Android API documentation and found that the calls being used in the plugin were from the version 2 (v2) API.  The v3 API is the latest, but just came out in last month or so.  But its quite a bit different.  So essentially the plugin would need a major upgrade to support the v2 API.  Not knowing Java, that seemed to be too much for me, so I had to give up on helping with the plugin :-(

And MonsterCache will just have to get by with the v2 API features for now.  The two v3 features I was trying to implement were:

• Getting the list of available products and prices from the store.  I can store those myself, but getting them from the Play store may send you a converted currency in other countries, I'm not sure.
• Consuming items.  In v3 all items in the store are "Managed", meaning Google keeps track of whether a user has bought them so that they don't have to be bought again.  But if your item should able to be bought again -- like in-game currency -- then you have to "consume" the item so that the user can buy it again.  In v2 though, they have "Unmanaged" items, and you can still make those in the Play store, so v2 still works

So once I coded for v2, it looks like Android In App Purchasing is working.  I'll have to have my test user (my wife) run a test tomorrow to be sure.  Google doesn't let you buy your own product.

I also got a JQuery popup dialog working today.  That was very good because I have lots of basic ugly alert() boxes that I could replace now with something that would look better.

Tomorrow I'm going to take a shot at the iOS In App Billing plugin.

signed .apk file and first in-app product

When I started my in-app billing testing with Android a little over a week ago, I got the test product working (android.test.purchased) and wanted to try my real products.  That led me to a long list of pre-requisites.  Before I could create an in-app product in the Google Developer Console, I first had to upload my .apk.  No problem, I thought.  I uploaded it and got an error that it was not "zip aligned".

Okay, so I did some reading and found the zipalign tool that you have to run on a .apk file before uploading. Fine, I ran the tool, uploaded again.  Now an error that my .apk is not signed.  Back to the documentation.

Before you can upload your .apk, it has to be complied in release mode and signed with a key.  All the documentation emphasizes doing this with command line tools, but it also can be done using a wizard in Eclipse.  You just right click on the project and choose Export.  The part about the keystore was still confusing to me, so I had to read  more about that.  After all the reading and trial and error that day, I basically gave up on it and worked on some other stuff.

But today I revisited it.  Reading about generating a keystore using the command line tools helped me to understand what was being asked for in the wizard in Eclipse.  I didn't get that it was asking me to create a new password-protected keystore file that then contains a separate key with its own password. So I finally got past that, got the .apk file signed, then zip aligned, and then uploaded it successfully to the Developer Console.  From there it was easy to make the first in-app product!

But now it's 5:30 on New Years Eve, so I'm calling it quits! Happy New Year!

In-App Billing setback

Just when I thought we were so close... in signing up for Apple Developer and Google Developer accounts, I found that both have restrictions that you must use their markets for purchasing any digital goods in the application.  I failed to anticipate that restriction :-(   My in-app purchasing is not done with their markets.  Actually, it isn't even in-app purchasing technically, because I link out to our web site to do a purchase.  That's also against the terms of both companies.

So.... I need to implement in-app billing for both Apple and Android.  Luckily, very recently an in-app billing Phonegap Plugin was made for just that purpose!  Plugins are separate per OS, so that meant I also needed to split the market page into a version for each OS.  I tried the Android one first, and it worked!  You just use Google's test product IDs, and they come back with fake success messages.  So cool to see the Google Play market open for the first time.

But then.... I discovered that the Plugin seems to be missing a few key features I needed, like the purchaseToken and the API call to consume an in-app purchase.  It looks like I may need to do those parts of the plugin myself.  If I succeed in improving the plugin, of course I would want to share those changes with other PhoneGap users.  That means that I've finally made my way to the GitHub community.  I feel like I'm just barely understanding everything I'm doing, so hopefully I don't make a fool of myself there.  It may be too late as I've already tried to message someone and hopefully didn't send the message to a bunch of people :-/

So much to learn!