RiTunes

RiTunes stands for “Ruby iTunes”. Cool huh? Maybe not but it is very useful. You can perform searches via the public iTunes API directly from a Ruby Rake task. The results are then added to a mySQL database where you can analyse them later.

Long Weekend uses this tool to keep track of our app rankings on the Apple App Store. We just cron the script with a bunch of relevant search terms, and get rankings of our app against other apps within a particular search term vector.

One of the hidden gems in this project is the Ruby mySQL Bulk Importer and mySQL & SQLite helper modules. We will get around to releasing these separately one day, but for now you might find it useful for writing custom migrations between mySQL and SQLite.

Kana2Rom

Ever wanted a reliable way to convert between Japanese phonetic scripts? “What’s Japanese” I hear you ask? No matter, we did but found the open source options lacking. Here is an all singing all dancing script that does gaijin friendly Romaji conversions too. If you’re not sure what I just said, then this probably isn’t for you.

Click here to visit our Open Source projects page.

This project involves at about 30 different sprite sheets, representing hundreds of frames of animation. Whilst this only translates into a few minutes of animation on the phone, the hassle of managing the asset workflow from artist to Cocos2D is made much easier by TexturePacker.

Recently we wrote about our preference for TexturePacker over good old Zwoptex. In particular the ability to load assets from folders and trigger republishing of assets from the command line are massive, massive time savers.

Here are some recently upgraded features we particularly like:

• Drag and drop assets
• Nice wide input controls on the sprite property pane
• Prominent display of texture file types in property pane
• Tooltips for all settings
• Power VR file viewer
• Improved color reduction and dithering methods
• Automatic generation of SD assets (non-retina sized assets)
• Creation of non 2-power textures
• Support for textures larger than 2048 x 2048 (not for Cocos2D unfortunately)
• Support for re-publishing assets via the command line using  TexturePacker *.tps

The only thing missing to support my workflow 100% is being able to define the relative path of the texture file in TexturePacker itself. Currently I have to edit this manually after publishing every spritesheet PLIST. I am hopeful however.

Andreas Löw’s TexturePacker is available here and is very reasonably priced!

What Do We Mean By ‘Smart Phone?’

As of December 2010, when we say Smart Phone we mean iPhone or Android. The newer Blackberrys fall into this category, but from a developer’s perspective, they are the black sheep of the family (pun!) At a recent Mobile Monday meeting in Melbourne, the RIM marketing rep claimed the upcoming PlayBook used C# for development. Methinks the RIM corporate culture does not respect third party developers.

So narrowing the definition down to iPhone OS and Android OS devices, what kind of demand shifts are we seeing? Thankfully Recruit.net in Asia and Indeed.com in the US have some great tools for graphing keywords in job advertisements. This is really broad brush, but the steepness of the graphs don’t take a PhD in statistics to interpret. For each graph, the iPhone appears in BLUE.

What Are The Trends?

United States – iPhone, Android

Australia – iPhone, Android

Singapore – iPhone, Android

Tokyo – iPhone, Android

Some Outlandish Conclusions

Attention parents of new born babies: start teaching your children Objective C concepts using Lego blocks and lashings of encouragement! More seriously however,  for me this confirms that the last 12 months were the beginning of the demand spike, and also that the skills necessary are in short supply!

From a developers perspective, the bulk of the market is not there yet. On the supply side, corporates with websites and highly evolved marketing and IT functions are just starting to sniff around the iPhone / iPad / Android space. On the demand side, whilst huge numbers of people have smart phones, there are still many many hold outs still happy with their feature phones (we know who you are, please upgrade!)

Outlandish Predictions for the Next 12 Months

On the development side, Google and Apple will hopefully get improved authoring tools. Already there are many “cross platform” platforms like Appcelerator Titanium, ANSCA Mobile’s Corona and Phonegap to make things easier. However the first two take the “kitchen for hire” approach, as your apps cook on their servers and not your local computer. Whilst Phonegap is local to your computer, it is focused on creating customised HTML/WebKit apps and not fully native apps.

PREDICTION #1: In iOS world,  someone will enter the fray with alternatives or extensions to Xcode and Interface Builder. They are great professional tools, but the learning curve is a blocker for many.

PREDICTION #2: Google will release something to make development easier on both Android and iOS. Why? Because doing so will entice more iOS developers to the Android program. Android users are notorious for not wanting to pay for apps, and piracy is a lot easier than on the iPhone. These are real deterrents for small developers who are still looking for their first million dollars of revenue.

On the demand side, 2011 is definitely the year of the Pad / Tablet / Slate computer. A lot of companies are starting to see the possibilities of this great device. It heralds the true beginning of the move from creation devices to consumption devices.

PREDICTION #3: Requests for contract iPad apps will dwarf requests for iPhone apps. Likewise for Android equivalent devices.

PREDICTION #4: The Blackberry Playbook will see a flood of requests to hastily port Flash and Adobe Air apps to the device. Developing Adobe Air Apps on the Playbook will no doubt be harder than expected and fraught with unexpected issues. In particular, Blackberry’s culture will be a blocker for dealing with oodles of developers in the SME space (why bother with SME’s when I can hit my target by dealing with a handful of Fortune 500 clients?!?!)

PREDICTION #5: The companies currently putting effort into selling tools and services to developers will report some early victories. You know what they say: when there’s a Gold Rush, the smart money is on people selling shovels!

Review Scheduled For December 2011

Let’s plan to review these trends and predictions again in 12 months time. No doubt this space will only get even more interesting. It’s nice being at the center of it all.

Wishing you a Happy Xmas and New Year from Long Weekend
〜 あけましておめでとうございます〜

Unfortunately we didn’t come away with any awards this time. However, our 2 nominations were read out on the night. We received one nomination for Best Consumer App and one nomination for Best Mobile Startup. Thanks mum!

There was some stiff competition in these categories, and the winners were Deck of Secrets for Best Consumer App, and the Voxel Agents won Best Mobile Startup, having had much success with Train Conductor 2 USA. Well done to Tom, Matthew and Co!

All The Gossip

Well, maybe only some of the gossip. SMS Global, one of the main sponsors of the event were revelling in the attention they attracted with their team of Conference Girls. Also referred to as the “Fembots” by some punters, the lovely ladies succeeded in collecting many a vote for SMS Global on the night! Is this kosher? Well I’m no rabbi, but the rules clearly state … erm … there are no rules. So I guess it is. Do we support this kind of vote rigging at Long Weekend? Certainly not for anyone who doesn’t make apps – sorry SMS Global.

Enough Blah Blah, Here Are The Photos

(above) Ben & Andrea from Mobile Monday Announcing Winners.

(above) Voxel Agents offering a hard earned high five!

Party Report

The theme of the event was Out of This World! The night started in rather tame fashion, with plenty of white shirts and white skirts among the early arrivals. Things were looking up by about 7pm with many original costumes. There was Team Clockwork Orange, both guys and gals dressed up as Stanley Kubrick’s much feared social miscreants. There were some cool robots, one complete with a business card dispensing slot!!

I also spotted a satellite (or marital aid, i couldn’t really tell). Ben from the MoMoMel team was in full parade regalia as a US Naval Commander. His girl, the lovely Suzy, was a fine geni and/or belly dancer. Her costume wasn’t white, strictly speaking, but all is forgiven! Space Elvis was even spotted in the crowd at one point – actually the 3 inch white platforms were a bit of a giveaway.

The Photos

Tim the Robot!

(above) Damian wore the screen and Miguel (below) had the camera on his head.
Is that footage of Elvis???

(above) An unlikely couple, but who am I to judge? Antenna man with Tim the Robot.

(above) The Mac Hippies, and a very lovely couple they were too. Hi Martin!

(above) Major Ben “Boogey Down” Bickford and his sparkling side kick Suzy in full “I Dream of Jeanie” regalia. I only just got the NASA reference (‘yes master!’)

Space Elvis brought his very own lamb chops (i.e. nice side burns!)

“Where’s the Massive Attack concert dude?” Nice lights Richard.

I decided that there must be some better solutions out there, and here are two approaches I have found. One is a good approach, and the other is even better and the one we use (from now on).

Typedef Enum With Matched C Array of NSStrings

[objc]
// Place this in your .h file, outside the @interface block
typedef enum {
JPG,
PNG,
GIF,
PVR
} kImageType;
NSString * const kImageTypeArray[];

…

// Place this in your .m file, outside the @implementation block
NSString * const kImageTypeArray[] = {
@"JPEG",
@"PNG",
@"GIF",
@"PowerVR"
};

…

// A method to convert an enum to string
-(NSString*) imageTypeEnumToString:(kImageType)enumVal
{
return kImageTypeArray[enumVal];
}

// A method to retrieve the int value from the C array of NSStrings
-(kImageType) imageTypeStringToEnum:(NSString*)strVal
{
int retVal;
for(int i=0; i < sizeof(kImageTypeArray)-1; i++)
{
if([(NSString*)kImageTypeArray[i] isEqual:strVal])
{
retVal = i;
break;
}
}
return (kImageType)retVal;
}[/objc]

Credit for this goes to Slava Bushtruk

Continuing the tradition of syntatic silliness that abounds in lower level languages, the enums must be declared in a different spot! This is a little counter intuitive and we can do better.

Typedef Enum With #Defined NSArray of NSStrings

[objc]
// Place this in your .h file, outside the @interface block
typedef enum {
JPG,
PNG,
GIF,
PVR
} kImageType;
#define kImageTypeArray @"JPEG", @"PNG", @"GIF", @"PowerVR", nil

…

// Place this in the .m file, inside the @implementation block
// A method to convert an enum to string
NSString* imageTypeStringToEnum( kImageType enumVal )
{
NSArray *imageTypeArray = [[NSArray alloc] initWithObjects:kImageTypeArray];
return [imageTypeArray objectAtIndex:enumVal];
}

// A method to retrieve the int value from the NSArray of NSStrings
kImageType imageTypeEnumToString(NSString* strVal)
{
NSArray *imageTypeArray = [[NSArray alloc] initWithObjects:kImageTypeArray];
NSUInteger n = [imageTypeArray indexOfObject:strVal];
if(n < 0) n = JPG;
return (kImageType) n;
}[/objc]

Credit goes to Peter N Lewis although it’s been modified it to work!

There you have it, all the declarations fit in the header, and two methods (similar to the first example), for converting between the enum and string representations.

Oh, one more thing. The original author of the second example code created a category for enum handling. Just the thing for adding to your very own NSArray class definition. Fantastic!

[objc]
@interface NSArray (EnumExtensions)

- (NSString*) stringWithEnum: (NSUInteger) enumVal;
- (NSUInteger) enumFromString: (NSString*) strVal default: (NSUInteger) def;
- (NSUInteger) enumFromString: (NSString*) strVal;

@end

@implementation NSArray (EnumExtensions)

- (NSString*) stringWithEnum: (NSUInteger) enumVal;
{
return [self objectAtIndex:enumVal];
}

- (NSUInteger) enumFromString: (NSString*) strVal default: (NSUInteger) def;
{
NSUInteger n = [self indexOfObject:strVal];
if(n < 0) n = def;
return n;
}

- (NSUInteger) enumFromString: (NSString*) strVal;
{
return [self enumFromString:strVal default:0];
}

@end
[/objc]

Credit for the category goes to Peter N Lewis on Stackoverflow.com

There are two great tools on the market that will make your life heaven, instead of hell.

Sprite Sheets Explained

Sprite sheets allow you to store and load animation frames for your sprites. Generally you store the frames for related sprites (e.g. on the same level) in a single sprite sheet. Having it in one place improves loading efficiency and game performance.

For iOS the largest spritesheet you can load is 2048 x 2048 pixels. You can have smaller ones, but only with width or height dimensions in powers of 2 (i.e. 32, 64 ,128, 256, 512, 1024 or 2048).

Generally Each sprite sheet comprises one graphics file (e.g. commonly a PNG) and one PLIST file. The PNG stores all the frames of animation for one or more sprites, whilst the PLIST stores meta data about where each logical sprite is and its name for reference purposes.

By the way, you can include different sized sprites in the one spritesheet (i.e. for different characters, backgrounds, etc) but each sprite (based on the CCSprite class) more or less requires each frame to be identically sized. By cramming in my sprites into one sprite sheet, you have less load time and better game performance.

Sprites Can Be Hard Work!

New projects usually start with non-production artwork – often something quite horrible! As things progress, artwork much closer to final is developed. However it changes many times! Keeping your PLIST files and PNG sprite sheet assets up to date can be a lot of work, which is especially defeating since you know some of that efforts is thrown away on editing PLIST and PNG files!

Thankfully there are two good tools for managing things.

Zwoptex is Good

The first tool we recommend is Zwoptex, whose authors first defined the PLIST format for Cocos2D sprite sheets. This tool allows you to graphically layout your sprites. It will then create the PNG and PLIST for you.

It’s a great tool! It can automatically layout your sprites based on best fit, which is great for tightly packing sprites into a single sheet. It also trims excess space and makes the PNG and PLIST creation process very smooth.

Ray Wenderlich has a great tutorial on using Zwoptex in a Cocos2D project!

However, Zwoptex is no longer the best.

What! You Want More???

Once you get your sprites into your project, you may find you need to optimise things. For one thing, using different color depths can drastically affect your frame rate on older devices (2G, 3G iPhones or older 2nd Gen iPod Touches for example).

Additionally, your overall bundle size can get out of hand very quickly if you have lots of graphics. Which could make it hard to ensure you stay under the 20Mb over-the-air (OTA) App Store download limit.

TexturePacker is Better

Don’t get me wrong, Zwoptex was my favorite BFF sprite tool for Cocos2D until only 3 days ago. However, once I started trying to optimize my assets, I found it offered me nothing. On the other hand, the “smirk inducingly” named TexturePacker (tee hee) offers some great benefits above and beyond Zwoptex.

For one, TexturePacker can show you how your sprites look using different color depths. This is crucial when deciding if your artwork will look any good at RGBA4444 (16 bit) instead of memory gobblingly rich RGBA8888 (32bit).

Moreover, any gradient rich artwork tends to show banding or striping at bit depths they were not made for. However, TexturePacker also provides built in dithering for making them look better at your target pixel format.

TexturePacker dithering results, check it on a iOS device screen to know for sure!

TexturePacker also supports the Power VR compressed graphics format. Every iOS device contains a PowerVR graphics chip that can decompress files in its native format very quickly. This is now supported in Cocos2D as of 0.99.5-RC1

So you can have compressed files for your sprite sheets which decompress quickly without slowing down the device!

Ray Wenderlich also has a great tutorial on using TexturePacker in a Cocos2D project!

Workflow Benefits Abound

So you’ve worked out your optimum sprite layout and pixel format. But every time you make a change to your source graphics, you feel like you have to load up the sprite sheet editor and do it all again. With Zwoptex this is currently your only choice. But with TexturePacker, you can do one of two things more.

Use Folder References in Your Project
TexturePacker allows you to include references to folders for your source graphics. So after changing an existing source PNG or adding new PNGs in the source folder, open TexturePacker and press “publish” and hey presto your sprite files will be updated.

Xcode Scripting
That’s right folks, if you can code in ObjC you can write shell scripts. TexturePacker was originally a command line tool, so you can fully automate updates to your sprite sheets right from inside Xcode. A great time saver! Combined with TexturePacker’s ability to scale source graphics automatically, you can create sprite sheets for iPhone Retina and iPhone 3G resolutions using one set of source graphics – muy bueno!!

What Will It Cost Me?

Come on, don’t be cheap, both Zwoptex and TexturePacker’s authors are indie developers looking to help you and make a little money. They offer freebies but show ‘em some love!

• Zwoptex is US$14.95, get it here
• TexturePacker is US$17.95, get it here, it is well worth the extra 3 bits!

Full disclosure: I just found TexturePacker on the web, bought a license and started using it. Long Weekend LLC has no connection to TexturePacker’s author other than being satisfied users of his software *grin*

What I found was worthy of  short post, especially since I hadn’t found any solutions on Crack Overflow. Here is the Cocoa form I had lovingly co-created, and the big red button at the bottom was refusing to respond to touches.

What we have here is a UIView inside of a UIScrollView. The height of the UIView was about 30 pixels greater than the height of its parent UIScrollView. Also, when the UITextView gets the focus, I dynamically change the UIScrollView’s contentSize parameter to allow it to move into view smoothly (IMHO, it’s a lot of work to make a Cocoa form “work like it outghta” on the iPhone).

So after fiddling around with the heights of the form’s parent UIView, the UIView’s parent UIScrollView, the UIScrollView contentSize and a few juju charms, I decided to cast some light on the situation by setting the UIView’s background color to yellow.

This is what I found!

Just what I had suspected, the button was somehow outside of its parent UIView. But interestingly, it was still visible!

Don’t ask me why. Surely clipping it would give me some fast feedback as to the problem. However,  when embedded in a UIScrollView, it doesn’t get clipped visually, but the touchable area is just as you set it.

After fixing the height of the form’s parent UIView, this is what I had, and it worked.

Peace at last.

According to TechCrunch:

Email intros will become ever more important, because you’ll want to ensure that your message gets marked with coveted ‘important’ tag … Increasingly, content will be displayed to you based on its importance rather than its time stamp — not just when it comes to browsing email, but for social networks and other content as well.

Gmail Priority Inbox sorts your email and its fantastic

Great ideas don’t just have many fathers (mothers) but also many cousins. I remember pitching this idea to Ross back in 2008. Thankfully we didn’t choose to take on Google after all!

Here is the full article.

It would seem that monthly costs is the biggest deterrent for teenagers right now. The average monthly plan for a new smart phone on a 24 month contract is US$100. Here is a list of monthly current generation smartphone costs in US dollars I found on Gizmodo.

Assuming plans come down a lot, the average teenager will probably have a smartphone in 5 years time. Whilst 63.7% of American phone owners have sent a text, only 31% have used a mobile browser and only 29% have used downloaded apps (according to Mashable).

IMHO everything is pointing towards absolutely EVERYONE on the planet having a smartphone in about 10 years time. Even under-privileged kids in Africa will soon be browsing pictures of porn and food on the Internet using their cheap smart phones provided by the UN (okay, I made this bit up, but I do support OLPC! Do you?)

So why are teens so happy without Smartphones? Surely they should be stopping at nothing short of multiple part time jobs and a few well-timed tantrums to get a Smartphone? So what do teens do on their phones?

Resoundingly, they send text messages! In fact, 1 in 3 teens in America sends more than 100 texts a day! “Hello, my name is [blah] and I’m a text-a-holic!”

54% of all teens use SMS to contact friends. This is substantially more than other contact methods including instant messenger, email, Facebook, voice calls (by mobile or landline phone) and meeting face to face. That’s right, teens use texts MORE than any other mode of social interaction (according to the Pew Internet’s report on Teens and Mobile Phones by way of Benson Cheng).

Excuse me. My teenage cousin has just sent me a text!

NB: Pew Internet sampled 800 American teens aged 12-17 for their insightful report.