Lots of very vanilla drawing code that is fairly boring, but one interesting part is how the new canvas-based clock uses svg paths. The old flex code used svg paths liberally as simple way to draw shapes, but since canvas doesn’t support drawing svg path data directly I had to write my own:

function drawPath(ctx,path,fill,ang) {
    ctx.save();
    ctx.rotate(ang == undefined ? 0 : ang  * Math.PI / 180.0);
    ctx.beginPath();
 
    var parts = path.split(' ');
    while (parts.length > 0) {
        var part = parts.shift();
        if (part == 'M') {
            coords = parts.shift().split(',');
            ctx.moveTo(coords[0], coords[1]);
        } else if (part == 'L') {
            continue;
        } else if (part == 'Z') {
            break;
        } else if (part.indexOf(',') >= 0) {
            coords = part.split(',');
            ctx.lineTo(coords[0], coords[1]);
        }
    }
 
    ctx.closePath();
    ctx.fillStyle = (fill == undefined ? '#000' : fill);
    ctx.fill();
    ctx.restore();
}

The drawPath() function takes svg path data as input (with the restriction that it contains only M (move to), L (line to), and Z (close path) elements), and executes moveTo() and lineTo() calls in the canvas element instead. It does zero error checking, so the incoming svg path data must be well formatted.

If you call it like this:

drawPath(ctx, 'M 0,0 L 0,10 10,10 10,0 Z');

You’d get a nice 10px by 10px square as expected.

Conclusion

It’s no surprise that canvas is just as powerful as Flex or SVG as far as drawing shapes and gradients, but it would definitely make canvas extra cool if it had more intergrated svg path support. Yes, of course, I could have used pure svg if I wanted to draw a bunch of svg shapes, but I had set my mind on using canvas only.

Files

• clock.html

Flex’s Future

With a singular, spectacular blog post Adobe eviscerated Flex and any hope of ever using Flex again. Thanks Adobe! Flex is dead dead, not just a little dead. No one in their right mind should ever start development on a Flex app. Period. I’ll make a nice pull quote just so you understand my opinion on the matter:

“Flex is dead!” — Justin

Spoon is not dead, nor is the open sourcing of Flex on Apache (as Apache Flex), but alas, no amount of open sourcing or intense community love will change things in this particular case. But since everyone is in love with zombies nowadays, I’m sure there are plenty of people and companies out there that see the simulacrum of life in Flex and call it life.

Flex Mobile’s Future (aka Adobe AIR)

Flex Mobile, aka Adobe’s cross-compiler that take AS3 code as input and outputs iOS binaries (as a fully formed IPA) and also Android binaries (APK), is decidedly not dead yet. But the most unfortunate part is that it certainly should be. In general, cross-platform mobile solutions (particularly Flex Mobile) really suffer when the make contact with reality (a real app with real functionality and real users). Sure they can be made to look pretty, sure they make great demos, and sure they lower the initial bar for developer. But you will never ever have as much control as you will when you go native. It is still the case today (March 24 2013) that the only good answer is go native, and write it twice. Twice being once for iOS and once for Android.

Flash Player’s Future

Banned from iOS, unsupported by Chrome Mobile, officially discontinued on all interesting mobile platforms, click to install on desktop Safari, no 64-bit flash player on linux, and now click to run on Firefox. Hmmm…I wonder what is next? How about dead. Yep, my crystal ball says that the flash player itself is on the gallows.

Let’s think about how Adobe makes money from Flash (this is coming from a developer that actually knows nothing)… From what I can tell, they sell really nice authoring tools, they sell some server-side tools (mainly Flash MediaServer, aka FMS), and they have a bunch of game stuff. I love games and I love watching video online, but does the flash-related parts of any of those mostly desktop businesses look healthy and awesome to you, especially with the rapid growth of mobile and tablets?

Adobe’s Future

Adobe will be certainly fine (but again, I’m just some guy who writes code). I always think of them as a tools company. Photoshop is a sweet piece of software (Photoshop 1.0 source is now available in the Computer History Museum). But the whole platform play that is Flash and Flex? I always felt that was Macromedia’s idea, and Adobe just went along for the ride after the aquistion. That ride isn’t much fun anymore.

And who just left? Kevin Lynch is moving to Apple (aka they guy who was chief software architect at Macromedia).

My Future

I know I’ll be doing some more speaking. And I’m trying hard to figure out how to create more teaching opportunities. I love teaching, but for whatever reason it’s hard to find the right teaching opportunity with the right students. I’ll always be learning new feameworks and languages, because that is a constant. But writing more content for this blog, probably not so much…

I’m working on couple of app ideas right now, and still writing lots of code, but only a little bit of that work will make it all the way to this blog. Watch my my github for some new projects.

Here’s one of those issues that I faced this past week: rotating an object in Flex. I was playing with the camera in Flex Mobile, and I quickly learned that it is landscape only even if the device is being held in portrait. Really, Adobe?

“…a Video object attached to the camera will only show upright video in a landscape-aspect orientation. Thus, mobile apps should use a landscape orientation when displaying video and should not auto-rotate.”
     – official Adobe docs for flash.media.Camera

Sad but true. So, if you wanted to build a video chat app and use the front camera you either always hold the iPhone in landscape or you hold it portrait and rotate the video in code. (Why did I say iPhone?…Alas, Flex Mobile does not provide front camera support for Android…period…none!)

Option 1: rotation Attribute

The first thing to try is to rotate the easy way, like this:

camera.rotation = 90;

Using actionscript, I just set the rotation to 90°. Of course, this rotates about (0,0), the upper left corner in Flex, and not what we need.

Option 2: rotation, Plus transformX and transformY

To rotate an object about its center, you can set transformX and transformY (and transformZ too), like this:

<s:Button id="btn" label="My Button"
    rotation="90"
    transformX="{btn.width * 0.5}"
    transformY="{btn2.height * 0.5}" />

Using MXML, I set rotation to 90°, plus transformX and transformY to half the width and height of the object (in this case, a button). By moving the rotation point from the top left to the center of the button, I get what I want: an object rotating about its center. [I had forgotten how this works...thanks go to Bindu for reminding me!]

Option 3: Matrix Rotation

Option #2 works because every component in Flex has a full affine transformation matrix behind it (as of Flash Player v9, I think, but only exposed to MXML in Flex 4). In MXML, when you set attributes like rotation, transformX, and transformY, you are just setting the underlying transformation matrix.

You can also set the matrix directly, like this:

var mat:Matrix = new Matrix();
mat.translate(-W/2, -H/2);
mat.rotate(Math.PI/2);
mat.translate(+W/2, +H/2);
mat.concat(myObj.transform.matrix);
myObj.transform.matrix = mat;

To get a rotation about the center of our object, we first translate it, then rotate, then translate it back. Note the concat() operation, which just “adds” the current matrix to our new rotation matrix, and thus preserves any previous transforms (maybe our object had scaleX or scaleY applied).

Option 4: Rotate Animation

Lastly, if we want to watch the rotation happen, we can use a Rotate animation, like this:

var rot:Rotate = new Rotate();
rot.angleBy = 90;
rot.duration = 1000;
rot.autoCenterTransform = true;
rot.target = myObj;
rot.play();

Here we just instantiate a new spark Rotate effect, set its various properties, and start it with a call to play(). The key property to force rotation about the center is autoCenterTransform, just set it to true.

Conclusion

When I need total control, I find myself doing the full matrix solution. Otherwise for anything simple, the MXML attributes are best.

Here’s an example project showing all options (view source enabled):

Files

• RotationTester (fxp download)

Alex Harui is the guru of turning a Flex 4 Spark List into a look-alike for the old Flex 3 component using skins and a custom ItemRenderer. Alex has used List + ItemRenderer to make a DataGrid, DateField, ColorPicker, Menu + MenuBar, and even an XML-based TreeList. Unfortunately, Alex’s TreeList assumes incoming XML, and I needed a TreeList that could display a simple object hierarchy (root node with children, and those children have children, etc.). Since I couldn’t find exactly what I wanted, I decided to build it myself.

Flattener

The key step to getting a hierarchy of objects to display as a list is: flatten the list, duh! Or at least flatten the part of the tree you wish to display. So, I built a simple adapter class that turns an object hierarchy into an ArrayList that can be given directly to a List‘s dataProvider.

Here’s the actual flattener, but with just the comments not the code:

public class MyObjFlattenedList extends ArrayList {
 
    //the root object
    private var _root:MyObj;
 
    //list of open nodes
    private var _openList:Array;
 
    public function MyObjFlattenedList(root:MyObj) {
        _root = root;
        _openList = [];
        reset();
        ...
    }
 
    public function reset(openList:Array = null):void {
        //init the flattened list, starting at root
        _openList = (openList == null ? [] : openList);
        var a:Array = [];
        addItemToList(_root, a);
        this.source = a;
    }
 
    private function addItemToList(obj:MyObj, a:Array):void {
        //recursively walk obj and all of its "open" children to build
        //a flattened list that is returned in array a
    }
 
    public function isItemOpen(obj:MyObj):Boolean {
        //true if obj has children and is "open"
    }
 
    public function openItem(obj:MyObj):void {
        //add all of obj's children (if any) to the list
    }
 
    public function closeItem(obj:MyObj):void {
        //remove all of obj's children (if any) from the list
    }
    ...
}

There’s really not much to it. When instantiated with a root object, the object hierarchy is walked recursively to build a flattened list of all the open nodes. Once the initial list is built, openItem() can be called to open a node, and add all its children to the list. Alternately, closeItem() can be called to close a node, and remove all its children from the list.

Design

I used some basic styling and skinning, but the ItemRenderer does the majority of the work. Here’s the abbreviated version of MyObjRenderer.mxml with all the boring stuff edited out:

<?xml version="1.0" encoding="utf-8"?>
<s:ItemRenderer
    xmlns:fx="http://ns.adobe.com/mxml/2009" 
    xmlns:s="library://ns.adobe.com/flex/spark"
    width="100%"
    autoDrawBackground="false">
 
    <fx:Script>
        <![CDATA[
            [Bindable] private var _obj:MyObj;
            [Bindable] private var _hasChildren:Boolean = false;
 
            private var _list:MyObjFlattenedList;
 
            override public function set data(val:Object):void {
                super.data = val;
 
                if (val != null) {
                    _obj = val as MyObj;
 
                    var ownerList:List = owner as List;
                    _list = ownerList.dataProvider as MyObjFlattenedList;
 
                    btn.selected = _list.isItemOpen(_obj);
                    _hasChildren = (_obj.children != null && _obj.children.length > 0);
                }
            }
 
            private function toggleHandler():void {
                if (btn.selected) {
                    _list.openItem(_obj);
                } else {
                    _list.closeItem(_obj);
                }
            }
        ]]>
    </fx:Script>
 
    <s:states>
        <s:State name="normal" />
        <s:State name="hovered" />
        <s:State name="selected" />
    </s:states>
 
    <s:Rect ...>
 
    <s:HGroup ...>
        <s:ToggleButton id="btn" click="toggleHandler()" visible="{_hasChildren}" ... />
 
        <s:Group id="dot" visible="{!_hasChildren}" ... />
 
        <s:Label ... />
    </s:HGroup>
</s:ItemRenderer>

Each rendered item has a background Rect and a Label. But most importantly, each row has either a ToggleButton (if the object has children) or some non-interactive visuals (if the object doesn’t have children it just gets a dot). The toggle button is the key interactive element used to open or close the node, everything else is part of the visual gravy added to make the list look good.

Focusing on the functional stuff, if you look in the script block, you’ll see two functions: a data() setter and a toggleHandler() to handle toggle button clicks. As expected, clicking the toggle button calls openItem() or closeItem() on the flattener adapter which adds or removes children from the flattened list, respectively. The setter mostly sets up the local variables, but it notably computes if the object has children or not, and also sets the initial state of the toggle button.

Conclusion

With just a little effort, we can have a nice usable Spark TreeList component that looks decent. More importantly, we have total control and can make the TreeList look like anything our designer can throw at us. As is always the case, the combo of List + ItemRenderer proves to be awesome. I tried to cover all the interesting pieces, but for the details, you’ll need to check out the source code.

Here’s the finished product (view source enabled):

Use it and enjoy.

Files

• ObjTreeList (fxp download)

Hamcrest was born in the Java world as the matcher framework in jMock. It was quickly extracted into its own framework and has become somewhat of a monster in the testing world. It’s now included directly in JUnit (since v4.4), and has been ported to many languages (OCHamcrest in Objective-C, Hamcrest-AS3 in Actionscript, PyHamcrest in Python, etc.). Additionally, the matcher concept is generally useful, and Hamcrest is used is lots of different places (my favorite is collection filtering with Hamcrest in LambdaJ).

When writing unit tests, OCHamcrest offers lots of advantages over the vanilla SenTest assertions. First, there’s a ton of matchers that really make life easy, especially when testing collections like NSArray. Second, OCHamcrest matchers are very readable in code, almost self-documenting. Lastly, OCHamcrest automatically provides excellent failure messages when actual is not equal to expected.

Matching Strings

Some string matching examples:

• is – match the complete string
• startsWith – match the beginning of a string
• endsWith – match the end of a string
• containsString – match part of the string
• equalTo – match the complete string
• equalToIgnoringCase – match the complete string but ignore case
• equalToIgnoringWhiteSpace – match the complete string but ignore extra whitespace (new line, tab, or double spaces)

NSString *s = @"FooBar";
 
assertThat(s, is(@"FooBar"));
 
assertThat(s, startsWith(@"Foo"));
assertThat(s, endsWith(@"Bar"));
assertThat(s, containsString(@"oo"));
assertThat(s, equalToIgnoringCase(@"foobar"));
 
assertThat(@" X \n  Y \t\t  Z \n", equalToIgnoringWhiteSpace(@"X Y Z"));

NOTE: Technically, is isn’t really a matcher, it’s a matcher decorator that implicity converts to the equalTo matcher. [thanks Jon!]

Combining Matchers

You can combine multiple matchers with:

• allOf – AND together all matchers
• anyOf – OR togehter all matches

NSString *s = @"FooBar";
 
assertThat(s, allOf(startsWith(@"Foo"), endsWith(@"Bar"), nil));
assertThat(s, anyOf(startsWith(@"Foo"), startsWith(@"Bar"), nil));
assertThat(s, anyOf(endsWith(@"Foo"), endsWith(@"Bar"), nil));

NOTE: The list of matchers must be nil terminated.

You can invert a matcher, or multiple matchers, with:

• isNot – negate the matcher

NSString *s = @"FooBar";
 
assertThat(s, isNot(@"foo"));
assertThat(s, isNot(endsWith(@"Baz")));
assertThat(s, isNot(allOf(startsWith(@"Baz"), endsWith(@"Baz"), nil)));
assertThat(s, isNot(anyOf(startsWith(@"Baz"), startsWith(@"Baz"), nil)));

Matching nil

You can match nil with:

• nilValue() – stands in for nil
• notNilValue() – stands in for !nil

NSObject *o = nil;
assertThat(o, nilValue());
 
NSString *s = @"FooBar";
assertThat(s, notNilValue());

Matching Classes

You can match an instance’s class with:

• instanceOf – match the class

NSString *s = @"FooBar";
assertThat(s, instanceOf([NSString class]));

Matching Numbers

One of the great pains of Objective-C is typing numbers from primitive types to objects and back again. OCHamcrest has a variety of matchers the help make life easy.

• assertThatInt – typed assert that expects an int (other types too: assertThatFloat, assertThatDouble, etc.)
• equalToInt – typed equals that takes an int (other types too: equalToFloat, equalToDouble, equalToBool, etc.)
• closeTo – match a number with a target number plus or minus a delta (both params are double)
• lessThan – match a number less than the given number (param is NSNumber), also lessThanOrEqualTo
• greaterThan – match a number greater than the given number (param is NSNumber), also greaterThanOrEqualTo

assertThatInt(5, equalToInt(5));
assertThatFloat(3.14, equalToFloat(3.14f));
assertThatBool( false, equalToBool(NO) );
 
NSNumber *i = [NSNumber numberWithInt:5];
assertThat(i, equalToInt(5));
assertThat(i, is([NSNumber numberWithInt:5]));
 
NSNumber *f = [NSNumber numberWithFloat:3.14f];
assertThat(f, equalToFloat(3.14f));
assertThat(f, is([NSNumber numberWithFloat:3.14f]));

The easiest cleanest approach is to use assertThatInt with equalToInt, the next best option is to use the vanilla assertThat with equalToInt, the most verbose option is to use NSNumber everywhere.

It’s easy to make rough number comparisons too:

NSNumber *f = [NSNumber numberWithFloat:3.14f];
assertThat(f, closeTo(3.0f, 0.25f));
 
assertThat(f, lessThan([NSNumber numberWithInt:4]));
assertThat(f, greaterThan([NSNumber numberWithInt:3]));

NOTE: It is a little weird, but closeTo takes double params, but everything else expects NSNumber params.

Numeric comparisons also work great on dates too:

NSDate *now = [NSDate date];
 
//now minus 1000 seconds
NSDate *beforeNow = [NSDate dateWithTimeIntervalSinceNow:-1000]; 
 
assertThat(now, greaterThan(beforeNow));

Matching Arrays

Easily the best part of OCHamcrest is its ability to match lists of objects. Array matchers are every powerful, but don’t forget to add the terminating nil to all lists.

• hasItem – match if given item appears in the list
• hasItems – match if all given items appear in the list (in any order)
• contains – match exactly the entire array
• containsInAnyOrder – match entire array, but in any order
• hasCountOf – match the size of the array
• empty – match an empty array

Here some basic array examples:

NSArray *a = [NSArray array];
 
assertThat(a, is(empty()));
assertThat(a, hasCountOf(0));

Here some hasItem examples:

NSArray *a = [NSArray arrayWithObjects:@"a", @"b", @"c", nil];
 
assertThat(a, hasItem(@"a"));
assertThat(a, isNot(hasItem(@"X")));
assertThat(a, hasItem(equalToIgnoringCase(@"A")));

The last matcher may look a little weird, but remember matchers expect a matcher as their input param, and only default to equalTo if none is given. Thus, the first matcher hasItem(@"a") can be rewritten as hasItem(equalTo(@"a")).

We repeat the above example, but this time using numbers in our NSArray. As you can see below, all the number matchers require us to explicitly use equalToInt everywhere:

NSArray *a = [NSArray arrayWithObjects:
    [NSNumber numberWithInt:2],
    [NSNumber numberWithInt:3],
    [NSNumber numberWithInt:5],
    nil];
 
assertThat(a, hasItem(equalToInt(2)));
assertThat(a, isNot(hasItem(equalToInt(13))));
 
assertThat(a, contains(equalToInt(2), equalToInt(3), equalToInt(5), nil));

Here are some more complex array matchers:

NSArray *a = [NSArray arrayWithObjects:@"a", @"b", @"c", nil];
 
assertThat(a, hasItems(@"b", @"a", nil));
 
assertThat(a, contains(@"a", @"b", @"c", nil));
assertThat(a, containsInAnyOrder(@"c", @"b", @"a", nil));
 
assertThat([a componentsJoinedByString:@","], is(@"a,b,c"));

And as I show in the last matcher, you can always dump to a string, and just match strings.

Matching Dictionaries

The dictionary matchers build on the array matchers:

• hasKey – match a key
• hasValue – match a value
• hasEntry – match a key-value pair
• hasEntries – match a list of k-v pairs

NSDictionary *d = [NSDictionary dictionaryWithObjectsAndKeys:
    @"valA", @"keyA", @"valB", @"keyB", @"valC", @"keyC", nil];
 
assertThat(d, hasCountOf(3));
assertThat(d, isNot(empty()));
 
assertThat(d, hasKey(@"keyA"));
assertThat(d, isNot(hasKey(@"keyX")));
 
assertThat(d, hasValue(@"valA"));
 
assertThat(d, hasEntry(@"keyA", @"valA"));
 
assertThat(d, hasEntries(@"keyA", @"valA", @"keyC", @"valC", nil));

Matcher Error Messages

When a matcher fails, you get a standardize error message of: Expected "foo", but was "bar". This default message is easy to modify by using the describedAs() matcher in place of the typical is() matcher.

NSString *s = @"bar";
 
assertThat(s, is(@"foo"));
//Expected "foo", but was "bar"
 
assertThat(s, describedAs(@"doh! this should be 'foo'", equalTo(@"foo"), nil));
//Expected doh! this should be 'foo', but was "bar"
 
assertThat(s, describedAs(@"doh! this should be foo, %0, %1", equalTo(@"foo"), @"baz", [NSNumber numberWithInt:42], nil));
//Expected doh! this should be foo, "baz", <42>, but was "bar"

NOTE: The argument list for describedAs() MUST end with nil or your tests will crash instantly with no useful error message.

Building a Custom Matcher

Writing your own custom matchers is relatively easy. Here’s an example of a matcher that matches the value of some property on an object:

#import <OCHamcrestIOS/OCHamcrestIOS.h>
#import <objc/objc-api.h>
 
@interface HasProperty : HCBaseMatcher {
    NSString *property;
    id<HCMatcher> valueMatcher;
}
 
+ (id) hasProperty:(NSString *)aProperty value:(id<HCMatcher>)aValueMatcher;
- (id) initWithProperty:(NSString *)aProperty value:(id<HCMatcher>)aValueMatcher;
 
@end
 
OBJC_EXPORT id<HCMatcher> hasProperty(NSString *property, id valueMatcher);

We extends HCBaseMatcher with our custom HasProperty class. We store the name of the property and a value matcher.

And the implementation:

#import "HasProperty.h"
#import <OCHamcrestIOS/HCDescription.h>
#import <OCHamcrestIOS/HCWrapInMatcher.h>
 
@implementation HasProperty
 
+ (id) hasProperty:(NSString *)aProperty value:(id<HCMatcher>)aValueMatcher {
    return [[[self alloc] initWithProperty:aProperty value:aValueMatcher] autorelease];
}
 
- (id) initWithProperty:(NSString *)aProperty value:(id<HCMatcher>)aValueMatcher {
    self = [super init];
    if (self != nil) {
        property = [aProperty copy];
        valueMatcher = [aValueMatcher retain];
    }
    return self;
}
 
- (void) dealloc {
    [property release];
    [valueMatcher release];
    [super dealloc];
}
 
- (BOOL)matches:(id)item {
    SEL propertyGetter = NSSelectorFromString(property);
 
    if ([item respondsToSelector:propertyGetter]) {
        if ([valueMatcher matches:[item performSelector:propertyGetter]])
            return YES;
    }
    return NO;
}
 
- (void) describeTo:(id<HCDescription>)description {
    [[[description appendText:[NSString stringWithFormat:@"an object with a property named '%@' with a value of {", property]]
        appendDescriptionOf:valueMatcher]
        appendText:@"}"];
}
@end
 
OBJC_EXPORT id<HCMatcher> hasProperty(NSString *property, id valueMatcher) {
    return [HasProperty hasProperty:property value:HCWrapInMatcher(valueMatcher)];
}

When we write a custom matcher, we must implement two methods, matches: to do the matching and describeTo: to provide feedback in case of match failure. In the above code, we first construct a selector from the given property name, then call the selector to get the actual property value, and finally check if actual matches the expected value (given by the valueMatcher).

Usage looks like this:

Person *p = [Person personWithFirstName:@"Joe" andLastname:@"Doe"];
 
assertThat(p, hasProperty(@"firstName", @"Joe"));

Or more importantly, we can now use our custom hasProperty matcher to match an arrays of objects:

NSArray *a = [NSArray arrayWithObjects:
    [Person personWithFirstName:@"Joe" andLastname:@"Doe"],
    [Person personWithFirstName:@"Joe" andLastname:@"Smith"],
    [Person personWithFirstName:@"Jane" andLastname:@"Allen"],
    nil];
 
assertThat(a, contains(
    hasProperty(@"firstName", @"Joe"),
    hasProperty(@"firstName", @"Joe"),
    hasProperty(@"firstName", @"Jane"),
    nil));

That’s it. Go forth and match.

UPDATE: I put the above hasProperty matcher into a pull request, and Jon Reid accepted it into OCHamcrest v1.6. He even wrote a nice post about it. Get the lastest OCHamcrest from github.

Links

• OCHamcrest – github repo
• OCHamcrest Docs – docs
• Hamcrest – on Java

The Good

Using square brackets to call methods is a little wack, but you’ll get over that in about 20 minutes. Honestly, the syntax is a little bumpy for a day or two, tops…after that, there’s a lot to like about Objective-C.

Dynamic

Objective-C is a very dynamic language, not quite at the level of Ruby, but it’s pretty dang close. You’ve got the id data type when you need dynamic typing, but you can also use static typing for some compiler love. You’ve got Categories for extending classes. And you’ve got full-on runtime meta-programming that allows you to create new classes at runtime, create new methods on existing classes at runtime, and swizzle methods at runtime. Objective-C’s also got message forwarding (just a more verbose method_missing if you know Ruby) for handling unknown method calls at runtime.

Not to shabby. With the exception of the id data type and using @selector everywhere, I seldom use the dynamic features. Since dynamism is completely unobtrusive in Objective-C, I don’t have to worry about it, but I know it’s there if I need it. Basically, it’s a big warm fuzzy.

Blocks

Closures are pretty sweet in any language, but the Objective-C implementation, called Blocks, is better than most. The addition of Blocks means that functions are now first class objects in the runtime, meaning they can be created, saved, executed, copied, or passed to other functions at runtime. Blocks are directly supported by the base Objective-C classes and in some iOS APIs too (examples include NSArray‘s enumerateObjectsUsingBlock: or UIView‘s animateWithDuration:animations:).

But the coolest thing you can do with Blocks is to use them to create chucks of work that can be executed in parallel. The hard part is breaking a job out into independent chunks of work, but once you have that implementation is trivial in Objective-C. You just use NSArray‘s enumerateObjectsWithOptions:usingBlock: with the NSEnumerationConcurrent option to do work on the chunks concurrently, like this:

[myArray enumerateObjectsWithOptions:NSEnumerationConcurrent
                          usingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    //do chunk of work on obj
}];

And if you really need to some concurrent kung-fu, Objective-C provides NSOperationQueue along with Grand Central Dispatch to really kick some ass. If you can forgive the Charlie Sheen reference, I like to think of Blocks as the tiger blood of concurrent programming. Winners use Blocks.

Good references: Drew McCormack’s 10 Uses for Blocks; Make Ash’s part 1 and part 2; Mike Clark’s basic blocks and advanced blocks.

UIAutomation

UIAutomation is not much to look at. And it actually starts looking pretty bad as a functional testing tool when compared to Selenium or FlexMonkey or FoneMonkey. But it’s there, it works, it’s full-baked, and it appears to be Apple’s way forward. Automation is so powerful, particularly on big apps developed by big teams. UIAutomation’s integration with Instruments is it’s achilles heel right now, so hopefully Apple brings out an update that is happily command-line-runnable soon. Until then, it’s still super awesome to have an automation tool.

The Bad

There’s a lot of not-good-yet stuff in Objective-C development. For the most part, I’m optimistic that much of stuff will get fixed over time.

The Community

With the exception of Stack Overflow (and that’s a major exception because it’s just awesome), the Objective-C community is just getting started, for the obvious reason that it’s so new on the radar. The number of books, bloggers, libraries, frameworks, et cetera is just not there yet. From my own personal experience, I find it very analogous to the Ruby community circa Rails 1.0. A few, well known, super dev bloggers, a few good books, a few widely used frameworks (Three20, cocos2d), and a lot of eager wannabes (like me then with ruby, and me now with iOS) [Note to self: Am I just a career wannabe? Discuss.] But look at ruby now…the community got so big that they are now experiencing contraction (the Rails/Merb merge is the big example).

I’m always googling while writing code, but with Objective-C I often find myself coming up empty. A lot of first time never-been-done-before stuff is going on in Objective-C and iOS, which is certainly exciting, but not without its challenges to day-to-day development. I don’t doubt things will improve in the future, but right now I find the community lacking.

Tools

Much like the community, the tool chain is just getting started. There’s a ton of Makefiles out there, along with piles of bash scripts. And I swear people are still jumping to the command line in gdb. Of course, this is all the C/C++ heritage, but come on people! Who uses this stuff and actually likes it? It’s not like Ant and Maven were forged by the gods, but Makefiles? Save me.

And what’s up with Other Linker Flags? This whole thing to totally idiotic. Why can’t we invent some new packaging format that knows it must be added with -lstdc++ or -ObjC? Super lame.

I’ve been getting pretty dirty with Rake, Ivy, and Sonatype’s Nexus to bring some serenity to the situation. Definitely a work in progress, but it’s getting there.

The Ugly

The ugly parts are rather unfortunate, especially given the beauty of Apple’s hardware. It’s also a little hard for non-programmers to see, because the user-facing bits of the software can be made so beautiful too. But I would certainly argue that the beauty of the UI is done despite of some evil ugly warts in the code. Maybe I’m being a little too Zen, or maybe I’m a hopeless romantic, or maybe I’m just being naive, but it sure would be great if inner beauty at the code level eventually lead to beauty at the surface.

Memory Management

Everyone loves to hate on Objective-C’s lack of garbage collection on iOS. I’m on the bandwagon on this one too, because memory management just plain sucks. The constant dance of retain, release, and autorelease is unrelenting, and so hateful! For an alternate data point, with the release of Gingerbread, Android has a new concurrent garbage collector. Come on Apple, give us some love.

Writing leak free code on the first pass is basically impossible, especially on a big app. So now I’ve had to expand my toolbox to include tools like Clang and Leaks and UIAutomation to find and fix all my memory bugs. It’s just ugly plain and simple.

Xcode

By far the ugliest part of Objective-C is the Xcode IDE. By far! I’ve used the question, "Tell me about some of the warts of iOS development?", a couple of times in recent interviews. It turns out to be a great differentiator between professional developers that are familiar with team development and professional tools and people that know how to code. All the candidates I’ve asked can easily point to memory management as one of the ugly parts, but almost no one says the Xcode.

If you’ve ever used a real IDE (Eclipse, IntelliJ, Visual Studio), then you are probably familiar with various code-level helpers like generate getters/setters, rename class, automatic code formatting on save, just to give a few examples. Xcode doesn’t generate getters or setters from ivars. Nor does it do class rename, only file rename, how pathetic is that? It doesn’t do any intelligent code formatting either on save or otherwise. And these are just my code-level gripes…

You are also probably familiar with the various development tooling integrations that put the I in Integrated Development Environment. Things like using source control, viewing graphical diffs, running unit tests, running scripts, debugging with variable watches, writing tickets, submitting bug reports, doing code reviews, and more. Nope, Xcode doesn’t do any of those things either.

In the end, I give Xcode a "syntax highlighter plus" rating, which puts it just above vanilla Vim but below a super tricked out Vim setup.

Conclusion

I’m an iOS developer by choice, but just because I’m splashing around in the mud like a happy pig right now doesn’t mean I like being dirty all the time. [For more about "the mud", read my rablings here.] The ugly bits do have one positive effect: my value (and hence my salary) are improved. By setting the bar high, either intentionally or unintentionally, Apple is effectively keeping the riffraff out.

Hopefully, GC will arrive once all the iOS hardware gets multiple cores. Or maybe ARC might be decent. And JetBrains CIDR (Objective-C IDE from the makers of IntelliJ) will turn out to be awesome. Onward and upward.

Update 2013-04-17: Yes, ARC is pretty sweet. Yes, JetBrains AppCode is the real deal. And yes, Xcode is still an ugly wart on iOS development.

It’s very easy to go completely nibless (and a little stylish in my opinion) and eschew Interface Builder altogether. For all you Flexers out there, this is the moral equivalent of eschewing Flash Builder’s Design View. Honestly, who really uses Design View to build an app beside Adobe evangelists doing 30 minute demos?

A Completely Nibless App

Here’s how you can build a completely nibless app in five simple steps. First, you’ll want to start with a fresh Window-based Application in Xcode. Then follow these steps:

1. Remove MainWindow from your app’s Info.plist
2. Delete all .xib files
3. Edit AppDelegate.h remove all the IBOutlet keywords
4. Edit main.m, import AppDelegate.h, and set the UIApplicationMain‘s 4^th parameter to @"AppDelegate"
5. Edit AppDelegate.m to instantiate the main UIWindow in code

Here’s what main.m should look like after you’ve completed Step 4:

#import <UIKit/UIKit.h>
#import "AppDelegate.h"
 
int main(int argc, char *argv[]) {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate");
    [pool release];
    return retVal;
}

And here’s what the application:didFinishLaunchingWithOptions: method in AppDelegate.m should look like:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] applicationFrame]];
    [self.window makeKeyAndVisible];
    return YES;
}

Now you can go about you view-creation business in a nibless fashion. I’d probably create a UIViewController subclass as my root view, construct my UI in loadView, and wire everything together in the AppDelegate.

Nibless App Xcode Template

But don’t do any of that stuff! Instead you can just use this handy-dandy Xcode template to do all the work. On of the very few things Xcode gets right is its template system. It is very easy to create a custom template for Xcode (see here and here for the basics).

Install the NiblessApp custom template in Xcode:

1. Download nibless_app_template.tgz
2. cd ~/Library/Application Support/Developer/Shared/Xcode/Project Templates/ (you might need to create the Project Templates folder if it doesn’t already exist)
3. tar xzvf /path/to/nibless_app_template.tgz
4. Quit Xcode and restart

Files

• nibless_app_template.tgz – a completely nibless iPhone custom template for Xcode

Stack

A very basic Stack implementation with just push, pop, and peek.

@interface NSMutableArray (Stack)
 
- (void) push: (id)item;
- (id) pop;
- (id) peek;
 
@end

@implementation NSMutableArray (Stack)
 
- (void) push: (id)item {
    [self addObject:item];
}
 
- (id) pop {
    id item = nil;
    if ([self count] != 0) {
        item = [[[self lastObject] retain] autorelease];
        [self removeLastObject];
    }
    return item;
}
 
- (id) peek {
    id item = nil;
    if ([self count] != 0) {
        item = [[[self lastObject] retain] autorelease];
    }
    return item;
}
 
@end

No real magic above, just Objective-C’s annoying retain & autorelease dance to get an item out of NSMutableArray correctly.

Queue

Much like Stack above, here’s a very basic Queue implementation with just enqueue, dequeue, and peek.

@interface NSMutableArray (Queue)
 
- (void) enqueue: (id)item;
- (id) dequeue;
- (id) peek;
 
@end

@implementation NSMutableArray (Queue)
 
- (void) enqueue: (id)item {
    [self addObject:item];
}
 
- (id) dequeue {
    id item = nil;
    if ([self count] != 0) {
        item = [[[self objectAtIndex:0] retain] autorelease];
        [self removeObjectAtIndex:0];
    }
    return item;
}
 
- (id) peek {
    id item = nil;
    if ([self count] != 0) {
        item = [[[self objectAtIndex:0] retain] autorelease];
    }
    return item;
}
 
@end

Note that we need the same retain & autorelease dance as above.

Files

• stack.tgz
• queue.tgz

UX 101

It is impossible to develop an RIA without some basic understanding of interaction design. As they say in one of my favorite movies, "Many men have tried. They tried and failed? They tried and died." So a short UX primer on drag-and-drop goes like this…

Users are typically familiar with drag-and-drop for two basic actions: moving-stuff-around and putting-stuff-into. For example, we move windows around the desktop or move songs around in a playlist or move icons around in a folder. Also, we put stuff into the trash or put a picture into an album or put an attachment into an email. At a fundmental level, users have an understanding of these actions because they mimic the physical world. Performing these actions via a touch interface (rather than a mouse) is even better, but that’s a story for another day.

Given these two basic actions, I’m going to design a sample app that exercises them both. This is what I came up with:

Our sample app has three drag actions. In #1, you can drag to put items from the palette into the list. In #2a and #2b, you can drag items from the list into a target box (that preforms some action). In #3, you can drag items around inside the list to reorder them. I’ll break them down one by one.

#1 — Drag List Item to Another List

Dragging from one list and dropping on another is super easy in Flex 4. Here’s a snippet:

<s:List id="sourceList" dragEnabled="true">
    <s:ArrayList source="['A','B','C','D']" />
</s:List>
 
<s:List id="targetList" dropEnabled="true">
    <s:ArrayList></s:ArrayList>
</s:List>

We set dragEnable=true on the source list and dropEnable=true on the target list. For bi-directional drag-and-drop, just set both attributes true for both lists. In a feat of awesomeness, Flex 4 does everything else for you. You don’t need to listen for any events or write any handlers. And you even get some nice eye candy for free, because the target list glows when you drag an item over it.

Trick 1 — When the drop target is an empty list, you must given it an empty dataProvider. In the above example, I just use an empty ArrayList pair of tags in MXML, but I could just as easily say dataProvider="{new ArrayList()}", or even do everything in Actionscript.

Trick 2 — The source list accepts a drop—if and only if—the item being dropped is compatible with the items in the target dataProvider. For example, you can not drop a Foo object on a list of Bar objects. Setting the target list to have an empty dataProvider (à la Trick 1), accepts anything.

#2 — Drag List Item to UIComponent Target

Again, to use a list as the drag source, we just set dragEnable=true. But this time the target is some non-List UIComponent, so we need to do what we always do to enable drop functionality on a component—namely, attach handlers to the dragEnter and dragDrop events. Here’s a snippet:

<s:List id="sourceList" dragEnabled="true">
    <s:ArrayList source="['A','B','C','D']" />
</s:List>
 
<s:Panel id="targetA" 
         dragEnter="dragEnterHandler(event)"
         dragDrop="dragDropHandler(event)">
</s:Panel>

And here are the handlers:

private function dragEnterHandler(e:DragEvent):void {
    DragManager.acceptDragDrop(e.currentTarget as IUIComponent);
}
private function dragDropHandler(e:DragEvent):void {
    //do something with dropped item here
}

As always, we accept the drop in the dragEnter handler via the static acceptDragDrop() method on the DragManager. And once the object is dropped, we can do whatever we want with it in the dragDrop handler.

#3 — Drag List Item to Reorder Items

Finally, we want to be able to reorder the items in a list. Again, the spark List does all the work for us. We just set both dragEnable=true and dropEnable=true on the list we want to reorder. We must also set the magical dragMoveEnabled=true, which has numerous ramifications. Here is the snippet:

<s:List id="reorderList"
        dragEnabled="true"
        dropEnabled="true"
        dragMoveEnabled="true">
    <s:ArrayList source="['A','B','C','D']" />
</s:List>

The code is trivial, but what’s going on with dragMoveEnabled=true? Well, dragMoveEnable, which defaults to false, controls whether or not an object is moved (aka removed from the source and added to the target) or copied (aka added to the target leaving the source untouched). So to reorder the items in a list, we need the move behavior, thus we set dragMoveEnabled=true.

Trick 3 — If the source list is dragMoveEnabled=true and the target is a non-List UIComponent, you will see some seemingly odd behavior. Every time to drop an object on your component, it will be deleted from the source list. This is because you are only seeing the first half of the move (the item is removed from the source), and not the second half (the item is added to the target) because the target is not a List.

Trick 4 — As an alternative to dragMoveEnabled=true, you can make a call to DragManager.showFeedback(DragManager.MOVE) in the dragEnter handler to control whether or not an object is moved or copied. Do NOT use both showFeedback and dragMoveEnabled at the same time.

Eye candy

What’s a Flex app without eye candy? But with drag-and-drop, I’d say most of the eye candy is more of a UX necessity than anything else. It’s used to indicate potential drop targets, or highlight a target that is ready to receive a drop, etc.

Glow On Enter

With list to list drag-and-drop, we get a glow on the target list for free, which tells the user that the target list is ready to receive the drop. But when dragging to a non-List UIComponent, we need to add the glow ourselves:

private function dragEnterHandler(e:DragEvent):void {
    myGlow.alpha = 1;
    DragManager.acceptDragDrop(e.currentTarget as IUIComponent);
}
private function dragExitHandler(e:DragEvent):void {
    myGlow.alpha = 0;
}
private function dragDropHandler(e:DragEvent):void {
    myGlow.alpha = 0;
    //do something with dropped item here
}

In the dragEnter handler, we turn the glow on, and we turn the glow off on either a dragExit or dragDrop event. And we need to add a simple GlowFilter to the target component:

<s:Panel id="targetA" 
         dragEnter="dragEnterHandler(event)"
         dragDrop="dragDropHandler(event)">
    <s:filters>
        <s:GlowFilter id="myGlow" blurX="16" blurY="16"
                color="#3399ff" alpha="0" />
    </s:filters>
</s:Panel>

No magic, just use MXML to add a GlowFilter to the target component, which in this snippet is a spark Panel component.

Custom Drag Proxy

Customizing the drag proxy (what an item looks like while dragging) is fun, but I covered that previously, so there’s no need to revisit it here. On the other hand, I haven’t discussed how to customizing an item dragged from a spark List yet. It is not only fun, but also quite a bit easier.

Flex 4 makes is super easy to create a custom drag proxy by simply adding a magic dragging state to the List‘s itemRenderer. For this snippet, imagine I have a trivial ItemRenderer that just shows a centered label with black text, but when it’s being dragged I want to turn the text red:

<?xml version="1.0" encoding="utf-8"?>
<s:ItemRenderer ...>
    <s:states>
        <s:State name="normal" />
        <s:State name="hovered" />
        <s:State name="selected" />
        <s:State name="dragging"/>
    </s:states>
 
    <s:Label left="0" right="0" top="0" bottom="0"
            text="{data.label}" textAlign="center" verticalAlign="middle"
            color="#000000"
            color.hovered="#0000ff"
            color.dragging="#ff0000" />
</s:ItemRenderer>

As you can see from the above code, customizing the drag indicator is a huge nothing. Just add the magic dragging state to the list of states, and use Flex 4′s inline state syntax to do whatever you want. In this snippet, we set color.dragging="#ff0000" to turn the text red when its being dragged. The sample app below does quite a few more things to customize the dragged item, so check out that code too.

Custom Drop Indicator

When a user drags an item over a target spark List, a line appears to show the user where the item will be inserted. This line is known as the drop indicator. To change things up, we will make a custom drop indicator that is a dashed line.

Trick 5 — Alas, Flex 4 does not have direct support for dashed strokes, so we need to fake it. The easy way to make a dashed line in Flex 4 is to use BitmapFill. First, we create an image that is a tileable pattern of squares. Then, we make a Rect and set its fill to BitmapFill and fillMode="repeat".

The dropIndicator component is found in the fx:Declarations block of the default spark ListSkin, so we must create a custom List skin with our custom dropIndicator component. Here’s a snippet from our custom skin’s fx:Declarations block:

<fx:Declarations>
    <fx:Component id="dropIndicator">
        <s:Group minWidth="1" minHeight="1" maxWidth="1" maxHeight="1">
            <s:Rect left="0" right="0" top="0" bottom="0">
                <s:fill>
                    <s:BitmapFill source="@Embed('dash.png')"
                            fillMode="repeat" />
                </s:fill>
            </s:Rect>
        </s:Group>
    </fx:Component>
</fx:Declarations>

As described above, we have a Rect with a BitmapFill, and an image dash.png that is a tileable pattern of squares. But the real magic is in the Group wrapper, by setting all of minWidth, maxWidth, minHeight, maxHeight to 1px we ensure we get a one pixel line as our drop indicator independent of the layout applied to our List. This is because HorizontalLayout ignore min and max height, and VerticalLayout ignore min and max width. So if we take a 1px view of our pattern of squares, we see dashes.

Conclusion

Here’s the complete drag-and-drop sample (view source enabled):

Hopefully, I covered the full spectrum of drag-and-drop functionality that the average Flex app (or even above average) is ever likely to need. If you want more, check out the links below, or just leave me a comment.

Useful Links

• My first post on drag-and-drop in Flex 4 covered a lot of drag proxy stuff.
• Flex After Dark has a solid drag-and-drop tutorial that is definitely worth reading if you are implementing drag-and-drop functionality in your app.
• Evtim, aka The Godfather, as I like to call him, has a cool post on customizing both the drag indicator and the drop indicator of the spark List component.

Files

• DragDropColors (download)

Suddenly, I realized that I really needed to test some private methods. So, a quick google for “testing private methods java” brings up a good article by Bill Venners. He lists all possible options to test private methods:

1. Don’t test private methods
2. Give the methods package access
3. Use a nested test class
4. Use reflection

Basically, the only real one is #4, use reflection. Bill didn’t give me the exact code I needed, so lots of googling later I realized that the world is filled with opinionated people (like me), and boy do they love to talk about #1. I just wanted some code, not a lecture, so I had to write my own code. Here is that code for anyone else that just wants to test private methods.

Imagine you have a class MyClass and it has a private method, myMethod(). Sorta like this:

public class MyClass {
    private String myMethod(String s) {
        return s;
    }
}

Then you could use reflection to invoke the method like this:

MyClass myClass = new MyClass();
Method method = MyClass.class.getDeclaredMethod("myMethod", String.class);
method.setAccessible(true);
String output = (String) method.invoke(myClass, "some input");

The real magic is setAccessible(true) which allows the private method to be called outside the class. And shazam, I can now test all my private methods. I was really hoping JUnit 4 would provide some additional facilities specifically for testing private methods, but not luck.

A Better Example

Here’s a more complete example. Suppose we have a NovelWriter class that in a feat of API cleanliness only exposes the writeNovel() method. It happens to have a few private utility methods that we’d like to test:

public class NovelWriter {
    public String writeNovel() {
        //...the magic goes here...
        return null;
    }
 
    private String shout(String s) {
        return s.toUpperCase().replaceAll("\\.", "!");
    }
 
    private List<Integer> countLetters(List<String> words) {
        List<Integer> out = new ArrayList<Integer>();
        for (String word : words) {
            out.add( word.replaceAll("[^A-Za-z]+","").length() );
        }
        return out;
    }
}

I won’t get into all the details, but it seems easy to imagine a clean API that has private helper methods. Furthermore, it seems very logical to me to want to bring all methods, both public and private, so I can be sure they are being exercised to the fullest.

Our JUnit 4 + Hamcrest test class:

public class NovelWriterTest {
    public static NovelWriter novelWriter;
 
    @BeforeClass
    public static void beforeClass() {
        novelWriter = new NovelWriter();
    }
 
    @Test
    public void privateShout() throws NoSuchMethodException,
            InvocationTargetException, IllegalAccessException {
 
        String input = "This is magic.";
 
        Method method = NovelWriter.class.getDeclaredMethod("shout", String.class);
        method.setAccessible(true);
        String output = (String) method.invoke(novelWriter, input);
 
        assertThat(output, notNullValue());
        assertThat(output, is("THIS IS MAGIC!"));
    }
 
    @Test
    @SuppressWarnings("unchecked")
    public void privateCountLetters() throws NoSuchMethodException,
            InvocationTargetException, IllegalAccessException {
 
        List<String> input = Arrays.asList("Foo", "Foobar123", "Foo Bar Baz");
 
        Method method = NovelWriter.class.getDeclaredMethod("countLetters", List.class);
        method.setAccessible(true);
        List<Integer> output = (List<Integer>) method.invoke(novelWriter, input);
 
        assertThat(output, notNullValue());
        assertThat(output.size(), is(3));
        assertThat(output, hasItems(3, 6, 9));
    }
}

The nice thing about using the Reflection API like this is that it really doesn’t get too messy. I’m not inspecting anything at runtime, because I know exactly the return type and the types of all the parameters. I’m just invoking the method with known inputs, followed by a simple cast on the output type. And as you can see in the second test above, privateCountLetters(), it’s not a problem to use generics because we’re not doing any inspection only invocation.

Happy testing.

Files

• novel.tgz – download the complete Eclipse project