私人的

最近有关于使用私有iPhone API的讨论很多首先使用谷歌手机公开承认使用一个私人API访问接近传感器,然后再与兰登富勒的拒绝申请的举报从App Store出来使用私有Cover Flow框架,实际上Fuller从头开始创建自己的Cover Flow实现因为iPhone的系统实现没有公共API。

软件平台提供了许多在环境中运行的软件可以调用的功能公共API(应用程序编程接口)是这些功能的列表,这些功能被记录并支持供第三方编写平台软件使用完整的功能列表(或方法图书馆构架或平台上可用的任何特定技术术语通常(如果不是总是)a公共API中发布的函数不在公共API中的函数称为私有API或SPI(系统编程接口)。

在iPhone OS上,如Mac OS X,API分为框架公共框架是那些为第三方开发人员提供公共API的框架私有框架是那些没有任何公共API的框架但是,即使是公共框架,有时也会包含一些私有API调用。

至少在Cocoa和Cocoa Touch中,没有真正的技术障碍阻止第三方软件调用私有API公共/私人区别是社会障碍,而不是技术障碍The difference, from a developer’s point of view, is that public APIs are more than just a list of what works now; they constitute a promise, a commitment, from the platform provider of what will continue to work in the future.

私有API调用将来可能会发生变化或消失私有API是私有的有一些原因可能就是这样这里留下来,平台供应商还没有到处记录它但它可能很容易成为供应商打算完全取代的权宜之计当有问题的平台供应商是一个不透明的实体,如Apple,你只是不知道。

对于iPhone,还有App Store许可协议的附加问题,在使用私有API时无法更明确:

3.3.1 Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs.

除了App Store指南之外,我对私有API的使用并不是绝对的如果您作为开发人员想要使用私有API- 应用程序的必要方面,并在实际调用它们之前注意检查它们的存在,如果它们没有,则编写优先失败的代码,那么也许它没问题。

但如果你的应用程序要看on private APIs, or you don’t test for their existence before calling them, you risk having a mess on your hands (and your users’ hands) in the future, when a system update appears where the private APIs on which you’re relying are changed or removed.

谷歌手机就是一个可能正确做到这一点的例子 - 或者至少做一些不会出错的事情我公开使用的私有API是用于iPhone的接近传感器,用于启用“只需将手机放到耳边,等待哔哔声,并说出您的查询”功能他们已经实现了自己的代码来处理proximityStateChangedmessage; ifproximityStateChanged在未来的操作系统更新中消失,谷歌处理它的代码根本不会被调用电梯通话功能将不再有效,但应用程序不会崩溃谷歌手机不依赖于电梯通话功能 - 您可以点按一个按钮来手动启动语音提示关键是应该非常谨慎地处理私有API - 它们是与爆炸性材料相当的编程。

我一直对谷歌移动使用私有接近传感器API感兴趣的不是技术方面,而是社交方面:苹果是否有关于谷歌与典型iPhone开发人员使用私有API的双重标准的问题。

有些法则有待破解的理论

在我发表关于谷歌移动使用私有API的最初文章之后,埃里卡·萨杜恩在Ars Technica的Infinite Loop上发表了一篇文章。调查这个问题Sadun是一位着名的iPhone开发者,可以追溯到越狱时代,并且是最近发布的作者iPhone开发者的食谱由Addison Wesley出版。

Sadun在她的无限循环片中支持这样的理论:“开发人员使用非标准呼叫有两种截然不同的方式”(其中“非标准”是指“未发布或私有”)这些是:

链接到私有框架。This is the bad, the evil, the Sauron of App StoreApple offers two sets of frameworks, or libraries that contain linkable routines for developersThere are Public Frameworks, which are fine and dandy to link to, and Private Frameworks, which are not[...]

使用未发布的API。If linking to private frameworks is unacceptable, unpublished APIs play the role of a minor jaywalkingYou might get a ticket, a citation, and a talking to, but you’re not going to jail foreverThe App Store is absolutely littered with unpublished APIsI’ve learned to spot them pretty wellWhen you see applications doing things that you know they can do but that they’re not entirely supposed to be doing, you can lay odds that the developers have gently called unpublished but public routines.

这种区别对我来说很新颖而且,经过进一步考虑,我认为这是无稽之谈公共iPhone API是Apple在iPhone SDK中记录的那些其他所有内容都是私有的,无论是公共框架中的方法还是私有框架中的方法它们都是无证件的,同样可以随时更改,同样违反了iPhone SDK许可协议。

几天后,Sadun为Infinite Loop写了另一篇文章,“倾倒iPhone 2.2框架“,提供说明,说明如何提取列出iPhone SDK中许多私有API的Objective-C头文件她发布了这些头文件在她的个人网站上

Her header-dumping post does contain a cursory warning that the use of these APIs violates the SDK agreement, and that software that uses such APIs is subject to break under future iPhone OS releases, but there’s an implicit “Go ahead and use them in your own apps if you want to and it’ll probably work out just fine” attitude that pervadesWhy else publish such a piece if not to encourage the use of private APIs? And why not a single word encouraging developers to file Radar bugs requesting that desired private methods be made public in the future?

繁荣

这种对公共与私人之间分裂的普遍漠视在Sadun的书中有所体现The book contains an entire chapter on how to use the iPhone’s private Cover Flow framework(私人框架的使用,当然,用Sadun自己的话来说,“坏的,邪恶的,App Store的Sauron”。)章节介绍包含了比警告更多的鼓励:

Although Cover Flow is not officially included in the iPhone SDK, it offers one of the most beautiful features of the iPhone experienceWith Cover Flow, you can offer users a gorgeously intense visual selection that puts standard scrolling lists to shameThis chapter introduces Cover Flow and shows how you can use it in your application繁荣!

It is one thing for me to lecture in the abstract regarding the dangers of using private APIs — to warn against the fact that the underlying frameworks in the iPhone OS are undergoing significant changes between releases, and that apps which make use of private APIs really are more likely to crash when running on future OS releases.

另一件事是能够指出发生这种情况的具体例子一个例子,比方说,Safari书包,来自O'Reilly的Safari Books Online服务的iPhone客户端。

当iPhone OS 2.2发布时,Safari Bookbag在发布时开始崩溃iPhone开发商Landon Fuller进行了调查,并且发现崩溃的来源是对Cover Flow框架中的方法的调用Apple在iPhone OS 2.1和2.2之间删除了:

It’s clear from the disassembly that Bookbag is using the private UICoverFlowLayer API当Apple发布iPhone OS 2.2时- [UICoverFlowLayer initWithFrame:numberOfCovers:]method was removed, and Safari Bookbag started crashing.

它结束了- [UICoverFlowLayer initWithFrame:numberOfCovers:]正是Erica Sadun的Cover Flow章节的方法iPhone开发者的食谱开始于。

如前所述,富勒是作者窥视,一个iPhone应用程序,提供Cover Flow风格的界面,用于浏览您的地址簿在App Store提交队列中等待33天后,Peeps最初被拒绝了由Apple使用私人Cover Flow API让拒绝值得注意的是Peeps使用私有框架富勒做了正确的事情:他从头开始编写自己的Cover Flow实现,而不使用任何私有API:

The last thing I would do is deliver time-bomb code to a paying customerPrivate API can be broken or removed at any time by the vendor, and relying on it is unfair to your customers — they rarely have any idea that the application they just purchased may not work next week, or next month.

So Fuller took the extra time to do the right thing and had his work rejected anyway because whoever it was at Apple who reviewed the submission saw “Cover Flow” and assumed, incorrectly, that it was using the private Cover Flow framework(富勒的故事有一个圆满的结局:Peeps被接受了周末进入App Store。)

鉴于Safari Bookbag的情况,并且可能是任何其他使用私有Cover Flow框架的应用程序iPhone开发者的食谱对于最初拒绝Peeps的App Store评论员来说,这不一定是不合理的假设不正确,不公平,令人沮丧,是的 - 但并非完全不合理Bookbag并不是唯一一个在此框架更改中被捕获的iPhone应用程序。以下是对Erica Sadun的博客的评论来自开发人员使用Sadun的Cover Flow代码编写一个名为Yoga Trainer Pro的应用程序目前在商店中的Yoga Trainer Pro版本在iPhone OS 2.2上崩溃(参见客户评论),开发人员提交的更新版本已被Apple拒绝,因为它继续使用私有Cover Flow框架。

私有iPhone API的使用越普遍,iPhone就越有可能成为用户抵制安装操作系统更新的平台,理由是以前的操作系统更新“破坏”了他们安装的第三方应用程序。

但是,尽管Erica Sadun关于使用私有API的判断可能是可疑的,但她并不是伪君子 - Sadun本人就是被誉为首席开发者Safari Bookbag确实如此。