iOS编程学习第三版：Object C与App开发指南

4星 · 超过85%的资源需积分: 9 115 浏览量更新于2024-07-23 1 收藏 11.37MB PDF 举报

"Learning iOS Programming 3rd Edition 是一本由 Alasdair Allan 撰写的英文书籍，主要介绍 iOS 应用程序开发以及 Object C 语言的使用。这本书于2013年3月出版，由 O'Reilly Media 出版。内容涵盖了iOS编程的基础到高级主题，适合教育、商业或销售推广使用。此外，该书还提供了在线版本，并设有专门的错误报告系统以保持内容的准确性和更新。" 《Learning iOS Programming 第三版》是iOS开发者入门和进阶的重要参考书籍，作者Alasdair Allan以其丰富的经验和深入的理解，引导读者掌握Apple的移动平台开发技术。本书特别关注Objective-C编程语言，这是一种强大的面向对象的语言，是iOS开发的核心工具。书中可能包括以下关键知识点： 1. **Objective-C基础**：介绍Objective-C的基本语法，包括类、对象、消息传递、属性等概念，以及如何创建和使用这些元素来构建应用程序。 2. **Cocoa Touch框架**：Cocoa Touch是iOS开发的核心框架，书中会讲解如何使用它来实现用户界面设计，如按钮、滑块、标签等控件的使用。 3. **Xcode集成开发环境**：学习使用Xcode进行项目设置、代码编写、调试和构建应用程序的全过程。 4. **iOS应用架构**：讲解Model-View-Controller (MVC)架构模式，以及如何在iOS项目中实现和利用这一模式。 5. **数据持久化**：包括使用SQLite数据库存储应用程序数据，以及Core Data框架的使用方法。 6. **网络编程**：讲解如何在iOS应用中实现网络通信，包括HTTP请求、JSON解析以及使用URLSession。 7. **多线程**：讨论GCD（Grand Central Dispatch）和Operation Queues，用于优化应用程序性能和用户体验。 8. **动画与图形**：介绍Core Animation和Core Graphics库，用于创建复杂的动态效果和自定义视图。 9. **用户接口设计**：包括Auto Layout和Size Classes，以适应不同屏幕尺寸和设备方向的适配策略。 10. **推送通知**：如何集成Apple Push Notification Service (APNS)为用户提供实时更新。 11. **测试与性能优化**：涵盖单元测试、UI测试以及性能分析和优化的方法。 12. **App Store发布**：指导读者如何完成应用程序的签名、打包，以及提交至App Store的过程。 13. **最新API和技术**：由于书籍是2013年出版，可能会包含当时最新的iOS SDK特性，但可能不包含后来的iOS版本更新。通过阅读《Learning iOS Programming 第三版》，读者不仅可以了解Objective-C编程语言，还能获得实际开发iOS应用的实践经验，从而为成为一名成功的iOS开发者打下坚实基础。同时，读者可以通过O'Reilly提供的在线资源获取最新的修订信息和错误报告，确保学习的内容与时俱进。

from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Pro‐

fessional, Microsoft Press, Sams, Que, P

eachpit Press, Focal Press, Cisco Press, John

Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT

Press, 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.

Acknowledgments

Books do not write themselves, especially the third editions, and especially the third

edition of your first book. After fixing everything you felt was wrong with it in the

second edition, at least to your own satisfaction, the prospect of doing it all again to

keep up with moving technology is daunting. It’s a horrifying prospect, and a harder

job than just sitting down and writing a new book from scratch. I’d therefore like to

thank my editors, Brian Jepson and Shawn Wallace, for prodding and poking until I

actually picked up the manuscript once more and wrote something. I’d also like to thank

my long-suffering wife, Gemma Hobson. I’m not entirely sure why she lets me keep

writing; it’s almost certainly nothing to do with the royalty checks. Finally to my son

Alex, who is still young enough that he’s not entirely sure what Daddy is doing, although

he’s moved on a fair way since the first edition was written and can now read and write

a few words of his own. Sorry for being so grumpy while I went about the whole business.

xiv | Preface

It seemed that the users of the applications disagreed. It’s arguable why this is the case,

but it

’s very hard to make native-looking web applications that can be reused across

many different platforms, though it is possible. Just as applications on the Mac desktop

that have been ported from Windows tend to stand out like a sore thumb by not quite

working as the user expects, web applications, especially those that are intended to be

used across different platforms, tend to do the same.

Just to be clear, this isn’t a criticism of HTML, CSS, and JavaScript. The Web’s technology

stack is solid and maturing, and the attraction of having a cross-platform code base is

going to be immediately obvious to you as a developer. However, to your users, it’s not

so obvious. Most of the arguments that are put forth in support of using web technol‐

ogies, or other non-native frameworks, are from a developer’s perspective. While that

doesn’t make them invalid, you should take a serious look at those arguments from a

user’s perspective, because none of them really address their main concern: usability.

Consumers won’t buy your application on their platform just because you support other

platforms; instead, they want an application that looks like the rest of the applications

on their platform, that follows the same interface paradigms as the rest of the applica‐

tions they’re used to, and that is integrated into their platform.

If you integrate your application into the iOS ecosphere, make use of the possibilities

that the hardware offers, and make sure your user interface is optimised for the device,

the user experience is going to be much improved. All of this is possible using web

technologies, but most of the time it’s actually really hard to write non-native applica‐

tions that work well across multiple platforms. It’s harder still to make them look native

on half a dozen different platforms.

Why Write Native Applications?

The obvious reason to use the native SDK is to do things that you can’t do using web

technologies. The first generation of augmented reality applications is a case in point;

these needed close integration with the iPhone’s onboard sensors (e.g., GPS, acceler‐

ometer, digital compass, and camera) and wouldn’t have been possible without that

access.

Although the Safari browser on iOS supports the geolocation capabilities HTML 5 pro‐

vides, this doesn’t alleviate the problem entirely. It’s doubtful that all platform-specific

hardware is going to get the same sort of treatment in HTML 5, so it’s unlikely that you

will see the arrival of augmented reality web applications.

2 | Chapter 1: Why Go Native?

If you are coming from a web development background, you may be

terested in the cross-platform PhoneGap framework. This framework

provides native wrapper classes and allows you to build native appli‐

cations in HTML/JavaScript on a range of mobile platforms. One of the

platforms it targets is the iOS.

Sometimes it’s not about doing things that can’t be done; it’s about doing things faster,

and doing clien

t-side error handling. For instance, the Apple iTunes and App Store

applications that are provided with the iOS are actually web applications wrapped inside

native applications. Just like the iTunes and App Stores on the Mac desktop, the main

panel you see is actually just a web page, but the surrounding infrastructure is a native

application. This means that while the application can’t do a lot without an Internet

connection, it can at least start up cleanly.

But those are extreme examples. A lot of the applications in the App Store combine

remote data and native interfaces. Without access to the network, some of the UI is

generally disabled. However, native applications can be built to degrade gracefully when

the device’s network connection disappears or if it was never present in the first place.

The user can still use the bits of the application that don’t need a network connection

to work.

Sometimes it’s also about what an application doesn’t need. If it doesn’t need a network

connection, the idea that your phone needs to be connected to the network to use it,

sucking extra battery power in the process, is wasteful. Even when it is connected, the

device isn’t always connected to a fast Internet connection. Anything you can do to

minimize the amount of data you need to suck down the data connection will improve

users’ interaction with your application. That means generating your user interface lo‐

cally, and populating it with data pulled from the Internet.

Network performance will affect the user’s perception of speed; rendering your user

interface while a web request is made to populate it allows your application to remain

responsive to user interaction even while it’s waiting for the network. That can only be

a good thing.

I haven’t even mentioned game development yet, and with Apple pitching the iPod touch

as “the funnest iPod ever,” that’s important. You cannot develop the sorts of games now

starting to appear on the App Store using web-based technologies. While this book

covers the basics of how to program for iOS devices, if you want to delve deeply into

game programming on the platform, I recommend Tap, Move, Shake: Turning Your

Game Ideas into iPhone & iPad Apps by Todd Moore (O’Reilly).

The Pros and Cons | 3

The Release Cycle

aul Graham, one of my favorite dispensers of wisdom, argues that the arrival of web-

based software has changed not just the user experience, but the developer experience

as well:

One of the most important changes in this new world is the way you do releases. In the

desktop software business, doing a release is a huge trauma, in which the whole company

sweats and strains to push out a single, giant piece of code. Obvious comparisons suggest

themselves, both to the process and the resulting product.

— From “The Other Road Ahead” by

Paul Graham

He is exactly right. Working in the cloud, you rarely make a software release in the old

sense of the word. Despite the benefits, I must admit I actually somewhat miss the “big

push” where, usually with a great deal of trepidation, you roll out a new, improved

version of a piece of software. However, one problem with writing native applications

is that we’ve made a return to the release cycle.

With web-based software you can make incremental releases, fixing bugs when and if

they occur. Native applications are far more like desktop software.

I cover the details of how to submit applications to the App Store in Chapter 13. However,

you should prepare yourself now for some amount of pain. The review process is no‐

toriously opaque, and it can and does take time. Plus, each of your applications must

go through it, not just when you initially submit it to the store, but also for each new

version you release. Typically, it can take up to seven days from submitting your appli‐

cation for it to be approved (or rejected) by the review team, although it can take much

longer. While some of my applications have sailed through the submission process in

only a couple of days, I have had applications in the review process for up to four months

before receiving approval.

If you’re interested in how the average review time for iOS and OS X

pplications changes with time, look at Average App Store Review

Times. The site, written by Dave Verwer, a well known iOS developer,

tracks the average App Store review times for apps submitted to both

the iOS and the Mac App Store using data crowdsourced from devel‐

opers on Twitter.

4 | Chapter 1: Why Go Native?

剩余451页未读，继续阅读

身份认证购VIP最低享 7 折!

30元优惠券

tomorjerry

粉丝: 0

iOS编程学习第三版：Object C与App开发指南

Learning GNU Emacs 3rd Edition: Mastering Emacs 21.3 on Mac, Windows, Linux

Learning Python 3rd Edition：入门指南

Learning Python 3rd Edition: 英文PDF教程

Learning iOS Programming 3rd Edition-- object-c 和 xcode4的学习文档

Learning iOS Programming, 2nd Edition.pdf

Core Python Applications Programming 3rd Edition

Learning Swift, 3rd Edition

Learning OpenStack Networking 3rd Edition

Learning Swift, 3rd Edition_Building Apps for macOS, iOS, and Beyond-OReilly2018

Core Python Applications Programming 3rd Edition Python核心编程 第三版 英文原版

最新资源

Core Python Applications Programming 3rd Edition Python核心编程第三版英文原版