programming ios 7, 4th edition

3 The Window 4 Experimenting With Views 7 Subview and Superview 8 Visibility and Opacity 11 Frame 12 Bounds and Center 13 Transform 16 Layout 22 Autoresizing 23 Autolayout 27 Constraints

Matt Neuburg

FOURTH EDITIONProgramming iOS 7

Programming iOS 7, Fourth Edition

by Matt Neuburg

Copyright © 2014 Matt Neuburg All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use Online editions are

also available for most titles (http://my.safaribooksonline.com) For more information, contact our corporate/ institutional sales department: (800) 998-9938 or corporate@oreilly.com.

Editor: Rachel Roumeliotis

Production Editor: Kristen Brown

Proofreader: O’Reilly Production Services

Indexer: Matt Neuburg

Cover Designer: Randy Comer Interior Designer: David Futato Illustrator: Matt Neuburg

May 2011: First Edition

March 2012: Second Edition

March 2013: Third Edition

December 2013: Fourth Edition

Revision History for the Fourth Edition:

2013-12-09: First release

See http://oreilly.com/catalog/errata.csp?isbn=9781449372347 for release details.

Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly

Media, Inc Programming iOS 7, the image of a kingbird, and related trade dress are trademarks of O’Reilly

Media, Inc.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trade‐ mark claim, the designations have been printed in caps or initial caps.

While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

ISBN: 978-1-449-37234-7

[LSI]

Table of Contents

Preface xv

Part I Views 1 Views 3

The Window 4

Experimenting With Views 7

Subview and Superview 8

Visibility and Opacity 11

Frame 12

Bounds and Center 13

Transform 16

Layout 22

Autoresizing 23

Autolayout 27

Constraints in the Nib 38

Order of Layout Events 45

Autolayout and View Transforms 46

2 Drawing 49

UIImage and UIImageView 49

Resizable Images 53

Image Rendering Mode 56

Graphics Contexts 58

UIImage Drawing 61

CGImage Drawing 63

Snapshots 66

CIFilter and CIImage 68

Drawing a UIView 72

iii

Graphics Context Settings 74

Paths and Shapes 75

Clipping 79

Gradients 80

Colors and Patterns 82

Graphics Context Transforms 84

Shadows 86

Erasing 87

Points and Pixels 88

Content Mode 89

3 Layers 91

View and Layer 92

Layers and Sublayers 94

Manipulating the Layer Hierarchy 97

Positioning a Sublayer 98

CAScrollLayer 99

Layout of Sublayers 99

Drawing in a Layer 100

Content Resizing and Positioning 104

Layers that Draw Themselves 106

Transforms 108

Depth 111

Shadows, Borders, and Masks 115

Layer Efficiency 116

Layers and Key–Value Coding 118

4 Animation 121

Drawing, Animation, and Threading 122

UIImageView and UIImage Animation 125

View Animation 126

Block-Based View Animation 127

View Animation Options 129

Springing View Animation 134

Keyframe View Animation 134

Transitions 136

Implicit Layer Animation 138

Animation Transactions 140

Media Timing Functions 141

Core Animation 143

CABasicAnimation and Its Inheritance 143

Using a CABasicAnimation 145

Keyframe Animation 149

Making a Property Animatable 150

Grouped Animations 151

Transitions 155

Animations List 157

Actions 159

What an Action Is 160

Action Search 160

Hooking Into the Action Search 162

Nonproperty Actions 164

Emitter Layers 166

CIFilter Transitions 171

UIKit Dynamics 174

Motion Effects 180

Animation and Autolayout 181

5 Touches 185

Touch Events and Views 186

Receiving Touches 187

Restricting Touches 189

Interpreting Touches 190

Gesture Recognizers 195

Gesture Recognizer Classes 195

Gesture Recognizer Conflicts 200

Subclassing Gesture Recognizers 203

Gesture Recognizer Delegate 205

Gesture Recognizers in the Nib 207

Touch Delivery 208

Hit-Testing 208

Initial Touch Event Delivery 214

Gesture Recognizer and View 214

Touch Exclusion Logic 216

Gesture Recognition Logic 216

Touches and the Responder Chain 218

Part II Interface 6 View Controllers 223

View Controller Responsibilities 224

View Controller Hierarchy 225

View Controller Creation 231

Table of Contents | v

How a View Controller Gets Its View 234

Manual View 235

Generic Automatic View 237

View in a Separate Nib 238

Nib-Instantiated View Controller 241

Storyboard-Instantiated View Controller 243

View Resizing and the Status Bar 245

Rotation 251

Rotation and Layout Events 254

Initial Orientation 258

Presented View Controller 261

Presenting a View 262

Communication With a Presented View Controller 264

Presented View Animation 267

Presentation Styles 268

Rotation of a Presented View 271

Presenting a View in Response to Rotation 273

Tab Bar Controllers 274

Tab Bar Items 276

Configuring a Tab Bar Controller 277

Navigation Controllers 279

Bar Button Items 282

Navigation Items and Toolbar Items 284

Configuring a Navigation Controller 287

Custom Transition Animations 290

Noninteractive Custom Transition Animation 291

Interactive Custom Transition Animation 294

Custom Presented View Controller Transition 301

Transition Coordinator 308

Page View Controller 310

Container View Controllers 315

Storyboards 320

Segues 322

Container Views 324

Unwind Segues 325

View Controller Lifetime Events 329

Incoherencies in View Controller Events 332

Appear and Disappear Events 332

Manual Event Forwarding to a Child View Controller 333

View Controller Memory Management 335

State Restoration 337

How to Test State Restoration 338

Participating in State Restoration 339

Restoration ID, Identifier Path, and Restoration Class 341

Restoring View Controller State 348

Restoration Order of Operations 353

Restoration of Other Objects 355

Snapshot Suppression 357

7 Scroll Views 359

Creating a Scroll View in Code 360

Using a Content View 363

Scroll View in a Nib 365

Scrolling 367

Paging 371

Tiling 373

Zooming 375

Zooming Programmatically 376

Zooming with Detail 377

Scroll View Delegate 380

Scroll View Touches 382

Floating Scroll View Subviews 386

Scroll View Performance 387

8 Table Views and Collection Views 389

Table View Cells 392

Built-In Cell Styles 393

Registering a Cell Class 399

Custom Cells 401

Table View Data 408

The Three Big Questions 409

Reusing Cells 411

Table View Sections 413

Section Index 418

Refreshing Table View Data 419

Variable Row Heights 423

Table View Cell Selection 426

Managing Cell Selection 426

Responding to Cell Selection 427

Navigation From a Table View 429

Cell Choice and Static Tables 430

Table View Scrolling and Layout 432

Table View State Restoration 432

Table View Searching 433

Table of Contents | vii

Table View Editing 442

Deleting Table Items 445

Editable Content in Table Items 446

Inserting Table Items 448

Rearranging Table Items 450

Dynamic Table Items 451

Table View Menus 453

Collection Views 455

Collection View Classes 459

Using a Collection View 462

Custom Collection View Layouts 465

Switching Layouts 469

Collection Views and UIKit Dynamics 470

9 Popovers and Split Views 473

Preparing a Popover 475

Popover Size 476

Popover Appearance Customization 477

Summoning and Dismissing a Popover 480

Popover Segues 480

Managing a Popover Controller 481

Dismissing a Popover 482

Popovers During Rotation or Backgrounding 485

Popovers and Presented Views 486

Automatic Popovers 487

Split Views 489

Using a Split View 489

Split Views in a Storyboard 491

Other Split View Configurations 492

10 Text 493

Fonts 494

Fonts and Dynamic Type 494

Font Descriptors 497

Attributed Strings 499

Attributed String Attributes 500

Making an Attributed String 503

Modifying and Querying an Attributed String 508

Measuring and Drawing an Attributed String 509

Labels 511

Number of Lines 511

Wrapping and Truncation 512

Label Resizing 513

Customized Label Drawing 514

Text Fields 515

Summoning and Dismissing the Keyboard 517

Keyboard Covers Text Field 519

Configuring the Keyboard 524

Text Field Delegate and Control Event Messages 525

Text Field Menu 528

Text Views 530

Text View as Scroll View 531

Text View and Keyboard 532

Text Kit 534

Text Container 535

Alternative Text Kit Stack Architectures 538

Layout Manager 540

Text Kit Without a Text View 543

11 Web Views 549

Web View Content 550

Loading Web View Content 554

Designing Web View Content 556

Paginated Web Views 558

Web View State Restoration 558

Communicating with a Web View 559

12 Controls and Other Views 563

UIActivityIndicatorView 563

UIProgressView 565

UIPickerView 567

UISearchBar 569

UIControl 574

UISwitch 578

UIStepper 579

UIPageControl 581

UIDatePicker 581

UISlider 584

UISegmentedControl 587

UIButton 590

Custom Controls 595

Bars 598

Bar Position and Bar Metrics 599

Bar Appearance 601

Table of Contents | ix

UIBarButtonItem 602

UINavigationBar 604

UIToolbar 607

UITabBar 607

Tint Color 612

Appearance Proxy 614

13 Modal Dialogs 619

Alert View 620

Action Sheet 622

Dialog Alternatives 627

Local Notifications 628

Activity View 632

Part III Some Frameworks 14 Audio 639

System Sounds 639

Audio Session 640

Interruptions 643

Routing Changes 645

Audio Player 646

Remote Control of Your Sound 648

Playing Sound in the Background 651

Further Topics in Sound 654

15 Video 657

MPMoviePlayerController 658

MPMoviePlayerViewController 664

UIVideoEditorController 665

Introduction to AV Foundation 668

Some AV Foundation Building Blocks 668

Displaying a Movie 669

Synchronizing Video With Animation 671

Building Media 672

Further Exploration of AV Foundation 673

16 Music Library 675

Exploring the Music Library 675

Querying the Music Library 676

Persistence and Change in the Music Library 680

Music Player 681

MPVolumeView 684

Playing Songs With AV Foundation 686

Music Picker 688

17 Photo Library and Image Capture 693

Choosing From the Photo Library 693

Assets Library Framework 697

Using the Camera 701

Customizing the Image Capture Interface 703

Image Capture With AV Foundation 705

18 Address Book 709

Address Book Database 709

Address Book Interface 714

ABPeoplePickerNavigationController 715

ABPersonViewController 717

ABNewPersonViewController 718

ABUnknownPersonViewController 719

19 Calendar 721

Calendar Database 721

Creating Calendars and Events 725

Recurrence 727

Fetching Events 729

Reminders 731

Proximity Alarms 732

Calendar Interface 732

EKEventViewController 733

EKEventEditViewController 735

EKCalendarChooser 736

20 Mail and Messages 739

Mail Message 739

Text Message 741

Twitter Post 742

21 Maps 743

Displaying a Map 743

Annotations 746

Custom Annotation View 747

Custom Annotation Class 751

Table of Contents | xi

Other Annotation Features 752

Overlays 754

Custom Overlay Class 755

Custom Overlay Renderer 758

Other Overlay Features 760

Map Kit and Current Location 761

Communicating With the Maps App 762

Geocoding, Searching, and Directions 764

Geocoding 764

Searching 766

Directions 766

22 Sensors 769

Core Location 770

Basic Location Determination 771

Heading 775

Background Location 776

Acceleration and Attitude 779

Shake Events 780

Raw Acceleration 781

Gyroscope 785

Part IV Final Topics 23 Persistent Storage 793

The Sandbox 793

Basic File Operations 794

Saving and Reading Files 796

User Defaults 798

File Sharing 799

Document Types 800

Handing Off a Document 803

Document Architecture 806

iCloud 811

XML 814

SQLite 821

Core Data 821

Image File Formats 827

24 Basic Networking 831

HTTP Requests 831

Simple HTTP Request 833

Formal HTTP Request 834

Multiple Tasks 839

Background Downloads 845

Background App Refresh 847

In-App Purchases 848

Bonjour 852

25 Threads 855

Main Thread 855

Why Threading Is Hard 858

Three Ways of Threading 860

Manual Threads 861

NSOperation 863

Grand Central Dispatch 867

Threads and App Backgrounding 872

26 Undo 875

Undo Manager 875

Target–Action Undo 876

Undo Grouping 878

Invocation Undo 879

Undo Interface 880

Shake-To-Edit 880

Undo Menu 881

A Application Lifetime Events 883

Index 889

Table of Contents | xiii

Aut lego vel scribo; doceo scrutorve sophian.

—Sedulius Scottus

Preface

This book, now in its fourth edition, has grown in size to encompass the growth in its

subject, until it can grow no more The previous editions — Programming iOS 4 (May 2011), Programming iOS 5 (March 2012), and Programming iOS 6 (March 2013) — were

approximately 800 pp., 950 pp., and 1150 pp in length, respectively, not because I hadmore to say each time, but because Apple, as it added features to iOS 4 to make iOS 5,and to iOS 5 to make iOS 6, had given me more to describe

Now iOS 7 has come along with even more new features, and drastic action was needed.Accordingly, the book has been ripped violently but neatly in two — neatly, becausethere was already a perfectly natural place to do the ripping, namely right after the end

of what used to be Part III (Chapter 13) There are now two books:

• A new book, iOS 7 Programming Fundamentals, comprising chapters 1–13 of theearlier books

• This book, Programming iOS 7, comprising chapters 14–40 of the earlier books

The truth is that this is a division I had wanted to make even before Programming iOS

4 was published — indeed, before it was even conceived of My original proposal to

O’Reilly Media, back in early 2010, had been for a book to be called Fundamentals of

Cocoa Programming , intended to cover very much the same material as iOS 7 Program‐

ming Fundamentals covers now But the proposal was accepted only on condition that

it be extended to cover much more of Cocoa Touch (iOS) programming; so I compliedand set to work on this longer project, and later, despite my impassioned pleas in theautumn of 2010, I was unable to persuade the publisher to break up the lengthy manu‐script into two: by that time, all the king’s horses and all the king’s men could no longercrack Humpty Dumpty apart

The new situation, therefore, is just what I always wanted in the first place — but notquite, because what I most desired was a single book in two volumes My idea was that

xv

the books would have the same title, distinguished as Volume I and Volume II, withsuccessive numbering of pages and chapters: if Volume I ended, say, with Chapter 13and page 400, then Volume II would start with Chapter 14 and page 401 To this de‐lightfully Victorian extreme, I’m sorry to say, O’Reilly Media were implacably opposed.

Thus, Programming iOS 7, though it starts with its own Chapter 1 and page 1, never‐ theless still picks up exactly where iOS 7 Programming Fundamentals leaves off They

complement and supplement one another Those who desire a complete grounding inthe knowledge needed to begin writing iOS apps with a solid and rigorous understand‐ing of what they are doing and where they are heading will, I hope, obtain both books

At the same time, the two-book architecture should, I believe, render the size and scope

of each book individually more acceptable and attractive to more readers

Those who feel that they know already all there is to know about C, Objective-C, Xcode,and the linguistic and architectural basis of the Cocoa framework, or who are content

to pick up such underpinnings as they go along, need no longer (as some in the pasthave done) complain that the book is occupied with 13 preliminary chapters before thereader starts really writing any significant iOS code, because those 13 chapters have now

been abstracted into a separate volume, iOS 7 Programming Fundamentals, and this book, Programming iOS 7, now begins, like Homer’s Iliad, in the middle of the story,

with the reader jumping with all four feet into views and view controllers, and with aknowledge of the language and the Xcode IDE already presupposed And if such a readersubsequently changes his or her mind and decides that a thorough grounding in those

underpinnings might in fact be desirable, iOS 7 Programming Fundamentals will still

be available and awaiting study

Moreover, the existence of iOS 7 Programming Fundamentals means that I, as author

and teacher, can make the same assumption in this edition about you, as reader andstudent, that I made in previous editions — namely, that you have a command of thematerial in that book If you find yourself mystified by terminology or concepts used in

this book, then it might be wise to stop reading it and take up iOS 7 Programming

Fundamentals first! In it, I explain such things as:

• The Objective-C language, starting with C and building up to the object-orientedconcepts and mechanics of classes and instances in Objective-C itself

• Xcode, the world in which all iOS programming ultimately takes place, includingwhat an Xcode project is and how it is transformed into an app, and how to workcomfortably and nimbly with Xcode to consult the documentation and to write,navigate, and debug code, as well as how to bring your app through the subsequentstages of running on a device and submission to the App Store There is also a veryimportant chapter on nibs and the nib editor (Interface Builder), including outletsand actions as well as the mechanics of nib loading (However, some additionalimportant nib-related topics, such as autolayout constraints and storyboard segues,

are discussed in this book.)

• The Cocoa Touch framework, which provides important foundational classes andadds linguistic and architectural devices such as categories, protocols, delegation,and notifications, as well as the pervasive responsibilities of memory management,plus key–value coding and key–value observing.

With those basics having been laid down in iOS 7 Programming Fundamentals, this book, Programming iOS 7, assumes that you already know Objective-C and how to work

with Xcode to edit code and nibs, make properties and outlets and actions, and so forth,and proceeds to explain the constituents of practical iOS app construction:

• Part I describes views, the fundamental units of an iOS app’s interface Views are

what the user can see and touch in an iOS app To make something appear beforethe user’s eyes, you need a view To let the user interact with your app, you need aview This part of the book explains how views are created, arranged, drawn, layered,animated, and touched

• Part II starts by discussing view controllers Perhaps the most remarkable and im‐

portant feature of iOS programming, view controllers enable views to come and gocoherently within the interface, thus allowing a single-windowed app running onwhat may be a tiny screen to contain multiple screens of material This part of thebook talks about all the ways in which view controllers can be manipulated in order

to make their views appear It also describes every kind of view provided by the

Cocoa framework — the built-in “widgets” with which you’ll construct an app’sinterface

• Part III surveys many of the secondary frameworks provided by iOS These are

clumps of code, sometimes with built-in interface, that are not part of your app bydefault, but are there for the asking if you need them, allowing you to work withsuch things as sound, video, user libraries, mail, maps, and the device’s sensors

• Part IV wraps up the book with some miscellaneous but important topics: files,networking, threading, and how to implement Undo and Redo

• Appendix A summarizes the most important lifetime event messages sent to yourapp delegate

Someone who has read this book (and who, it goes without saying, is conversant with

the material in iOS 7 Programming Fundamentals) will, I believe, be capable of writing

a real-life iOS app, and to do so with a clear understanding of what he or she is doingand where the app is going as it grows and develops The book itself doesn’t show how

to write any particularly interesting iOS apps (though it is backed by dozens of exampleprojects that you can download from my GitHub site, http://github.com/mattneub/ Programming-iOS-Book-Examples), but it does constantly use my own real apps andreal programming situations to illustrate and motivate its explanations

Just as important, this book is intended to prepare you for your own further explorations

In the case of some topics, especially in Part III and Part IV, I guide you past the initial

Preface | xvii

barrier of no knowledge into an understanding of the topic, its concepts, its capabilities,and its documentation, along with some code examples; but the topic itself may be sohuge that there is room only to introduce it here Your feet, nevertheless, will now beset firmly on the path, and you will know enough that you can now proceed furtherdown that path on your own whenever the need or interest arises.

Indeed, there is always more to learn about iOS iOS is vast! It is all too easy to find areas

of iOS that have had to be ruled outside the scope of this book In Part IV, for example,

I peek at Core Data, and demonstrate its use in code, but a true study of Core Data wouldrequire an entire book of its own (and such books exist); so, having opened the door, Iquickly close it again, lest this book suddenly double in size By the same token, manyareas of iOS are not treated at all in this book:

OpenGL

An open source C library for drawing, including 3D drawing, that takes full ad‐vantage of graphics hardware This is often the most efficient way to draw, especiallywhen animation is involved iOS incorporates a simplified version of OpenGL called

OpenGL ES See Apple’s OpenGL Programming Guide for iOS Open GL interface

configuration, texture loading, shading, and calculation are simplified by the GLKit

framework; see the GLKit Framework Reference.

Sprite Kit

New in iOS 7, Sprite Kit provides a built-in framework for designing 2D animatedgames

Accelerate

Certain computation-intensive processes will benefit from the vector-based Accel‐

erate framework See the vDSP Programming Guide.

Game Kit

The Game Kit framework covers three areas that can enhance your user’s gameexperience: Wireless or Bluetooth communication directly between devices (peer-to-peer); voice communication across an existing network connection; and GameCenter, which facilitates these and many other aspects of interplayer communica‐tion, such as posting and viewing high scores and setting up combinations of players

who wish to compete See the Game Kit Programming Guide.

Advertising

The iAD framework lets your free app attempt to make money by displaying ad‐

vertisements provided by Apple See the iAD Programming Guide.

Newsstand

Your app may represent a subscription to something like a newspaper or magazine

See the Newsstand Kit Framework Reference.

Printing

See the “Printing” chapter of the Drawing and Printing Guide for iOS.

This book does not discuss security topics such as keychains, certificates, and en‐

cryption See the Security Overview and the Security framework.

Accessibility

VoiceOver assists visually impaired users by describing the interface aloud To par‐ticipate, views must be configured to describe themselves usefully Built-in viewsalready do this to a large extent, and you can extend this functionality See the

Accessibility Programming Guide for iOS

Telephone

The Core Telephony framework lets your app get information about a particularcellular carrier and call

Pass Kit

The Pass Kit framework allows creation of downloadable passes to go into the user’s

Passbook app See the Passbook Programming Guide.

of advice about backward compatibility, and now and then I will call out a particularlynoteworthy change from earlier versions

(For example, it has been hard to refrain from pointing out the confusion caused by thechanges in how the status bar works, or in the meaning of tintColor, or the nightmarishway in which your perfectly viable iOS 6 project, when recompiled against iOS 7, willtry to resize and reposition its views incorrectly, underlapping the navigation bar.)Xcode 5 no longer offers the user, creating a new app project from one of the projecttemplates, an option as to whether or not to use Automatic Reference Counting (ARC),the compiler-based manual memory management technology that has made life somuch easier for iOS programmers in recent years ARC is simply turned on by default.Therefore, this book assumes from the outset that you are using ARC

Xcode also no longer provides a template-based option as to whether or not to use astoryboard All projects (except the Empty Application template) come with a main

storyboard, and there is no option to use a main xib file instead Taking my cue from

Preface | xix

this, I have adapted my teaching style to assume that storyboards are primary and thatyou’ll usually be using one (I do also assume that you know how to make and work

with a xib file when you need one, as this is explained in iOS 7 Programming Funda‐

mentals.)

I have also embraced, often without much fanfare, the various other iOS 7 and Xcode

5 innovations Apple has clearly set out, with this generation of their software, to makeiOS programming easier and more pleasant than ever; and by and large they have suc‐ceeded For example, modules and autolinking have made it much simpler than in thepast to work with additional frameworks, and I simply assume as a matter of course thatyou will be using them; thus, when telling you what to do in order to employ a certainframework, I give simply the relevant @import command Similarly, in discussing draw‐ing and images in Chapter 2, I naturally steer you toward the use of asset catalogs

Acknowledgments

My thanks go first and foremost to the people at O’Reilly Media who have made writing

a book so delightfully easy: Rachel Roumeliotis, Sarah Schneider, Kristen Brown, andAdam Witwer come particularly to mind And let’s not forget my first and long-standingeditor, Brian Jepson, who had nothing whatever to do with this edition, but whoseinfluence is present throughout

As in the past, I have been greatly aided by some fantastic software, whose excellences

I have appreciated at every moment of the process of writing this book I should like tomention, in particular:

From the Programming iOS 4 Preface

A programming framework has a kind of personality, an overall flavor that provides aninsight into the goals and mindset of those who created it When I first encounteredCocoa Touch, my assessment of its personality was: “Wow, the people who wrote thisare really clever!” On the one hand, the number of built-in interface widgets was severelyand deliberately limited; on the other hand, the power and flexibility of some of thosewidgets, especially such things as UITableView, was greatly enhanced over their OS Xcounterparts Even more important, Apple created a particularly brilliant way (UIView‐Controller) to help the programmer make entire blocks of interface come and go andsupplant one another in a controlled, hierarchical manner, thus allowing that tinyiPhone display to unfold virtually into multiple interface worlds within a single appwithout the user becoming lost or confused

The popularity of the iPhone, with its largely free or very inexpensive apps, and thesubsequent popularity of the iPad, have brought and will continue to bring into the foldmany new programmers who see programming for these devices as worthwhile anddoable, even though they may not have felt the same way about OS X Apple’s own annualWWDC developer conventions have reflected this trend, with their emphasis shiftedfrom OS X to iOS instruction

The widespread eagerness to program iOS, however, though delightful on the one hand,has also fostered a certain tendency to try to run without first learning to walk iOS givesthe programmer mighty powers that can seem as limitless as imagination itself, but italso has fundamentals I often see questions online from programmers who are evidentlydeep into the creation of some interesting app, but who are stymied in a way that revealsquite clearly that they are unfamiliar with the basics of the very world in which they are

so happily cavorting

It is this state of affairs that has motivated me to write this book, which is intended toground the reader in the fundamentals of iOS I love Cocoa and have long wished towrite about it, but it is iOS and its popularity that has given me a proximate excuse to

do so Here I have attempted to marshal and expound, in what I hope is a pedagogicallyhelpful and instructive yet ruthlessly Euclidean and logical order, the principles andelements on which sound iOS programming rests My hope, as with my previous books,

is that you will both read this book cover to cover (learning something new often enough

to keep you turning the pages) and keep it by you as a handy reference

This book is not intended to disparage Apple’s own documentation and exampleprojects They are wonderful resources and have become more wonderful as time goes

on I have depended heavily on them in the preparation of this book But I also find thatthey don’t fulfill the same function as a reasoned, ordered presentation of the facts Theonline documentation must make assumptions as to how much you already know; itcan’t guarantee that you’ll approach it in a given order And online documentation is

Preface | xxi

more suitable to reference than to instruction A fully written example, no matter howwell commented, is difficult to follow; it demonstrates, but it does not teach.

A book, on the other hand, has numbered chapters and sequential pages; I can assumeyou know views before you know view controllers for the simple reason that Part Iprecedes Part II And along with facts, I also bring to the table a degree of experience,which I try to communicate to you Throughout this book you’ll find me referring to

“common beginner mistakes”; in most cases, these are mistakes that I have made myself,

in addition to seeing others make them I try to tell you what the pitfalls are because Iassume that, in the course of things, you will otherwise fall into them just as naturally

as I did as I was learning You’ll also see me construct many examples piece by piece orextract and explain just one tiny portion of a larger app It is not a massive finishedprogram that teaches programming, but an exposition of the thought process that de‐veloped that program It is this thought process, more than anything else, that I hopeyou will gain from reading this book

Conventions Used in This Book

The following typographical conventions are used in this book:

Constant width bold

Shows commands or other text that should be typed literally by the user

Constant width italic

Shows text that should be replaced with user-supplied values or by values deter‐mined by context

This icon signifies a tip, suggestion, or general note

This icon indicates a warning or caution

Using Code Examples

Supplemental material (code examples, exercises, etc.) is available for download at

We appreciate, but do not require, attribution An attribution usually includes the title,

author, publisher, and ISBN For example: “Programming iOS 7 by Matt Neuburg

(O’Reilly) Copyright 2014 Matt Neuburg, 978-1-449-37234-7.”

If you feel your use of code examples falls outside fair use or the permission given above,feel free to contact us at permissions@oreilly.com

Safari® Books Online

Safari Books Online is an on-demand digital library that deliversexpert content in both book and video form from the world’s lead‐ing authors in technology and business

Technology professionals, software developers, web designers, and business and crea‐tive professionals use Safari Books Online as their primary resource for research, prob‐lem solving, learning, and certification training

Safari Books Online offers a range of product mixes and pricing programs for organi‐zations, government agencies, and individuals Subscribers have access to thousands ofbooks, training videos, and prepublication manuscripts in one fully searchable databasefrom publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Pro‐fessional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, JohnWiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FTPress, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technol‐ogy, and dozens more For more information about Safari Books Online, please visit us

online

Preface | xxiii

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

PART I

Views

The things that appear in your app’s interface are, ultimately, views A view is a unit of

your app that knows how to draw itself A view also knows how to sense that the userhas touched it Views are what your user sees on the screen, and what your user interactswith by touching the screen Thus, views are the primary constituent of an app’s visible,

touchable manifestation They are your app’s interface So it’s going to be crucial to know

how views work

• Chapter 1 discusses views in their most general aspect — their hierarchy, visibility,and position, including an explanation of autolayout

• Chapter 2 is about drawing A view knows how to draw itself; this chapter explainshow to tell a view what you want it to draw, from displaying an existing image toconstructing a drawing in code

• Chapter 3 explains about layers The drawing power of a view comes ultimatelyfrom its layer To put it another way, a layer is effectively the aspect of a view thatknows how to draw — with even more power

• Chapter 4 tells about animation An iOS app’s interface isn’t generally static; it’slively Much of that liveliness comes from animation iOS gives you great power toanimate your interface with remarkable ease; that power, it turns out, resides ulti‐mately in layers

• Chapter 5 is about touches A view knows how to sense that the user is touching it.This chapter explains the iOS view-based mechanisms for sensing and responding

to touches, with details on how touches are routed to the appropriate view and howyou can customize that routing

CHAPTER 1

Views

A view (an object whose class is UIView or a subclass of UIView) knows how to draw

itself into a rectangular area of the interface Your app has a visible interface thanks toviews Creating and configuring a view can be extremely simple: “Set it and forget it.”For example, you can drag an interface widget, such as a UIButton, into a view in thenib editor; when the app runs, the button appears, and works properly But you can alsomanipulate views in powerful ways, in real time Your code can do some or all of theview’s drawing of itself (Chapter 2); it can make the view appear and disappear, move,resize itself, and display many other physical changes, possibly with animation (Chap‐ter 4)

A view is also a responder (UIView is a subclass of UIResponder) This means that aview is subject to user interactions, such as taps and swipes Thus, views are the basisnot only of the interface that the user sees, but also of the interface that the user touches(Chapter 5) Organizing your views so that the correct view reacts to a given touch allowsyou to allocate your code neatly and efficiently

The view hierarchy is the chief mode of view organization A view can have subviews;

a subview has exactly one immediate superview Thus there is a tree of views Thishierarchy allows views to come and go together If a view is removed from the interface,its subviews are removed; if a view is hidden (made invisible), its subviews are hidden;

if a view is moved, its subviews move with it; and other changes in a view are likewiseshared with its subviews The view hierarchy is also the basis of, though it is not identical

to, the responder chain

A view may come from a nib, or you can create it in code On balance, neither approach

is to be preferred over the other; it depends on your needs and inclinations and on theoverall architecture of your app

3

The Window

The top of the view hierarchy is the app’s window It is an instance of UIWindow (or

your own subclass thereof), which is a UIView subclass Your app should have exactly

one main window It is created at launch time and is never destroyed or replaced Itoccupies the entire screen and forms the background to, and is the ultimate superview

of, all your other visible views Other views are visible by virtue of being subviews, atsome depth, of your app’s window

If your app can display views on an external screen, you’ll create an

additional UIWindow to contain those views; but in this chapter I’ll

behave as if there were just one screen, the device’s own screen, and

just one window I repeat: if there is just one screen, your app should

create just one UIWindow You may encounter online tutorials that

advise explicit creation of a second UIWindow as a way of making

content appear in front of the app’s main interface; such statements are

wrong and should be disregarded To make content appear in front of

the interface, add a view, not another entire window

The window must fill the device’s screen Therefore, its size and position must be iden‐tical to the size and position of the screen This is done by setting the window’s frame

to the screen’s bounds as the window is instantiated (and I’ll explain later in this chapterwhat “frame” and “bounds” are):

UIWindow* w = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

The window must persist for the lifetime of the app To make this happen, the appdelegate class has been given a window property with a strong retain policy As the app

launches, UIApplicationMain (called in the main function in main.m) instantiates the

app delegate class and retains the resulting instance This is the app delegate instance;

it is never released, so it persists for the lifetime of the app The window instance isassigned to the app delegate instance’s window property; therefore it, too, persists for thelifetime of the app

You will typically not put any view content manually and directly inside your mainwindow Instead, you’ll obtain a view controller and assign it to the main window’s root-ViewController property This causes the view controller’s main view (its view) to bemade the one and only immediate subview of your main window — the main window’s

root view All other views in your main window will be subviews of the root view Thus,the root view is the highest object in the view hierarchy that the user will usually see.There might be just a chance, under certain circumstances, that the user will catch aglimpse of the window, behind the root view; for this reason, you may want to assign

the main window a reasonable backgroundColor But this seems unlikely, and in generalyou’ll have no reason to change anything about the window itself.

Your app’s interface is not visible until the window, which contains it, is made the app’skey window This is done by calling the UIWindow instance method makeKeyAnd-Visible

All of the configuration that I’ve just described is trivial to perform, because the Xcodeapp templates implement all of it for you:

App with a main storyboard

If your app has a main storyboard, as specified by its Info.plist key “Main storyboard

file base name” (UIMainStoryboardFile) — the default for most Xcode 5 apptemplates, except the Empty Application template — then UIApplicationMaininstantiates UIWindow with the correct frame and assigns that instance to the appdelegate’s window property It also instantiates the storyboard’s initial view controllerand assigns that instance to the window’s rootViewController property All of that

happens before the app delegate’s

application:didFinishLaunchingWith-Options: is called (Appendix A)

Finally, UIApplicationMain calls makeKeyAndVisible to display your app’s inter‐face This in turn automatically causes the root view controller to obtain its mainview (typically by loading it from a nib), which the window adds as its own root

view That happens after application:didFinishLaunchingWithOptions: is

called

App without a main storyboard

If your app has no main storyboard, then creation and configuration of the windowmust be done in some other way Typically, it is done in code You can see this in aproject generated from the Empty Application template, where all the configurationI’ve just described is performed explicitly, in code, in application:didFinish-LaunchingWithOptions:, like this:

self.window =

[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

// Override point for customization after application launch.

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

It is extremely improbable that you would ever need to subclass UIWindow If, however,you wanted to create a UIWindow subclass and make an instance of that subclass your

app’s main window, then how you proceed depends on how the window is instantiated

in the first place:

App with a main storyboard

As the app launches, after UIApplicationMain has instantiated the app delegate, itasks the app delegate instance for the value of its window property If that value is

The Window | 5

nil, UIApplicationMain instantiates UIWindow and assigns that instance to the

app delegate’s window property If that value is not nil, UIApplicationMain leaves

it alone and uses it as the app’s main window Therefore, the way to instantiate aUIWindow subclass and use that instance as your app’s main window is to imple‐ment the getter for the app delegate’s window property in such a way as to generate

the UIWindow subclass instance exactly once (that is, instantiate the UIWindow

subclass only if you haven’t already done so), like this:

- (UIWindow*) window {

UIWindow* w = self->_window;

if (!w) {

w = [[MyWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self->_window = w;

}

return w;

}

App without a main storyboard

You’re already instantiating UIWindow and assigning that instance to the app del‐egate’s self.window, in code So instantiate your UIWindow subclass instead.Once the app is running, there are various ways to refer to the window:

• If a UIView is in the interface, it automatically has a reference to the window throughits own window property

You can also use a UIView’s window property as a way of asking whether it is ulti‐mately embedded in the window; if it isn’t, its window property is nil A UIViewwhose window property is nil cannot be visible to the user

• The app delegate instance maintains a reference to the window through its windowproperty You can get a reference to the app delegate from elsewhere through theshared application’s delegate property, and through it you can refer to the window:

UIWindow* w = [[[UIApplication sharedApplication] delegate] window];

• The shared application maintains a reference to the window through its Window property:

key-UIWindow* w = [[UIApplication sharedApplication] keyWindow];

That reference, however, is slightly volatile, because the system can create temporarywindows and interpose them as the application’s key window For example, while aUIAlertView is showing (Chapter 13), it is the application’s keyWindow

Experimenting With Views

In the course of this and subsequent chapters, you may want to experiment with views

in a project of your own Since view controllers aren’t formally explained until Chap‐ter 6, I’ll just outline two simple approaches

One way is to start your project with the Single View Application template It gives you

a main storyboard containing one scene with one view controller instance which itselfcontains its own main view; when the app runs, that view controller will become theapp’s main window’s rootViewController, and its main view will become the window’sroot view You can drag a view from the Object library into the main view as a subview,and it will be instantiated in the interface when the app runs Alternatively, you cancreate views and add them to the interface in code; the simplest place to do this, for now,

is the view controller’s viewDidLoad method, which has a reference to the view con‐troller’s main view as self.view For example:

- (void)viewDidLoad {

[super viewDidLoad];

UIView* mainview = self.view;

UIView* v = [[UIView alloc] initWithFrame:CGRectMake(100,100,50,50)]; v.backgroundColor = [UIColor redColor]; // small red square

[mainview addSubview: v]; // add it to main view

}

Alternatively, you can start your project with the Empty Application template It has

no xib or storyboard file, so your views will have to be created entirely in code The

Empty Application template does not supply any view controllers, and does not assignany view controller to the window’s rootViewController property This situation caus‐

es the runtime to complain when the application is launched: “Application windows areexpected to have a root view controller at the end of application launch.” A simplesolution is to put your code in the app delegate’s application:didFinishLaunching-WithOptions:, creating a minimal root view controller and accessing its main viewthrough its view property For example:

- (BOOL)application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

// (template code:)

self.window =

[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

// Override point for customization after application launch.

// (your code:)

self.window.rootViewController = [UIViewController new];

UIView* mainview = self.window.rootViewController.view;

UIView* v = [[UIView alloc] initWithFrame:CGRectMake(100,100,50,50)]; v.backgroundColor = [UIColor redColor]; // small red square

[mainview addSubview: v]; // add it to the main view

// (template code:)

Experimenting With Views | 7

Figure 1-1 Overlapping views

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Subview and Superview

Once upon a time, and not so very long ago, a view owned precisely its rectangular area

No part of any view that was not a subview of this view could appear inside it, becausewhen this view redrew its rectangle, it would erase the overlapping portion of the otherview No part of any subview of this view could appear outside it, because the view tookresponsibility for its own rectangle and no more

Those rules, however, were gradually relaxed, and starting in OS X 10.5, Apple intro‐duced an entirely new architecture for view drawing that lifted those restrictions com‐pletely iOS view drawing is based on this revised architecture In iOS, some or all of asubview can appear outside its superview, and a view can overlap another view and can

be drawn partially or totally in front of it without being its subview

For example, Figure 1-1 shows three overlapping views All three views have a back‐ground color, so each is completely represented by a colored rectangle You have no way

of knowing, from this visual representation, exactly how the views are related withinthe view hierarchy In actual fact, the view in the middle (horizontally) is a sibling view

of the view on the left (they are both direct subviews of the root view), and the view onthe right is a subview of the middle view

When views are created in the nib, you can examine the view hierarchy in the nib editor’sdocument outline to learn their actual relationship (Figure 1-2) When views are created

Figure 1-2 A view hierarchy as displayed in the nib editor

in code, you know their hierarchical relationship because you created that hierarchy.But the visible interface doesn’t tell you, because view overlapping is so flexible

To see an outline of a view’s subview hierarchy at runtime whilepaused in the debugger, use the debugger console to send the

recursiveDescription command to that view; for example, po [someView recursiveDescription]

Nevertheless, a view’s position within the view hierarchy is extremely significant For

one thing, the view hierarchy dictates the order in which views are drawn Sibling sub‐

views of the same superview have a definite order: one is drawn before the other, so ifthey overlap, it will appear to be behind its sibling Similarly, a superview is drawn beforeits subviews, so if they overlap it, it will appear to be behind them

You can see this illustrated in Figure 1-1 The view on the right is a subview of the view

in the middle and is drawn on top of it The view on the left is a sibling of the view inthe middle, but it is a later sibling, so it is drawn on top of the view in the middle and

on top of the view on the right The view on the left cannot appear behind the view on

the right but in front of the view in the middle, because those two views are subviewand superview and are drawn together — both are drawn either before or after the view

on the left, depending on the ordering of the siblings

This layering order can be governed in the nib editor by arranging the views in thedocument outline (If you click in the canvas, you may be able to use the menu items ofthe Editor → Arrange menu instead — Send to Front, Send to Back, Send Forward, SendBackward.) In code, there are methods for arranging the sibling order of views, whichwe’ll come to in a moment

Here are some other effects of the view hierarchy:

• If a view is removed from or moved within its superview, its subviews go with it

• A view’s degree of transparency is inherited by its subviews

• A view can optionally limit the drawing of its subviews so that any parts of them

outside the view are not shown This is called clipping and is set with the view’s

clipsToBounds property

Subview and Superview | 9

• A superview owns its subviews, in the memory-management sense, much as an

NSArray owns its elements; it retains them and is responsible for releasing a subviewwhen that subview ceases to be its subview (it is removed from the collection of thisview’s subviews) or when it itself goes out of existence

• If a view’s size is changed, its subviews can be resized automatically (and I’ll havemuch more to say about that later in this chapter)

A UIView has a superview property (a UIView) and a subviews property (an NSArray

of UIViews, in back-to-front order), allowing you to trace the view hierarchy in code.There is also a method isDescendantOfView: letting you check whether one view is asubview of another at any depth If you need a reference to a particular view, you willprobably arrange this beforehand as an instance variable, perhaps through an outlet.Alternatively, a view can have a numeric tag (its tag property), and can then be referred

to by sending any view higher up the view hierarchy the viewWithTag: message Seeingthat all tags of interest are unique within their region of the hierarchy is up to you.Manipulating the view hierarchy in code is easy This is part of what gives iOS apps theirdynamic quality, and it compensates for the fact that there is basically just a singlewindow It is perfectly reasonable for your code to rip an entire hierarchy of views out

of the superview and substitute another! You can do this directly; you can combine itwith animation (Chapter 4); you can govern it through view controllers (Chapter 6).The method addSubview: makes one view a subview of another; removeFrom-Superview takes a subview out of its superview’s view hierarchy In both cases, if thesuperview is part of the visible interface, the subview will appear or disappear; and ofcourse this view may itself have subviews that accompany it Just remember that re‐moving a subview from its superview releases it; if you intend to reuse that subview later

on, you will wish to retain it first This is often taken care of through a property with aretain policy

Events inform a view of these dynamic changes To respond to these events requiressubclassing Then you’ll be able to override any of these methods:

• didAddSubview: and willRemoveSubview:

• didMoveToSuperview and willMoveToSuperview:

• didMoveToWindow and willMoveToWindow:

When addSubview: is called, the view is placed last among its superview’s subviews;thus it is drawn last, meaning that it appears frontmost A view’s subviews are indexed,starting at 0, which is rearmost There are additional methods for inserting a subview

at a given index, or below (behind) or above (in front of) a specific view; for swappingtwo sibling views by index; and for moving a subview all the way to the front or backamong its siblings:

to cycle through it and remove each subview one at a time:

for (UIView* v in view.subviews)

[v removeFromSuperview];

Here’s an alternative way to do that:

[view.subviews makeObjectsPerformSelector:@selector(removeFromSuperview)];

Visibility and Opacity

A view can be made invisible by setting its hidden property to YES, and visible again

by setting it to NO This takes it (and its subviews, of course) out of the visible interfacewithout the overhead of actually removing it from the view hierarchy A hidden viewdoes not (normally) receive touch events, so to the user it really is as if the view weren’tthere But it is there, so it can still be manipulated in code

A view can be assigned a background color through its backgroundColor property Acolor is a UIColor; this is not a difficult class to use, and I’m not going to go into details

A view whose background color is nil (the default) has a transparent background It isperfectly reasonable for a view to have a transparent background and to do no additionaldrawing of its own, just so that it can act as a convenient superview to other views,making them behave together

A view can be made partially or completely transparent through its alpha property: 1.0means opaque, 0.0 means transparent, and a value may be anywhere between them,inclusive This affects subviews: if a superview has an alpha of 0.5, none of its subviews

can have an apparent opacity of more than 0.5, because whatever alpha value they have

will be drawn relative to 0.5 (Just to make matters more complicated, colors have analpha value as well So, for example, a view can have an alpha of 1.0 but still have atransparent background because its backgroundColor has an alpha less than 1.0.) Aview that is completely transparent (or very close to it) is like a view whose hidden isYES: it is invisible, along with its subviews, and cannot (normally) be touched

A view’s alpha property value affects both the apparent transparency of its backgroundcolor and the apparent transparency of its contents For example, if a view displays an

Visibility and Opacity | 11

image and has a background color and its alpha is less than 1, the background colorwill seep through the image (and whatever is behind the view will seep through both).

A view’s opaque property, on the other hand, is a horse of a different color; changing ithas no effect on the view’s appearance Rather, this property is a hint to the drawingsystem If a view completely fills its bounds with ultimately opaque material and itsalpha is 1.0, so that the view has no effective transparency, then it can be drawn moreefficiently (with less drag on performance) if you inform the drawing system of this fact

by setting its opaque to YES Otherwise, you should set its opaque to NO The opaque

value is not changed for you when you set a view’s backgroundColor or alpha! Setting

it correctly is entirely up to you; the default, perhaps surprisingly, is YES

Frame

A view’s frame property, a CGRect, is the position of its rectangle within its superview,

in the superview’s coordinate system By default, the superview’s coordinate system willhave the origin at its top left, with the x-coordinate growing positively rightward andthe y-coordinate growing positively downward

Setting a view’s frame to a different CGRect value repositions the view, or resizes it, orboth If the view is visible, this change will be visibly reflected in the interface On theother hand, you can also set a view’s frame when the view is not visible — for example,

when you create the view in code In that case, the frame describes where the view will

be positioned within its superview when it is given a superview UIView’s designatedinitializer is initWithFrame:, and you’ll often assign a frame this way, especially becausethe default frame might otherwise be {{0,0},{0,0}}, which is rarely what you want

Forgetting to assign a view a frame when creating it in code, and then

wondering why it isn’t appearing when added to a superview, is a

common beginner mistake A view with a zero-size frame is effective‐

ly invisible If a view has a standard size that you want it to adopt,

especially in relation to its contents (like a UIButton in relation to its

title), an alternative is to send it the sizeToFit message

We are now in a position to generate programmatically the interface displayed in

Figure 1-1:

UIView* v1 = [[UIView alloc] initWithFrame:CGRectMake(113, 111, 132, 194)]; v1.backgroundColor = [UIColor colorWithRed:1 green:.4 blue:1 alpha:1];

UIView* v2 = [[UIView alloc] initWithFrame:CGRectMake(41, 56, 132, 194)];

v2.backgroundColor = [UIColor colorWithRed:.5 green:1 blue:0 alpha:1];

UIView* v3 = [[UIView alloc] initWithFrame:CGRectMake(43, 197, 160, 230)];

Figure 1-3 A subview inset from its superview

v3.backgroundColor = [UIColor colorWithRed:1 green:0 blue:0 alpha:1];

Bounds and Center

Suppose we have a superview and a subview, and the subview is to appear inset by 10points, as in Figure 1-3 The utility function CGRectInset makes it easy to derive onerectangle as an inset from another, so we’ll use it to determine the subview’s frame But

what rectangle should this be inset from? Not the superview’s frame; the frame repre‐

sents a view’s position within its superview, and in that superview’s coordinates What we’re after is a CGRect describing our superview’s rectangle in its own coordinates,

because those are the coordinates in which the subview’s frame is to be expressed TheCGRect that describes a view’s rectangle in its own coordinates is the view’s boundsproperty

So, the code to generate Figure 1-3 looks like this:

UIView* v1 = [[UIView alloc] initWithFrame:CGRectMake(113, 111, 132, 194)]; v1.backgroundColor = [UIColor colorWithRed:1 green:.4 blue:1 alpha:1];

UIView* v2 = [[UIView alloc] initWithFrame:CGRectInset(v1.bounds, 10, 10)]; v2.backgroundColor = [UIColor colorWithRed:.5 green:1 blue:0 alpha:1];

[mainview addSubview: v1];

[v1 addSubview: v2];

You’ll very often use a view’s bounds in this way When you need coordinates for drawinginside a view, whether drawing manually or placing a subview, you’ll often refer to theview’s bounds

Bounds and Center | 13

Figure 1-4 A subview exactly covering its superview

Interesting things happen when you set a view’s bounds If you change a view’s bounds

size , you change its frame The change in the view’s frame takes place around its cen‐

ter, which remains unchanged So, for example:

UIView* v1 = [[UIView alloc] initWithFrame:CGRectMake(113, 111, 132, 194)]; v1.backgroundColor = [UIColor colorWithRed:1 green:.4 blue:1 alpha:1];

UIView* v2 = [[UIView alloc] initWithFrame:CGRectInset(v1.bounds, 10, 10)]; v2.backgroundColor = [UIColor colorWithRed:.5 green:1 blue:0 alpha:1];

10 points back onto the left, right, top, and bottom of the subview’s frame

When you create a UIView, its bounds coordinate system’s {0,0} point is at its top left

If you change a view’s bounds origin, you move the origin of its internal coordinate

system Because a subview is positioned in its superview with respect to its superview’scoordinate system, a change in the bounds origin of the superview will change theapparent position of a subview To illustrate, we start once again with our subview insetevenly within its superview, and then change the bounds origin of the superview:

UIView* v1 = [[UIView alloc] initWithFrame:CGRectMake(113, 111, 132, 194)]; v1.backgroundColor = [UIColor colorWithRed:1 green:.4 blue:1 alpha:1];

UIView* v2 = [[UIView alloc] initWithFrame:CGRectInset(v1.bounds, 10, 10)]; v2.backgroundColor = [UIColor colorWithRed:.5 green:1 blue:0 alpha:1];

[mainview addSubview: v1];