What’d you do to my phone bill?!
If your game is going to send data over the network, remember that it’s going to cost your users money to do that. If it costs too much – i.e. if they raise an eyebrow even a bit at the cost – you’re in trouble. To avoid this, you’ve got to compress any data sent over the network. The second place where uncompressed data can screw up your app is in the game. Uncompressed text data stored in the game can slow load times and compromise the user’s experience. Large amounts of text data in-game need to be compressed and doing so can speed up your load times, which is always a plus. Copy and add these two files to your project to get around these two landmines:
Posts Tagged ‘iPhone’
Compression
Posted in Code, tagged compression, data, iPhone on May 6, 2009| Leave a Comment »
How To Prevent iPhone App Piracy
Posted in Apps, Code, tagged Apps, Info.plist, iPhone, piracy on May 5, 2009| 1 Comment »
Get Off My Boat, err, App!
The waters off Somalia isn’t the only place pirates disrupt the work of good, honest folks just trying to get their haul of tuna back to port. The iPhone app store is picked apart daily by the world’s internet pirates and a burgeoning library of apps – some 6,000 of the 25,000 for sale in the app store – are now available online for free. Big Brother (Apple) sits back in his chair – hands up, palms out, to show how clean they are – and spouts some kind of “the enemy of my friend is my friend”-type of head scratcher. So we’re on our own out here in a leaky fishing trawler trying to protect our catch from zooted up pirates and, let me tell you, Obama’s Navy Seal sniper team ain’t nowhere in sight, brother. So all you got is your wiles; here’s how to use ‘em.
First, you’re going to want to know if your app has been hacked. That genetic code of your app – Info.plist – will give you all the evidence you need.
1. If the file, once uploaded, is in text format, you’ve been hacked. When you upload your app, the file is converted into binary code, so if Info.plist is in text, it’s because someone wanted to change the parameters to allow your app to work on any phone and they’ve converted it back to text in order to do that.
2. Search for “SignerIdentity” in your uploaded Info.plist file. This is the fingerprint of a hacker. It’s the Shibboleth for your app to work on any phone. If it’s there, it shouldn’t be there.
3. When you’re finished with your Info.plist file, you know its size. So if that changes once it’s been uploaded, somebody’s gotten into it and screwed around.
Ok, so the pirates have their grappling hooks thrown over the side of your boat and a dude with no teeth and one ear has you looking cross-eyed at the business end of an RPG. It’s time to get diplomatic, so get out your sticks and carrots.
You’ve got a couple options. You can either shut out users who have a pirated app and just make the thing not work. But this is overkill, there’s no need to scuttle the ship right away. Instead, set a time limit, or max number of times a user can open the app, and when one of those parameters is met, display a message and explain that it appears the app on their iPhone is pirated and, please, we’re just family people trying to eke out a living in this cruel, electronic world, so why not click this link and dole out the measly $2.99 for our app? This tactic has been tried, and the results were surprising — conversion rates – from pirate-copy user to legit-copy user – of around 10% were seen when a calm explanation of the situation and an invitation to purchase the app were offered. The added bonus to this approach is that when someone cracks your code, it won’t be immediately obvious to the hacker that there is a built in fail-safe; he/she may play for a few minutes and move on to the next app thinking that this one is cracked. But when the hacked app is downloaded, after a few minutes, or a few uses (whichever you decide) users will get the notification that their copy is pirated and a request to buy the legit version.
There you have it. If only diplomacy worked this well in Somalia.
iPhone Audio Basics
Posted in Code, Games, tagged audio, iPhone on May 5, 2009| Leave a Comment »
It’s all in the details. You’re so focused on getting your app just right – making the splatter effect when missile meets buffalo in your “BuffaloZapper 2: The ReZappening” app, perfect – that you forget the system on which your app will be played was not designed with only your app in mind; your user has his or her own things going on with their phone, too, and they don’t want your app to blot those things out.
The big spot where this comes into play is with sound and music. Your exploding buffalo noise might be great, but your users might not care if they can’t have their favorite Anthrax track playing in the background when it happens.
So you’ve got to have your sounds right. To do this, you need to consider the different situations that could arise for a user and what expectations they would have for your app, their iPhone, and their music. Below is a chart that diagrams all the sonic situations your app should be prepared to accommodate for its users.
Headphones Plugged In | iPod Music Playing | Silent Switch On
(iPhone only) |
Music | Sound Effects |
---|---|---|---|---|