blog.md

Traditionally, in order to test both Android and iOS apps, we need to:

1. Create a test case document.
2. Translate the test document to automation scripts for Android and iOS.

As a result, we need to maintain 1 document and 2 scripts for each user story. But now, there is a less painful way. All we need is to create a Cucumber test for each user story like the follow:

Feature: Rating a stand
  Scenario: Find and rate a stand from the list
    Given I am on the List
    Then I should see a "rating" button
    And I should not see "Dixie Burger & Gumbo Soup"
    And take picture

    Then I touch the "rating" button
    And I should see "Dixie Burger & Gumbo Soup"
    And take picture

    When I touch "Dixie Burger & Gumbo Soup"
    Then I should see details for "Dixie Burger & Gumbo Soup"

    When I touch the "rate_it" button
    Then I should see the rating panel

    Then I touch "star5"
    And I touch "rate"
    And take picture

And the script can drive both Android & iOS apps. Since the test script is more readable then Robotium or UI Automation scripts, so the PO or tester can understand and modify it by themselves. We create and maintain only 1 document instead of 3.

Overall, Calabash is a more cost effective tool to express executable specification on Android and iOS platform.

dojo.md

Introducing coding dojo to a new group could be challenging. I facilitated quite a few dojo sessions, here are the rule of thumbs:

• We need at least 90 minutes to 2 hours
• If the audience haven't tried test driven design before, we need to give them brief introduction to:
• red-green-refactor concept
• 2 roles of pair programming: driver and navigator
• Then we can introduce the dojo procedure
• Ask a participant to start pairing with you
• Each pair work on 1 to 2 red-green-refactor cycles
• Some participant might start writing production code before reaching red bar, or start refactoring in red bar, we need to remind him or her
• Some pair might go stuck for a minute or two, usually it's a good idea to move to next pair
• The group might or might not finish the kata within time frame (about 50/50) especially the first time

Facilitated or participating in a coding dojo could be a challenging yet fun and rewarding experience if we do it the right way.

modern-ios.md

iOS is great app development platform, yet its UI programming model is so 1990s, the UI library is not so productive comparing to the html CSS model. After iOS5, UIAppearance did improves such an outdated model, it allows you to modularize UI themes like the follow code:

[[UIBarButtonItem appearanceWhenContainedIn:[UINavigationBar class], nil]
       setTintColor:myNavBarColor];
[[UIBarButtonItem appearanceWhenContainedIn:[UINavigationBar class], [UIPopoverController class], nil]
        setTintColor:myPopoverNavBarColor];
[[UIBarButtonItem appearanceWhenContainedIn:[UIToolbar class], nil]
        setTintColor:myToolbarColor];
[[UIBarButtonItem appearanceWhenContainedIn:[UIToolbar class], [UIPopoverController class], nil]
        setTintColor:myPopoverToolbarColor];

But I would say why stop there? Why don't we use CSS to stylize our iOS apps? And Pixate took a bold step towards that direction! You no longer need to use Objective-C code to set the themes:

#top-slider max-track {
  background-color: rgba(192, 192, 192, 0.5);
  background-size: 10px 10px;
  background-inset: 0px 5px;
  border-radius: 3px;
}
 
navigation-bar {
    color: white;
    background-color: #288de3;
}
 
tab-bar {
    color: #288de3;
    selected-color: white;
    background-color: #288de3;
}
 
tab-bar-item {
    color: white;
    font-family: "Open Sans";
    font-weight: semibold;
    font-size: 12;
}

Want to support both iPhone and iPad? No problem, use the @media rule:

/* Rule sets apply only when the device is in portrait orientation */
@media (orientation:portrait) { }

/* Rule sets apply if the device's height (ignores orientation)
 is at least 1000 pixels and if the device has a retina display. */
@media (min-device-height:1000px) and (scale:2) { }

/* Apply rules to iPad Mini in landscape mode. */ 
@media (orientation:landscape) and (device:ipad-mini) { }

Imagine how many lines of code can be reduced by using such a great library! How about readability and modularization?

It's unlikely that we are going to reinvent iOS programming, but I believe by using the correct programming model, we can reduce the code size of a iOS app by the factor of 10.

modern-objc.md

Objective-C was quite verbose and lack of visual clue, however after Clang 3.5, there are quite a few improvements, these new language features allow us to write more clean code:

The "new" method

[Foo new]

is better than

[[Foo alloc] init]

if you don't need to use custom init methods.

Object Subscripting

array[i]
dictionary[key]

are better then

[array objectAtIndex:i]
[dictionary objectForKey:key]

since they has more visual clues.

Primitive Literals

 NSNumber *fortyTwo = @42; 

is bettern then

 [NSNumber numberWithInt:42]

since the syntax is consistent across int string char bool and enum types.

Container Literals

NSArray *array = @[ @"Hello", NSApp, @(i) ];
NSDictionary *dictionary = @{
    @"name" : NSUserName(),
    @"date" : [NSDate date],
    @"processInfo" : [NSProcessInfo processInfo]
};

Are better then the good old constructors.

By using these new language features, we would experience less cognitive load during programming.