Support for getOrientationRepresentationViaStatusBar

[CMTaylor]

There's a method in src/Commands/OrientationCommand.m:

• (NSDictionary *)getOrientationRepresentationViaStatusBar{
  switch([[UIApplication sharedApplication] statusBarOrientation]){
  case UIInterfaceOrientationLandscapeLeft:
  return [self representOrientation:@"landscape" withDetailedOrientation:@"landscape_left"];
  case UIInterfaceOrientationLandscapeRight:
  return [self representOrientation:@"landscape" withDetailedOrientation:@"landscape_right"];
  case UIInterfaceOrientationPortrait:
  return [self representOrientation:@"portrait" withDetailedOrientation:@"portrait"];
  case UIInterfaceOrientationPortraitUpsideDown:
  return [self representOrientation:@"portrait" withDetailedOrientation:@"portrait_upside_down"];
  default:
  NSLog(@"Device orientation via status bar is unknown");
  return nil;
  }
  }

but it is never called. The handleGet method seems to have a bug where if getOrientationRepresentationViaDevice returns nil then it calls the same method, getOrientationRepresentationViaDevice, again.

• (NSString *)handleGet{
  NSDictionary *orientationDescription = [self getOrientationRepresentationViaDevice];
  if( !orientationDescription )
  orientationDescription = [self getOrientationRepresentationViaDevice];

  return TO_JSON(orientationDescription);
  }

Maybe the original intent was to call getOrientationRepresentationViaStatusBar if getOrientationRepresentationViaDevice failed. In the past I had my own additional command that I added to Frank to specifically get the orientation via the Status Bar, 'cause some times you MUST do this. I would prefer not to add my own code back in, since the code's here already. But I would like an option on the host side to call getOrientationRepresentationViaDevice or getOrientationRepresentationViaStatusBar depending on my needs.

I'd do this fix myself, except I'm unsure of how method names at this depth in the code get mapped to methods that the Frank Helper on the host side can call. Given some brief tutoring on this, I'd be happy to make the change, test it, and issue a Pull request.

[moredip]

Looks like that's definitely a bug wrt calling [self getOrientationRepresentationViaDevice] twice. In fact, I think it's something I introduced here: 82c3b33

The way the command routing works on the server-side is something like:

• at launch all the different command handlers in the Frank server register themselves: https://github.com/TestingWithFrank/Frank/blob/master/src/FrankServer.m#L62
• at some point the frank client posts some JSON to a url
• FrankCommandRoute receives the request at https://github.com/TestingWithFrank/Frank/blob/master/src/FrankCommandRoute.m#L72
• it looks up a command to handle the request, based on the first path component in the url. If it finds a command it asks it to handle the request. Otherwise it returns a 404.

In the case of orientation, a GET to /orientation handled by the OrientationCommand, as you've discovered.

On the client side for the ruby gem, it works like this:

• when you require 'frank-cucumber' several helper modules are mixed into the magical cucumber World: https://github.com/TestingWithFrank/Frank/blob/master/gem/lib/frank-cucumber.rb#L8 After that point the methods in those modules are available to be called within any cucumber step definition.
• one of the modules that's mixed in (FrankHelper) includes some orientation-related methods, the key one being frankly_current_orientation: https://github.com/TestingWithFrank/Frank/blob/master/gem/lib/frank-cucumber.rb#L8
• that method gets the orientation by sending a GET for the /orientation url to the frank server. It then parses the JSON response, pull out the orientation field, and reports it back to the client.

Hope that helps some.

[CMTaylor]

I have an implementation for this that works on my iPads. I can't do a pull request just yet due to two things:

1. I need to get my employer's legal folks to OK my contribution to this Open Source project.
2. I'm reluctant to commit this until we can figure out why, and fix, the issue where MY build of libFrank.a breaks certain "touch" features.