Sunday 18 November 2012

The Amazon FAotD Experience

If you look on the web for posts by developers regarding Amazon's Free App of the Day feature, you'll find a lot of criticism for it.  Amazon didn't do themselves any favours when they started their App Store; an early-doors about-face on their FAotD policy cost them a lot of developer goodwill.  When originally announced, developers were told they would receive 20% of their app's list price on every download: a very appealing prospect.

However, before they rolled out the facility, Amazon changed this: developers would have to opt-in to the FAotD, under the condition that there would be no payments made at all.  The user would download the app for free, and Amazon would not be paying the developers anything for that day.
That coloured opinion fairly strongly, and other faults with Amazon's App Store were viewed harshly.  In it's original form, user reviews were completely sacrosanct from the developer: they could not contact the user who wrote it, or give any feedback that other users could see.

Amazon also take a very strong view on maintaining the lowest available price for every app it stocks; a developer is not supposed to offer their app on a different store for a lower price.  This means that the developer will be admonished by Amazon if they were to, for example, have a sale day on Google Play where they sold their app for half price.  Note how this contrasts with the FAotD: Amazon say it's OK for the version on their store to be sold cheaper, but it's definitely not OK for the reverse to happen.


This is the viewpoint I read about when researching the Amazon App Store.  Why was I looking at the Amazon App Store?  Unlike on the iPhone, where Apple's App Store is the only option available, on Android there are multiple App Stores, and it's recommended that you get your app out on as many as you can to maximise user exposure.  There generally is no cost to doing so (Amazon have a yearly fee, but it is currently being waived), but the downside is that every store your app is available from is another store you have to update with patches, create graphical assets for, maintain descriptions and version histories... basically, the more time and effort you have to invest.

Wednesday 7 November 2012

Pigment & the Droid, Part 2

As outlined in Part 1, the HTC Desire bracketed the heap allocation of Pigment.  That is, while developing the game, if it failed to work due to lack of memory then it would be cut back in order to fit, and thus the game came to be defined, at least in terms of heap allocation, by the Desire.  However, there came a point in development where more assets were required than could fit - there seemed to be no more screens to cut, no bitmaps that could be not-loaded, but something had to give in order for the game to work.


In order to fit more assets into memory than could physically go, Pigment uses a trick based on how some of the assets relate to each other.  One group of bitmaps the game uses are the messages, the info screens sent to the user after certain events; the "Win!" message, the tip about pressing Back to undo, the Bonus Unlocked messages, the congratulations message for completing worlds / the game.  Of these, the Science Unlocked message and the final congratulations message on completing the game made a useful pair.

The Science Unlocked message always (and only) displays after you complete your 4th level.  It doesn't matter what level it is, but when you have completed four levels total the Science Unlocked message is displayed (and, of course, the Science skin is unlocked in the Bonus menu).

The End Game message, on the other hand, only displays once you have completed every single level in the game.  Clearly it is very unlikely that a user will see both these messages in one play session.

Monday 5 November 2012

Pigment & the Droid, Part 1

When Pigment became available as a free download on Amazon's FAotD feature it became clear very quickly that there was a problem: it didn't work on some Motorola handsets - the Droid 4, Droid Razr and Razr Maxx were all reported specifically by unimpressed customers.  So: why did it crash on those phones, and how could it be fixed?


While the Amazon App Store beats Google Play hands-down at promoting your app, it is lacking in Play's technical features. Notably, if your app crashes on a Play user's phone, then they have the option to send you a report which tells you pretty specifically what went wrong.  Amazon do not (yet) have this facility.  As such, there was no way to know what was going wrong with Pigment, aside from guessing.

Educated guessing.  For one thing, customers were reporting it was crashing on the splash screen: the splash screen is displayed while the game loads its assets into memory.  For another, these type of crashes happened often during development: they occurred when the device ran out of memory.

"Out of memory?", you say, "But my phone has 16GB of internal storage!"  The memory we're talking about is the phone's temporary storage, not the place it permanently saves things.  That 16GB is the phone's equivalent of hard disk space - what we're running out of is RAM.
"But my Razr has 1GB of RAM!  How can you be using all of that up?"  Ah, a good question, the answer to which is found in how Android works: