6Tringle Blog

Renascence of 6Tringle et al.

2009-02-02T00:00:00Z

Alternative title: You disappear for 2 years and you expect me to take you back?

Sorry for not writing sooner, we've been busy. We can explain. Let's just start over, shall we?

PhotoClay

6Tringle is happy to announce the imminent availability of PhotoClay on the iPhone. It's like turning Photos into Clay, you can push and mold them to your will. We've made it fun and easy to render silly visages of your friends!

The cauldron is still bubbling however, and there are a couple of other projects being slow roasted to perfection. We'll let you know more when we can.

_gasp_ Marketing!?

2009-03-30T00:00:00Z

Given that the iTunes App Store population is rising, developers who launched on a prayer aren't always raking in the millions. News posts about 9 year old iPhone developers earning their college tuition overnight seems to have pushed expectations beyond the ceiling of reality. Even the smartest developers are only relying on luck if they don't, gasp, do marketing.

Three points from Steve Demeter

I had the good fortune to Meetup with Steve Demeter of Demiforce recently. Over the course of about 30 seconds I was able to swindle vital information.

It's important for many late-comers to the App Store to remember the early success stories basically don't apply anymore. Apps that were put up early had an extraordinary advantage in terms of visibility. Steve mentioned that new apps need to influence their own visibility and provided a handful of examples how recent apps have.

Create Demand Before you release

Steve talked about the importance of creating demand before release through the use of blogs, YouTube, etc. His example here was Zen Bound. Through the use of YouTube and some good press, the developer had customers "salivating" to buy the app.

Zen Bound

Get Good Reviews on Day One

If you app starts off with bad reviews, customers won't wait for your patches and updates to turn it around. You want to start off strong. Good reviews are infectious. If your beta testers love your app, have them positively review it the day it comes out. Resist the urge to cheat. You'll get caught.

Use Review sites

Unless your app is terrible, review sites almost always help you. Steve's key insight is to allow review sites early access to the final version of your app before it's available in the store. You want the reviews to be release as near as possible to the review date such that you can move up on the hot lists. Most review sites have a large backlog and thus would need access to the app a couple of weeks ahead of time.

Here's a short list. Needless to say, stay away from sites that condone pirated apps, and be wary of those that support jailbreaking. Gruber: "Not all jailbreakers are bootleggers, but all bootleggers are jailbreakers."

It's not a review site, but http://iphone.iusethis.com/ is a nifty site as well. If you testers or customers like your app, kindly suggest they give your app a vote.

If you need more help

In addition to being very tall, Steve's company, Demiforce, is a consulting company specializing in iPhone app and game development as well as promotion and marketing. Steve's a good guy and I'm sure he can help you look good.

Disclaimer: 6Tringle is not affiliated with Steve or his company. We have not contracted him to work for us, nor was this post or recommendation solicited by Demiforce or Steve.

iPhone Unit Testing with OCUnit

2009-04-06T00:00:00Z

There are a scattering of iPhone based testing frameworks and utilities:

Google's was one of the first. They've apparently built a lot of infrastructure around their solution to fit within existing test systems. With a recent Xcode update, Apple's brought back the original Objective-C test solution.

OCUnit

If you're coming from GTM, then the biggest difference is that OCUnit is the integration into Xcode. This means you get IDE errors instead of having to parse the console output (plus!). It also means you have to go to the console to read your log messages, rather than having them display in the built-in console (minus!).

This one ships with Apple, but the only clear instructions come from Sente (the original author of OCUnit, back in 1998).

Lecture 19 of the Stanford iPhone class had some slides and an example project. Unfortunately, due to the nature of the Stanford website, it's unlikely the slides and sample files will reappear on the website until Lecture 19 is presented for the current semester. Even when the links existed however, the Stanford way didn't give detailed instructions. In the mean time, all I can say is that you trust me when I say that the Stanford way of linking is much easier to do.

The Sente method of having the test run every time you build is far superior to the Stanford method (you have to manually change the target and run the tests). If you aren't continually running your tests, they approach a moldy and lifeless state.

Here's a set of instructions that take the best of both worlds

Add a new Unit Test bundle target (Project -> New Target... -> Mac OS X -> Unit Test Bundle)

[] (/media/images/NewTargetUnitTestBundle.png)
Modify the "Other Linker Flags" setting.

We need to change the Cocoa value to Foundation. This will allow us to compile for the iPhone Simlulator

[] (/media/images/UnitTestBundleOtherLinkerFlags.png)

[] (/media/images/UnitTestBundleOtherLinkerFlagsEdit.png)

Lastly, search for any Cocoa.h references and delete them:

[] (/media/images/UnitTestBundleSearchCocoah.png)

If you prematurely built and got the following Cocoa.h errors:

/System /Library /Frameworks /Cocoa.framework /Headers /Cocoa.h:13:26: error: AppKit/AppKit.h: No such file or directory /System /Library /Frameworks /Cocoa.framework /Headers /Cocoa.h:14:30: error: CoreData/CoreData.h: No such file or directory

You may need to do a Clean All Targets to clear them. Somewhat counterintuitively, if your project does not contain any tests, it will register a test failure.
Another note about test failures:

/Developer /Tools /RunPlatformUnitTests.include: 384: error: Failed tests for architecture 'i386' (GC OFF)

The description here about failure has nothing to do with the architecture or garbage collection. It's just information for your reference about the environment in which the test failed. The part you need to pay attention to is Failed tests. Similarly, there is nothing wrong with the RunPlatformUnitTests.include script.
Add a test file with a TestCase subclass in it.

Using the Mac OS X -> Cocoa -> Unit Test Case Class Template, create and add a new test case file.

Test Case files MUST end in TestCase (ie. MathTestCase or BackEndTestCase). Similarly, all test methods should start with test. The underlying tech mechanism uses some very nifty runtime magic to determine which classes and methods to run by their names.

[] (/media/images/XcodeAddUnitTestCase.png)

Make sure you are only adding to the Unit Test Bundle and not to the main Project

[] (/media/images/XcodeAddUnitTestCaseAddToProject.png)

Add a test

Here's a easy one you can use to test the test framework itself. (How very meta.)

- (void)testTestFramework
{
    NSString *string1 = @"test";
    NSString *string2 = @"test";
    STAssertEquals(string1, 
                   string2, 
                   @"FAILURE");
    NSUInteger uint_1 = 4;
    NSUInteger uint_2 = 4;
    STAssertEquals(uint_1, 
                   uint_2, 
                   @"FAILURE");
}

Build the test bundle, make sure tests pass
Build the test bundle, make sure tests fail

Again, just to exercise your test framework, temporarily change one of the strings to force a test failure.

[] (/media/images/UnitTestForceAFailure.png)
Add the unit test bundle as a dependent

Now, we want the unit tests to run every time we build. We can do this by setting a dependency on the Unit Test Bundle. Switch back to the main project target (away from the unit test bundle) and Edit the Active Target. Click the + button under to add and new Direct Dependancy

[] (/media/images/XcodeAddUnitTestBundleDependancy.png)
Build the app, make sure test pass and fail

Now you have an automated, up to date testing framework in place. Every time you build, you will be immediately notified of any test regressions. The rest is attitude. Xcode will keep the tests running every build, but you have to keep writing tests when appropriate.

Sample project available at 6Tringle's github repository.

An aesthetic note about header files

Test Case files almost always have an nearly useless header file, so I usually get rid of them, creating single file test cases. The resultant .m looks like this:

//only run on the simulator
#include "TargetConditionals.h"
#if !TARGET_OS_IPHONE || TARGET_IPHONE_SIMULATOR
#import <SenTestingKit/SenTestingKit.h>
@interface SampleTestCase : SenTestCase 
{
}
@end
@implementation SampleTestCase
- (void) setUp
{
    // Optional
}
- (void) tearDown
{
    // Optional
}
- (void)testTestFramework
{
    NSString *string1 = @"test";
    NSString *string2 = @"test";
    STAssertEqualObjects(string1, 
                         string2, 
                         @"FAILURE");

    NSUInteger uint_1 = 4;
    NSUInteger uint_2 = 4;
    STAssertEquals(uint_1, 
                   uint_2, 
                   @"FAILURE");
}
@end
#endif

iPhone Touch Sample Code

2009-05-10T00:00:00Z

The iPhone SDK's UIKit allows extremely versatile touch event handling. With only four methods, Apple has exposed nearly limitless potential for programatic reaction. The problem is that these four methods are essentially exposing the hardware. To do anything interesting or useful, one must wrap meat around these bones. Apple's Event Handling documentation covers several simple cases of touch handling:

single, double, triple tap etc.
swipes
location sensitive combo touches, simply described as a "Complex Multi-Touch Sequence", this is merely doing hit-testing on the touches.

Curiously, clear examples for certain basic interactions such as tap-and-hold or pinch-to-zoom are missing.

I'd like to rectify that. This recent inclination is compounded by my new-found passion for the au courant open source repository Github. This illicit dyad has produced the creatively named TouchSampleCode.

Currently, I've coded examples for the following cases (along with the implicit intention to add more):

Tap and Hold
Tap and Hold with delay
DoubleTap and Hold
Multi-touch (two fingers) with simple stretch and pinch for zoom and unzoom

The iPhones lack of a keyboard doesn't mean it's not a rich environment for human interaction. The current limitation is not in the hardware, but in the creatively of the developers. Future postings will explore some conjectures on creative uses of the interface.

Please consider leaving a tip if you find this useful. These kinds of small tokens are great energizers and tend to encourage more content.

The Secret Life of _cmd

2009-05-29T00:00:00Z

An Objective-C class in Cocoa has one hidden object that every knows about. The self object is used extensive within a class to reference the object currently invoking a method.

There is another hidden variable that very few seem to know about: _cmd.

_cmd is the method that is currently being invoked. So if self is the subject, _cmd is the verb.

The most obvious application of _cmd is logging. Here is one of my most used macros:

#define METHOD_LOG (NSLog(@"%@ %s\n%@", \
                    NSStringFromSelector(_cmd), \
                    __FILE__, self))

You would typically use it in a method like follows:

- (void)viewDidLoad
{
    METHOD_LOG;

    //do stuff...
}

This logs a message to the console telling, what method, from what file, invoked with what object.

Tremendously useful. Here's a second version that adds thread information:

#define METHOD_LOG_THREAD (NSLog(@"%@ %@ %s\n%@", \
                        NSStringFromSelector(_cmd), \
                        [NSThread currentThread], \
                        __FILE__, self))

_cmd is not only for logging. We can play neat tricks with it as well.

This method returns an object in a dictionary where the key is the method name,

- (id)color;
{
    //SomeDictionary defined elsewhere in class
    return [SomeDictionary 
            objectForKey:NSStringFromSelector(_cmd)];
}

You could combine this with a property to get easy access inside a dictionary.

@property (readonly) id color;

If you wanted a read-write property, you could implement it this way:

- (id)color;
{
    //SomeDictionary defined elsewhere in class
    return [SomeDictionary objectForKey:
                [NSStringFromSelector(_cmd) capitalize]];
}
- (void)setColor:(id)someObject;
{
    //3 means we start from the C in Color
    NSString *partial_string;
    partial_string = [NSStringFromSelector(_cmd) 
                        substringFromIndex:3];

    //SomeDictionary defined elsewhere in class
    [SomeDictionary setObject:someObject 
                       forKey:partial_string]; 
}

Now, we have a color property, without ever creating a color instance variable in the class. This has some advantages in that you don't have worry as much about memory management. The object is retained when it's added to SomeDictionary and released when SomeDictionary is released or when the object is replaced.

The Objective-C runtime is full of neat little tricks and _cmd is just one of them.

More advanced techniques can be used to implement some advanced functionality such as higher-order-messaging and even mimic methods as nearly first class objects.

Functional programming aficionados can check out http://www.cocoadev.com/index.pl?HigherOrderMessaging for some discussion on this.

App Store Reviewers Are _Only_ Paid to Review Apps

2009-05-30T00:00:00Z

"Never ascribe to malice, that which can be explained by incompetence."

--Napoleon Bonaparte

Daring Fireball's John Gruber recently did another bit on the app store review process. While I usually enjoy his satire (brushed metal anyone?), this one didn't seem quite right. The piece is funny enough, but I hate to think that they are being intentionally cruel or evil. Despite the above quote, I'm not even sure that incompetence is involved at the level of the individual reviewers.

I have my own theory on why there are so many rejections and why many highly publicized rejections seem so silly:

The large pool of reviewers are likely judged on how many apps they handle over a period of time.

By handle, I mean download, install, evaluate, approve/reject and feedback. If this is the case, then the apparent problems result from the fact that rejections can be done quickly (by finding/exaggerating/creating a violation) and that approval takes time (the entire app must be checked against the iPhone SDK Agreement Section 3.3 and its fifteen subsections).

In the case of Eucalyptus, The reviewer found it took almost no time at all to reject the app by searching for the Kama Sutra. If the intention was to approve the app, then the reviewer would have had to confirm and checkoff every feature against the long list of guidelines.

By quickly rejecting the app, the reviewer can move on to the next item, increasing his number of "handled" apps. Meanwhile, the developer is left feeling bullied and angry. It ultimately ends up a disservice to the millions of App Store users now denied the ability to purchase and benefit from Eucalyptus.

This, again, is just my own speculation but it could explain stories like the Tweetie rejection, the NIN rejection, and even the bizarre green icon rejection. It also explains why the feedback emails are often short.

There are many examples of mis-incentives across every industry. The New York Times has a great piece on the NBA addressing how focusing on the wrong stats can cost you games. In the early days of phone support, operators were graded on how many customers they handled in an hour. This lead to the operator hanging up in the middle of difficult or long support calls, so they could fish for easier, shorter calls to boost their daily numbers. Customers would become more upset and managers didn't understand why their internal metrics didn't match external surveys of customer satisfaction.

You have to incentivize the right metric and apps/hour is not it. The iTunesConnect entity within Apple may or may not believe that the developers it serves are its customers. However, if they don't evolve, refine and improves their service (like Apple evolves, refines and improves its iPods), developers will leave the ecosystem and writers will continue to make fun of them.