Wednesday, December 30, 2009

Announcing People?

Able Pear is happy to announce that our latest application, People?, is now available in the iTunes App Store.

People? is a game of questions and answers. Think of a person and People? tries to guess him or her.

Answer simple yes/no questions like "Is the person male?" or "Is he a US President?" When People? thinks it knows the answer it will guess the person: "Is it Barack Obama?"

When People? makes a wrong guess you can teach it the new person and add a new question to ask.

People? is great game for anyone age 8 and up who loves history and famous people.

Click here to see our complete list of apps.

Friday, December 18, 2009

iPhone Friday - December 18, 2009

Hello all and happy Friday!  We've been busy here at Able Pear Software and we have some exciting news in the wings, waiting to be released to the (hopefully washed) masses.  Today's iPhone and iPod touch wallpaper is from an upcoming game (and yes, there's only the one graphic).  Enjoy!


Tuesday, December 15, 2009

Objective-C Tuesdays: global variables

Last time we finished up our series on looping with a look at common uses for goto. Today we're starting a new series examining variables in Objective-C. Our first topic in the series is global variables.

Any variable declared outside of a function or method, class @interface or struct declaration is a global variable:
int count1; // global

int main(int argc, char *argv[]) {
  int count2; // local to main()
  ...
}
Initialization: By default, global variables are initialized to zero. For regular pointer types (including regular C strings) this means NULL is the default value; for Objective-C object pointers, it's nil by default. (This is different than local variables, which don't have a guaranteed initial value and thus should always be explicitly initialized.)

A global variable can be assigned an initial value when defined, but there's a tricky restriction: the initial value must be something the compiler can calculate at compile time. In general, this means you can only use literal values like numbers, characters and string literals, and you can only use basic numeric operators. Here are some examples of global variables with legal initial values:
int count; // defaults to 0
int daysPerYear = 365;
int secondsPerDay = 24 * 60 * 60;
Unfortunately you can't call functions or methods or use other global variables when assigning initial values. Here are some examples of illegal initial values for global variables:
// WARNING: WON'T COMPILE

// ERROR: function call not allowed
size_t titleLength = strlen("Objective-C Tuesdays");

// ERROR:  method call not allowed
NSUInteger subtitleLength = [@"global variables" length];

// ERROR:  calculation uses other global variables
unsigned long totalLength = titleLength + subtitleLength;
This restriction generally means that global Objective-C object types can't be initialized when they're declared:
// WARNING: WON'T COMPILE
NSArray *array = [[NSArray alloc] initWithObjects:@"one", @"two", nil];
There is one exception: NSString global variables can be initialized with Objective-C string literals (those special @ strings):
NSString *title = @"Objective-C Tuesdays";
If you need to do some complex initialization on your global variables, your only choice is to do it explicitly when your program starts. There are a few common places to do this sort of work:
  • at the start of main()
  • in your application delegate's -init method
  • in your application delegate's -applicationDidFinishLaunching: method
  • in the +initialize method of one of your classes
If the global variable is closely associated with a particular class, the +initialize method for that class is a good way to keep related code grouped together. Otherwise, -applicationDidFinishLaunching: is commonly used in Cocoa-touch programs while the start of main() is the traditional place in C programs.

Next time, we'll look at accessing global variables from multiple .m and .c files.

Objective-C Tuesdays: looping in Objective-C

Last week we wrapped up our look at the different ways to construct loops in Objective-C. Here's a quick overview of the posts.

There are four looping statements in Objective-C:
The for loop is the most flexible; we looked at some for loop idioms.

We examined the two loop flow modifiers:
Finally we wrapped up with a look at goto and examined common uses of goto.

Today, we start a new topic: variables.

Friday, December 11, 2009

iPhone Friday - December 11, 2009

Hello and happy Friday.  Today's collection of iPhone and iPod touch wallpapers were inspired from a friend (and you know who you are) asking me if I could do some that were a little lighter and seasonal.  So the following four images are what I came up with I hope that you all enjoy them.  Cheers!








Tuesday, December 8, 2009

Objective-C Tuesdays: common uses for goto

Last time we looked at the goto statement. Today we will look at the two common uses for goto: flow control in nested loops and organizing error handing code.

Flow control: As we saw in previous weeks, the break and continue statements are used to modify the flow of execution in a loop. Both break and continue affect only the innermost enclosing loop. Sometimes you need to break out of nested loops. You could implement this with boolean flag values, but that approach can make your loop logic more convoluted and error prone. Instead, a goto statement can be used like break to jump out of nested loops:
for (int i = 0; i < 10; i++) {
  for (int j = 0; j < 10; j++) {
    if (...) {
      goto doneWithLoops;
    }
  }
}
doneWithLoops:
  // do more stuff
Similarly, you can use goto to emulate continue within nested loops, though keep in mind that goto doesn't automatically advance to the next item in a for or for...in loop the way continue does:
for (int i = 0; i < 10; i++) {
  start_j:
    for (int j = 0; j < 10; j++) {
      if (...) {
        i++; // manually advance loop counter to emulate continue
        goto start_j;
      }
    }
}
Along with its use in loops, the break statement is also used in the switch statement to mark the end of a case block. It's not uncommon to use a switch statement inside a loop when implementing simple state machines, event dispatchers and parsers:
// simple event dispatcher
MyEvent *event = nil;
while (event = getNextEvent()) {
  switch (event.type) {
    case KEY_EVENT:
      // handle key event
      break;
    case MOUSE_EVENT:
      // handle mouse event
      break;
  }
}
shutdown();
Sometimes you want to exit the event loop from within one of the case blocks, like this:
// simple event dispatcher
MyEvent *event = nil;
while (event = getNextEvent()) {
  switch (event.type) {
    case KEY_EVENT:
      // handle key event
      if (event.keycode == KEY_ESC) {
        // want to break out of the while loop
        // but a break here applies to the case block
      } else {
        // ...
      }
      break;
    case MOUSE_EVENT:
      // handle mouse event
      break;
  }
}
shutdown();
You can always use a boolean flag variable and make your loop test more complex, but using goto here can make your code simpler and easier to follow:
// simple event dispatcher
MyEvent *event = nil;
while (event = getNextEvent()) {
  switch (event.type) {
    case KEY_EVENT:
      // handle key event
      if (event.keycode == KEY_ESC) {
        goto event_loop_end;
      } else {
        // ...
      }
      break;
    case MOUSE_EVENT:
      // handle mouse event
      break;
  }
}
event_loop_end:
  shutdown();

Error handling:
Standard C doesn't have a concept of throwing and catching exceptions; it's normal for functions in C libraries to return a result code to indicate an error (or to have an out parameter that holds a result code or error object). Writing robust programs using a C API requires checking result codes at each step and taking the appropriate action. For example, a function to copy a block of data from one file to another might look like this:
void copy_block(char const *in_filename, char const *out_filename, size_t block_size) {
  FILE *in_file = fopen(in_filename, "r");
  if (in_file) {
    FILE *out_file = fopen(out_filename, "w");
    if (out_file) {
      char *buffer = malloc(block_size);
      if (buffer) {
        int bytes_read = fread(buffer, 1, block_size, in_file);
        if (bytes_read > 0) {
          int bytes_written = fwrite(buffer, 1, bytes_read, out_file);
          if (bytes_written == bytes_read) {
            [[NSNotificationCenter defaultCenter] postNotificationName:@"Copy block completed successfully." object:nil];
          } else {
            [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to write to output file." object:nil];
          }
        } else {
          [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to read from input file." object:nil];
        }
        free(buffer);
      } else {
        [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to allocate buffer." object:nil];
      }
      fclose(out_file);
    } else {
      [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to open output file." object:nil];
    }
    fclose(in_file);
  } else {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to open input file." object:nil];
  }
}
This leads to deeply nested "flock of geese" code that can be error prone and hard to read. One technique to deal with this is to return from the function when an error is encountered. The same code implemented that way looks like this:
void copy_block(char const *in_filename, char const *out_filename, size_t block_size) {
  FILE *in_file = fopen(in_filename, "r");
  if ( ! in_file) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to open input file." object:nil];
    return;
  }
  
  FILE *out_file = fopen(out_filename, "w");
  if ( ! out_file) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to open output file." object:nil];
    fclose(in_file); // clean up
    return;
  }
  
  char *buffer = malloc(block_size);
  if ( ! buffer) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to allocate buffer." object:nil];
    fclose(out_file); // clean up
    fclose(in_file);
    return;
  }
  
  int bytes_read = fread(buffer, 1, block_size, in_file);
  if (bytes_read <= 0) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to read from input file." object:nil];
    free(buffer); // clean up
    fclose(out_file);
    fclose(in_file);
    return;
  }
  
  int bytes_written = fwrite(buffer, 1, bytes_read, out_file);
  if (bytes_written != bytes_read) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to write to output file." object:nil];
    free(buffer); // clean up
    fclose(out_file);
    fclose(in_file);
    return;
  }
  
  [[NSNotificationCenter defaultCenter] postNotificationName:@"Copy block completed successfully." object:nil];
  
  // clean up
  free(buffer);
  fclose(out_file);
  fclose(in_file);
}
One criticism of this approach is that clean up code is duplicated repeatedly and in different variations, a violation of the DRY principle. Some programmers also prefer to have a single return point in a function. Using goto, you can centralize clean up code in one place in the function (and as a side effect, the function now has a single return point):
void copy_block(char const *in_filename, char const *out_filename, size_t block_size) {
  FILE *in_file = fopen(in_filename, "r");
  if ( ! in_file) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to open input file." object:nil];
    goto end;
  }
  
  FILE *out_file = fopen(out_filename, "w");
  if ( ! out_file) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to open output file." object:nil];
    goto clean_up_in_file;
  }
  
  char *buffer = malloc(block_size);
  if ( ! buffer) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to allocate buffer." object:nil];
    goto clean_up_files;
  }
  
  int bytes_read = fread(buffer, 1, block_size, in_file);
  if (bytes_read <= 0) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to read from input file." object:nil];
    goto clean_up_all;
  }
  
  int bytes_written = fwrite(buffer, 1, bytes_read, out_file);
  if (bytes_written != bytes_read) {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"Unable to write to output file." object:nil];
    goto clean_up_all;
  }
  
  [[NSNotificationCenter defaultCenter] postNotificationName:@"Copy block completed successfully." object:nil];
  
  // clean up
  clean_up_all:
    free(buffer);
   
  clean_up_files:
    fclose(out_file);
  
  clean_up_in_file:
    fclose(in_file);
   
  end:
    return;
}
Please note that this is not a recommendation to always structure your error handling in this fashion using goto. This is simply one technique among many that you may encounter "in the wild" and which you may choose to use in the appropriate situation. When goto is used carefully and sparingly, it can help make difficult code cleaner and easier to follow, but unrestrained use of goto has the opposite effect. Whenever you're tempted to use goto in your own code, you should stop and see if you can break the code down into smaller functions or methods. Very often, refactoring a long function or method by extracting chunks of code into smaller functions or methods will do far more for you than a goto can.

Next time, a summary of looping and a new topic: variables.

Friday, December 4, 2009

iPhone Friday - December 4, 2009

Hello and happy Friday.  Today's collection of iPhone and iPod touch wallpapers are from looking out my window this morning.  Enjoy!








Tuesday, December 1, 2009

Objective-C Tuesdays: goto

Last time we looked at using the continue statement to skip to the next iteration of a loop. This week, we will finish looking at loops with the most primitive looping statement of all: the goto statement.

A goto statement always references a label, which is simply an identifier followed by a colon (:). When the goto statement is reached, execution jumps to the label and continues from that point. The label can be before or after the goto statement.
// goto and label examples

start: // label named "start"
  // do some stuff
  if (...) {
    goto start;
  }
  // do more stuff
  if (...) {
    goto end;
  }
  // and more stuff
end: // label named "end"
Labels do nothing by themselves except mark places in code that you can jump to using goto.

The goto statement has one big limitation: it only works within a single function. If you write something like this:
// goto may only jump to labels within a function
// THIS CODE DOESN'T COMPILE

void function1(void) {
  label1:
  goto label2;
}

void function2(void) {
  label2:
  goto label1;
}
The compiler will produce error messages like label ‘label1’ used but not defined. Without this restriction, goto could be abused to create difficult to understand spaghetti code (ask any old time BASIC programmer about this). Because of this restriction, label names are local to the function that contains them, so you can use the same label name in different functions.

Though mostly eschewed in favor of the for, for...in, while and do...while loops, the goto can be used to implement loops:
int i = 0;
startLoop: // label "startLoop"
  NSLog(@"%d", i);
  i++;
  if (i < 10) {
    goto startLoop;
  }
This loop logs the numbers from 0 to 9. It's equivalent to this while loop:
int i = 0;
while (i < 10) {
  NSLog(@"%d", i);
  i++;
}
Because the other looping statements are more compact and expressive, you will rarely see goto used to build loops. Next time, we'll look at common uses for goto.