Outline

• Auto-rotation
• Writing Logs
• Start Persistence

Auto-Rotations

• One cool aspect of the iPhone and Android is that when you rotate the phone it can detect this and display a suitable layout of the screen (Portrait or Landscape).
  
• In the simulator, you can use command and the arrow keys to change the orientation. Or you can select how to rotate the orientation from the hardware menu.

Mechanics of Auto-Rotations

• Apps can choose or choose not to support orientation.
• Many app use the orientations to show different views of the same data. For example, in a mail app in landscape mode we might have a left side bar used to display a list of messages in the mail app while the rest of the screen has the current message; in portrait mode though the mail app focuses on the details of just the selected item.
• For phones typically support orientation if it enhances the UX, for tablets should support it unless there is a compelling reason not to
• Auto-rotation is specified in the view controller. If a user rotates the device, the active view controller is asked if its okay to rotate to the new orientation. If yes, the app windows and views will be rotated to fit the new orientation.
• Sizes in orientations are measured in points (the size of a pixel before retina display introduced. i.e, the size of 2x2pixels on modern iOS devices). For iPhone 4S and earlier this was 320x480 portrait (320x568 on 5 and 5s) and 768x1024 on an iPad. When rotated the dimensions reverse, but you have to remember that by default about 20points will be cut off the top if the status bar is being shown.

Specifying Rotation Support

• There are different ways we can handle rotations: You can handle them in IB by specifying constraints for all the objects that make up the interface or by using code in our view controller. We will look at these in turn.
• To begin we can create a new single-view application.
• One of the things the summary tab for this application shows is the supported device orientations:
  
• This doesn't say that every view in your app must support these orientations, but if a view uses one of these orientations it should be checked here.
• Notice Upside Down is off by default because if the phone rings while in this orientation, you are likely to answer it upside down if you've rotated stuff to this orientation.
• As a quick test of the default rotation support we can make a single-view app draw a label out on the storyboard, compile and run the app. Then using Command-Left-Arrow and Command-Right-Arrow, we can see what happens in the simulator when we change the screen orientation.

Per-Controller Rotation Support

• In each UIViewController in your app you can specify which from your global list of orientations you support.
• This can be done by adding code like the following to your controller:

  -(NSUInteger)supportedInterfaceOrientations {
      return (UIInterfaceOrientationMaskPortrait | 
          UIInterfaceOrientationMaskLandscapeRight);
  }
  

• There are four constants defined in UIApplication.h which can be used in ORs like the above: UIInterfaceOrientationMaskPortrait, UIInterfaceOrientationMaskLandscapeLeft, UIInterfaceOrientationMaskLandscapeRight, UIInterfaceOrientationMaskPortraitUpsideDown.
• There are also three predefined combinations: UIInterfaceOrientationMaskLandscape, UIInterfaceOrientationMaskAll, UIInterfaceOrientationMaskAllButUpsideDown.

Using Interface Constraints with Rotations

• Let's look at how contraints can be used to help in drawing out a storyboard in a device.
• First, drag out four labels to the four corners of the storyboard and re-label then as below.
• Notice we are leaving the width and height properties at the bottom of the storyboard as Any.
  
• If we compile this and try to view it in an iPhone 6 simulator, the two right labels won't appear.
• What we would like for each of our labels is a constraint which says that a label should appear within so much of the margins of the screen. We'd also like other constraints which say the bottoms of such and such label align with the bottoms of other labels, etc.
• You might have noticed when we drag out a label that there are dashed blue alignment guides which appear to help us align the label with other items in the display. If we click on the label then go in the XCode menu to Editor : Resolve Auto Layout Issues : Add Missing Constraints you will see solid blues lines appear from the label as well as little weight constraint symbols that look sorta like |-| .
  
• If we do this for all four label then recompile the labels will all appear within the screen and furthermore their margins from the side of the screen will look correct when we rotate the simulator screen.

More on Interface Constraints with Rotations

If we click on a label and then from the Menu go to Select Tools > Size Inspector we can see what constraints we have on an item.

At the bottom of the panel with the storyboard we also have four icons:

These are bring up controls respectively for: Alignment, Pining Constraints, A Menu for Resolving Auto Layout issues, and a a Resizing Behavior menu. These can also be useful for adding constraints.

Finer Grain Control

• Constraints are pretty powerful but what if we'd like still more control...
• Let's see how to do stuff programmatically.
• Create a new Single-View Project named Restructure.
• We next go to IB and open the File Inspector (Option-Command-1) and uncheck Use Autolayout. It will say if we do this we can only code for iPhone or iPad layouts. Pick iPhone.
• Next drag a view onto the storyboard and set its background to red under Attribute Inspector, and then add four buttons as below.
  
• Using assistant view we next set up the following outlets in our ViewController.h header file:

  #import <UIKit/UIKit.h>
  
  @interface ViewController : UIViewController
  @property (weak, nonatomic) IBOutlet UIButton *actionButton1;
  @property (weak, nonatomic) IBOutlet UIButton *actionButton2;
  @property (weak, nonatomic) IBOutlet UIButton *actionButton3;
  @property (weak, nonatomic) IBOutlet UIButton *actionButton4;
  @property (weak, nonatomic) IBOutlet UIView *contentView;
  @end
  

Our Controller

• Now let's look at our controller.
• We override willAnimateRotationToInterfaceOrientation to put things where we want after the rotation. It checks what the orientation is and calls one of two methods layoutPortrait or layoutLandscape to then place all the controls in the layout
• These two methods use the bounds property of the whole screen to get a rectangle in which to lay things out. Within this we set the frame properties of our buttons and views to CGRect's (given by top, left, width, height) that we would like for these objects.
• Notice at the very bottom of our controller we have modified viewDidLoad so that it sets the initial orientation of the screen correctly.

@#import "ViewController.h"

@interface ViewController ()

@end

@implementation ViewController
-(void)willAnimateRotationToInterfaceOrientation:
    (UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration {
    [self doLayoutForOrientation:toInterfaceOrientation];
}

-(void)doLayoutForOrientation: (UIInterfaceOrientation)orientation {
    if(UIInterfaceOrientationIsPortrait(orientation)){
        [self layoutPortrait];
    } else {
        [self layoutLandscape];
    }
}

static const CGFloat buttonHeight = 40;
static const CGFloat buttonWidth = 120;
static const CGFloat spacing = 20;

-(void)layoutPortrait {
    CGRect b = self.view.bounds;

    CGFloat contentWidth = CGRectGetWidth(b) - (2 * spacing);
    CGFloat contentHeight = CGRectGetHeight(b) - (4 * spacing) -
        (2 * buttonHeight);
    self.contentView.frame = CGRectMake(spacing, spacing, contentWidth,
                                        contentHeight);
    CGFloat buttonRow1y = contentHeight + (2 * spacing);
    CGFloat buttonRow2y = buttonRow1y + buttonHeight +spacing;

    CGFloat buttonCol1x = spacing;
    CGFloat buttonCol2x = CGRectGetWidth(b) - buttonWidth - spacing;

    self.actionButton1.frame = CGRectMake(buttonCol1x, buttonRow1y, buttonWidth,
                                          buttonHeight);
    self.actionButton2.frame = CGRectMake(buttonCol2x, buttonRow1y, buttonWidth,
                                          buttonHeight);
    self.actionButton3.frame = CGRectMake(buttonCol1x, buttonRow2y, buttonWidth,
                                          buttonHeight);
    self.actionButton4.frame = CGRectMake(buttonCol2x, buttonRow2y, buttonWidth,
                                          buttonHeight);
}

-(void)layoutLandscape {
    CGRect b = self.view.bounds;

    CGFloat contentWidth = CGRectGetWidth(b) - buttonWidth - (3 * spacing);
    CGFloat contentHeight = CGRectGetHeight(b) - (2 * spacing);

    self.contentView.frame = CGRectMake(spacing, spacing, contentWidth,
                                        contentHeight);
    CGFloat buttonX = CGRectGetWidth(b) - buttonWidth - spacing;
    CGFloat buttonRow1y = spacing;
    CGFloat buttonRow4y = CGRectGetHeight(b) - buttonHeight - spacing;
    CGFloat buttonRow2y = buttonRow1y + floor((buttonRow4y - buttonRow1y)
                                            * 0.33);
    CGFloat buttonRow3y = buttonRow1y + floor((buttonRow4y - buttonRow1y)
                                              * 0.667);


    self.actionButton1.frame = CGRectMake(buttonX, buttonRow1y, buttonWidth,
                                          buttonHeight);
    self.actionButton2.frame = CGRectMake(buttonX, buttonRow2y, buttonWidth,
                                          buttonHeight);
    self.actionButton3.frame = CGRectMake(buttonX, buttonRow3y, buttonWidth,
                                          buttonHeight);
    self.actionButton4.frame = CGRectMake(buttonX, buttonRow4y, buttonWidth,
                                          buttonHeight);
}

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    UIApplication *app = [UIApplication sharedApplication];
    UIInterfaceOrientation currentOrientation = app.statusBarOrientation;
    [self doLayoutForOrientation: currentOrientation];
}

- (void)didReceiveMemoryWarning {
    [super didReceiveMemoryWarning];
    // Dispose of any resources that can be recreated.
}

@end
   

What it looks like

Logging

• For diagnostic/debugging purposes, it is often useful to get your app to write log messages while it is running.
• On a Mac, these messages often appear in your console (look in App > Utilities).
• In XCode you can see your device's console by looking at the bottom center pane when your app is running.
• To write a log message, you simply call the function NSLog:

     NSLog(@"Hello world of logging");
  

• Notice this is a C (not Objective-C) function call.

Starting Data Persistence

• So far we have considered Views and Controllers in the MVC pattern.
• We'd next like look at Models to some extent.
• i.e., we'd like some means to store application data persistently between invocations of our program.
• To understand how this works, we first must understand how data is arranged on the iPhone.
• Essentially, we have a folder structure just like on a Mac.
• Just as on a Mac there is a User folder and within it we have the following sub-folders: tmp, Root, Media, Library, Applications
• You can see this folder structure for the simulator by going to: ~/Library/Application Support/iPhoneSimulator/User/
• Each iPhone App is stored in the Applications folder. Each of these App folders has in turn a Documents, Library, and tmp.
• Next day, we will discuss how our app can access these.