iOS编程第三版：Xcode 4与Objective-C实战指南

5星 · 超过95%的资源需积分: 9 58 浏览量更新于2023-06-13 1 收藏 11.37MB PDF 举报

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

领优惠券(最高得80元）

资源详情

资源推荐

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页未读，继续阅读

jeson504876302

粉丝: 2
资源: 11

会员权益专享

iOS编程第三版：Xcode 4与Objective-C实战指南

Beginning ios programming with Swift-1

Programming iOS 11 - Matt Neuburg

Mastering iOS 11 Programming, 2nd Edition 2017年出版553页

ios 如何引入 linphone-sdk

ios curl 编译--with-openssl

beginning ios 14 programming with swift

xcode创建iOS模拟器

xcode怎么学习c++

libjpeg-turbo 编译生成iOS库

Qt编写和执行Object-C代码

dockerfile 基于mac镜像，搭建基于xcode 编译IOS 的环境

cordova ios vue xcode

ionic ios 测试打包发布

iOS12-Swift5-Xcode10-如何直接在Storyboard的attributes inspector上给view设圆角和阴影

vscode配置ios环境

xcode ios17.0真机调试包

cmake-ios-demo

xcode的edit中的to objectc arc

ios使用xcode离线打包

学习ios开发最好的方法是什么？

会员权益专享

最新资源