• Complain

Comer Randy - Programming iOS 8: dive deep into views, view controllers, and frameworks

Here you can read online Comer Randy - Programming iOS 8: dive deep into views, view controllers, and frameworks full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. City: Sebastopol;California, year: 2015, publisher: OReilly Media, genre: Computer. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:

Romance novel Science fiction Adventure Detective Science History Home and family Prose Art Politics Computer Non-fiction Religion Business Children Humor

Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.

Comer Randy Programming iOS 8: dive deep into views, view controllers, and frameworks
  • Book:
    Programming iOS 8: dive deep into views, view controllers, and frameworks
  • Author:
  • Publisher:
    OReilly Media
  • Genre:
  • Year:
    2015
  • City:
    Sebastopol;California
  • Rating:
    5 / 5
  • Favourites:
    Add to favourites
  • Your mark:
    • 100
    • 1
    • 2
    • 3
    • 4
    • 5

Programming iOS 8: dive deep into views, view controllers, and frameworks: summary, description and annotation

We offer to read an annotation, description, summary or preface (depends on what the author of the book "Programming iOS 8: dive deep into views, view controllers, and frameworks" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.

Start building apps for iOS 8 with Apples Swift programming language. If youre grounded in the basics of Xcode and the Cocoa framework, this book provides a structured explanation of all essential real-world iOS app components. Through deep exploration and copious code examples, youll learn how to create views, manipulate view controllers, and use iOS frameworks for adding features such as audio and video, access to user calendars and photos, and tracking the devices location--Back cover.

Comer Randy: author's other books


Who wrote Programming iOS 8: dive deep into views, view controllers, and frameworks? Find out the surname, the name of the author of the book and a list of all author's works by series.

Programming iOS 8: dive deep into views, view controllers, and frameworks — read online for free the complete book (whole text) full work

Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Programming iOS 8: dive deep into views, view controllers, and frameworks" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.

Light

Font size:

Reset

Interval:

Bookmark:

Make
Programming iOS 8
Matt Neuburg
Preface

Aut lego vel scribo; doceo scrutorve sophian.

Sedulius Scottus

On June 2, 2014, Apples WWDC keynote address ended with a shocking announcement: We have a new programming language. This was surprising in several ways:

  • Apple buried the lede (or, looking at it another way, they saved the biggest until last).
  • Like the weather, everyone had long talked about the need for a new language to replace Objective-C, but no one believed Apple would ever actually do anything about it.
  • How on earth had Apple done all the groundwork needed to design, prepare, and implement a whole new programming language without the least rumor leaking out?

Having picked themselves up off the floor, developers immediately began to examine this new language Swift studying it, critiquing it, and deciding whether to adopt it. My own first move was to translate all my existing iOS apps into Swift; this was enough to convince me that, for all its faults, Swift deserved to be adopted by new students of iOS programming, and that my books, therefore, should henceforth assume that readers are using Swift.

Therefore, Swift is the programming language used throughout this book. Nevertheless, the reader will also need some awareness of Objective-C (including C). There are two chief reasons for this:

  • The Foundation and Cocoa APIs, the built-in commands with which your code must interact in order to make anything happen on an iOS device, are still written in C and Objective-C. In order to interact with them, you have to know what those languages would expect. For example, in order to pass a Swift array where an NSArray is expected, you need to know what consitutes an object acceptable as an element of an Objective-C NSArray.
  • Swift cant do everything that C and Objective-C can do. Apple likes to claim that Swift can access all of the Cocoa Touch frameworks and that it constitutes a complete replacement for both the C and Objective-C languages Im quoting from the Xcode 6 release notes but the truth is that Swift cant interface directly with every facet of the Cocoa Touch APIs. Swift cant form a C function or obtain the address of such a function; Swift cant declare a property @dynamic in the Objective-C sense; in certain situations, Swift can be prohibitively slow in comparison to equivalent Objective-C code; and so on. Thus, I occasionally show some Objective-C code in this edition, in order to do things that Swift alone cant accomplish.

Because Swift is new, I have had to settle on my own conventions for presenting and describing code. The most important question has been how to state the name of a method. My solution is to give the methods Objective-C name . As an example, what is the name of the method that you call when you set a value using keyvalue coding? The actual call, in Swift, would be something like this:

someObject.setValue(someValue, forKey:"someKey")

But when I give the name of the method being called here, that name is setValue:forKey:. This choice has several advantages:

  • It is clear, compact, and predictable, being formed according to perfectly consistent and well-established rules.
  • For those who have been programming in Objective-C all these years, its what were used to. The way Objective-C methods are named is a thoroughly entrenched convention; even Swift programmers must accommodate themselves to seeing Objective-C method names plastered all over the Internet and Apples own documentation.
  • That name is in fact its name as far as Objective-C and the Cocoa APIs are concerned, and even in Swift you would need to know this. For example, if you wanted to specify this method when providing its name as a selector parameter (or as a string representing a selector), it is the Objective-C name that you would have to provide.
  • The translation from the Objective-C name into practical Swift syntax is mechanical and unambiguous the first colon is replaced by parentheses embracing the first parameter plus the names and values of any remaining parameters and is something that every Swift programmer needs to know how to do.

Similarly, I will speak of the setValue: parameter, even though, in an actual Swift method call, the name of that parameter appears before the parentheses, with no colon.

The grand exception to this rule is my treatment of initializers. Here, the difference between Objective-C and Swift is greater than a simple shorthand can readily encompass, so I give the initializers name as you would implement it . For example, in Objective-C, the default initializer for a UIView is initWithFrame:. In this book, I will call that initializer init(frame:). The same thing applies to what in Objective-C would be class factory methods with a corresponding initializer: when I want to mention what in Objective-C would be the UIImage class factory method imageNamed:, Ill call it init(named:).

This treatment of initializer names has the great virtue that the name clarifies instantly that such a method is an initializer. Swift effectively abolishes class factory methods and brings such methods into the fold of formal initializers; my treatment of their names is a way of supporting and adopting that innovation.

Again, this convention requires some mental translation on the readers part, because in Swift the way you would name an initializer when you implement it is not the same as the way you would name it when you call it. If you were to override this method in a UIView subclass, youd override init(frame:); but if you were to call it to create a new UIView, youd say UIView(frame:). This mental translation, however, is hardly objectionable, as it is a practical fact to which every Swift user is already habituated.

So much for Swift. A new language is big news, but Swift is not the only big news connected with iOS 8. Nor is it the only welcome news. Ive been arguing for years that Apple needs to check the rampant growth and evolution of the basic Cocoa Touch APIs and concentrate, for one release at least, on rationalizing the changes that have accumulated, often seemingly by random accretion, over the years. iOS 8 appears to do exactly that. To give just a couple of obvious examples:

  • An app, when it rotates to compensate for a change in the orientation of the device, no longer does so by applying a transform to the root view. Instead, in iOS 8, rotation is a feature of the app as a whole the window itself, and indeed the screen, is resized.
  • A popover, in iOS 8, is just a variety of presented view controller. Not only does this vastly simplify popover management (whose wretchedness Ive been complaining about since the first edition of this book), but also it eliminates the need, in a universal app, for large chunks of conditional code depending on what type of device the app runs on: a presented view controller is legal everywhere. Similarly, alerts and action sheets are now forms of presented view controller.

Such rationalization permeates iOS 8, and I have eagerly adopted it, even where the prior approach is not yet deprecated. You could still create popovers and alerts the way we created them in iOS 7 and before; and obviously if you wanted your code to run on iOS 7 as well as iOS 8, youd have to. But in this edition I behave, in effect, as if the old way didnt exist. Its the business of this edition to teach iOS 8, not to help you write backwards-compatible code; if you want to know how to deal with popovers (or anything else) in iOS 7 or before, consult an earlier edition of the book.

Next page
Light

Font size:

Reset

Interval:

Bookmark:

Make

Similar books «Programming iOS 8: dive deep into views, view controllers, and frameworks»

Look at similar books to Programming iOS 8: dive deep into views, view controllers, and frameworks. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.


Reviews about «Programming iOS 8: dive deep into views, view controllers, and frameworks»

Discussion, reviews of the book Programming iOS 8: dive deep into views, view controllers, and frameworks and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.