• IOS开发指南(中英版)官方文档,吐血推荐,极好的资料!
  • iOS开发文档(中文)

    2015-09-30 16:55:59
     做这个笔记本主要是重新熟悉一下iOS开发,因为之前学的东西太乱太杂,没有个详细的学习顺序,所以正好将苹果官方的iOS开发文档进行一下翻译,达到学习和锻炼英语的能力。苹果iOS开发原网址是:...
         本文主要转载:http://ourcoders.com/thread/show/117/

    目的

            做这个笔记本主要是重新熟悉一下iOS开发,因为之前学的东西太乱太杂,没有一个详细的学习顺序,所以正好将苹果官方的iOS开发文档进行一下翻译,达到学习和锻炼英语的能力。苹果iOS开发原网址是:https://developer.apple.com/library/ios/navigation/#section=Resource%20Types&topic=Getting%20Started.

    文档结构介绍

            当我们打开上面的网址时,显示的是如下所示的结构:


               然后我们看,文档内容区域的左侧导航栏区域,这里揭示了文档库的结构,如下图区域1。
               区域1的介绍:       
    •  Getting Started —— 新手入门,一般来说,是给完全的新手看的。建议初学者看看,这里面有一些建立观念的东西,有了这些建立观念的东西,后面的学习就比较容易了。
    •  Guides —— 指南,指南是Xcode里面最酷最好的部分,学会看指南则大多数情况完全不用买书。Xcode文档里面的指南,就是一个一个问题的,从一个问题,或者系统的一个方面出发,一步一步详细介绍怎么使用Cocoa库的文档。一般程序员比较熟悉的是Reference,就是你查某个类、方法、函数的文档时候,冒出来的东西。那些其实是一点一点的细碎知识,光看那些东西就完全没有脉络。而Guides就是帮你整理好的学习的脉络。
    • Reference —— 参考资料。一个一个框架一个一个类组织起来的文档,包含了每个方法的使用方法。
    •  Release Notes —— 发布说明。一个iOS新版本带来了哪些新特性,这样的信息,熟悉新iOS,比较不同iOS版本API不同,都需要参考这些文档。
    •  Sample Code —— 示例代码。苹果官方提供的一些示例代码,帮助你学习某些技术某些API。非常强烈建议学习的时候参考,一方面光看文档有时候还是很难弄明白具体实现是怎么回事儿。另外一方面这些示例代码都是苹果的工程师写的,你从示例代码的变迁可以看到苹果官方推荐的代码风格流变。
    •  Technical Notes —— 技术说明。一些技术主题文章,有空的时候可以浏览一下。往往会有一些收获。
    • Technical Q&A —— 常见技术问答。这是技术社区里面一些常见问题以及回答的整理。
    • Video —— 视频。目前主要是WWDC的视频,实际上是登录到开发者网站上去浏览的,这里就是快捷方式。想深入学习的话,一定不能错过,大量的看,不仅可以学好技术,还可以练好英文。
               总结一下,这里面的Reference、Release Notes、Sample Code、Technical Notes、Technical Q&A,一般来说只是备查的。主要要看的是Getting StartedGuides 
               然后下面是Topics,也就是话题,被分为:
    • Audio & Video —— 音视频
    • Languages & Utilities —— 语言和工具,Objective-C的一些知识,App Store的管理工具等。
    • Mathematical Computation —— 数学计算。
    • Xcode
    • Data Management —— 数据管理。
    • General —— 一般性的问题。
    • Graphics & Animation —— 图形和动画。
    • Networking & Internet —— 网络问题。
    • Performance —— 性能。
    • Security —— 安全。
    • User Experience —— 用户体验。
                    这里不多说,大多数都是顾名思义的问题。但是值得一提的就是有很多初学者说,我想好好了解下图形和动画的技术,但是文档里面找不到,这就只能说,你睁着大大的眼睛,为毛左看右看
              看不到呢?
              最下面是Frameworks(框架),分为:
    • Cocoa Touch Layer
    • Media Layer
    • Core Services Layer
    • Core OS Layer
                    这里我们先不讨论这个东西,后面会仔细讲。
                   总体来说左边的导航区域就是用三种不同的维度,来帮你精准定位你需要的内容。
                   现在我们看内容区域的右边。注意上面的文档过滤器。如下图:
                    

                   假设,你现在想看关于性能方面的Guides,那么你应该做的就是在左面的导航,点击Topics -> Performance,然后在右边的文档过滤器上面输入Guides。或者你也可以在左边的导航,点击
             Resource Types -> Guides,然后在文档过滤器里面输入 Performance。
                  熟练使用导航和文档过滤器的话,学习就会非常方便快捷。

     文档导读

              前面我们讲Xcode的文档结构是在介绍如何能够快速定位到你要找的内容。但是很多人的问题可能是一开始就根本不知道要读什么。
              这里我们就介绍自学iOS开发应该遵循或者说我们推荐的必读文档的阅读顺序。
              阅读顺序:
        1. 《马上着手开发 iOS 应用程序 (Start Developing iOS Apps Today)》
        2. 《Your First iOS App》
        3. 《Your Second iOS App: Storyboards》
        4. 《Your Third iOS App: iCloud》
        5. 《iOS Technology Overview》
        6. 《iOS Human Interface Guidelines》
        7. 《Learning Objective-C: A Primer》和《Programming with Objective-C》
        8. 《iOS App Programming Guide》
        9. 《View Programming Guide for iOS》和《View Controller Programming Guide for iOS》
        10. 《Table View Programming Guide for iOS》
          首先应该看的是Getting Started里面的《马上着手开发 iOS 应用程序 (Start Developing iOS Apps Today)》(中英文版本皆有,苹果官方的翻译)。这个文档讲的很浅,但是是建立概念的文档,     你以后在开发里面经常遇到的概念,在这里都有包含,特别注意是,这个文档看起来简单,但是每页下面的相关文章,不是选读,都是必读。
           即使是很多做了iOS开发很久的同学,其实也有很多概念上的误解,现代程序开发越来越简单,工具越来越强大,往往有些误解也可以继续前行,但是实际上不建立扎实的基础是很吃亏的,往往后    
    面理解和解决一个不难解决小问题都要付出很多辛苦。
         阅读这个文档的目的和检测标准是,以后你看到iOS开发中的基本概念,都大致所有了解。
         读完《马上着手开发 iOS 应用程序 (Start Developing iOS Apps Today)》后,应该去看Your XXX iOS App系列这个系列不是什么很难的文章,你也不必着急先去学习Objective-C,学什么C语言就更不要着急。我推荐的学习方法是有成就的逐步学习法。在学习系统体系架构、Objective-C之前,你可以先按照文档写一个全天下最简单的App,完成学习过程中第一个里程碑。在这个过程中不用担心有什么疑问,有什么不懂,先照着做就是。
         阅读这三个文档的目的和检测标准是,把这三个Demo App做出来在模拟器上跑起来。
         在这个过程中,你对开发工具的基本认识就建立起来了,也有了成就感,去了魅(就是消除了对iOS开发的神秘感)。
         再往下,建议你去看《iOS Technology Overview》(iOS技术概览),iOS不是一个技术,而是一堆技术,前一篇讲到文档导航区域的分类,框架分类的时候,我说不细讲的原因就在于此,你要做一个动画应该用Core Animation还是OpenGL?你要做一些文本相关操作应该用Core Text还是什么,就是看这里。
         学习现代的程序开发,语言和框架并重。我们Tiny4Cocoa叫做这个名字的原因就是,iOS/Mac开发者的代表往往就是这个Cocoa框架,就是这个SDK。大多数你所需要的功能都躺在框架里面,你知道框架的结构,你才知道怎么去寻找相关的技术资料。
         阅读这个文档的目的和检测标准是,遇到具体问题,知道应该去看哪方面的文档。
         再下来,建议阅读的是《iOS Human Interface Guidelines》,Mac/iOS平台虽然也是百花齐放各类程序、App都有,但是总体看来,大多数优秀App的UI看起来都和整个系统很协调。这和Windows以及很多其他平台完全不同。这是为什么呢?
        很大程度就归功于《Human Interface Guidelines》文化,所谓Human Interface Guidelines就是用户界面的规范,在苹果它还专门有一个缩写叫做HIG,是天条一样的东西。所有的App都推荐遵循HIG,遵循了HIG,你做的东西用户看起来就会觉得和整个系统很协调。即使是你要做一些创新的设计,你势必会打破HIG的限制,但是你这个时候仍旧应该遵循HIG的精神。
         此外,你阅读HIG的很重要一点是了解整个UI结构和UE行为的逻辑机理,这样才能在你设计界面的时候有所依据。
         阅读这个文档的目的和检测标准是,看到任何一个App,你可以知道它的任何一个UI是系统控件,还是自定义控件,它的层次关系等等。
         《Learning Objective-C: A Primer》是非常初级和简单的入门,适合先阅读。《Programming with Objective-C》超微复杂一点点,适合后阅读。
         一般人建议先学习语言,我反之建议先做了一个App,然后再学习语言。原因有几个,首先现代开发工具,往往不是用来开发控制台程序的,上来就会有框架,光懂语言不会使用IDE,甚至可能会更麻烦。再其次就是,其实现代语言发展到了面向对象以后,库往往比语言更复杂,更重要,或者说更多的时候,我们是在学习库,而不是语言,语言只是库的一个载体。
          比如,Delegate和Block等等都和Cocoa的UI异步机制关系紧密,光看代码,这些语言元素非常难以学习,也完全不知道其意义在哪里。
         阅读这个文档的目的和检测标准是,看得懂基本的Objective-C代码,方便后面的学习和阅读各种示例代码。
         《iOS App Programming Guide》基本上介绍的就是开发一个App的完整流程,包括App的生命周期、休眠、激活等等,里面介绍的细节颇多。正式开发第一个上线的App之前必看。或者开发了一个App,临到提交前必看才文档。
         阅读这个文档的目的和检测标准是,了解全部流程和很多细节问题。
         《View Programming Guide for iOS》和《View Controller Programming Guide for iOS》非常重要。View是整个图形界面里面最重要的概念。所有的图形、界面绘制都基于View。你看到的一切复杂的用户界面,就是各种不同的View的组合堆叠。
         View Controller是View和某种逻辑在一起的组合,本质上这种组合不是必须的,但是是大大降低编程复杂度的一种设计。很多人不懂什么是View什么是View Controller,这样写起代码来就很痛苦。
         阅读这个文档的目的和检测标准是,深刻理解什么是View,什么是View Controller,理解什么情况用View,什么情况用View Controller。
         UITableView是最重要的一个控件,是最常用的UI界面元素。在UICollectionView出现之前,大量的内容列表展示的自定义控件都是基于UITableView,比如很多书架、图片Grid其实都是UITableView做的。
         所以《Table View Programming Guide for iOS》非常重要,一定要好好阅读。
         阅读这个文档的目的和检测标准是,深刻理解UITableView/UITableViewController的理论和使用方法。
         我推荐的必读文档就这么多,仔细看的话,最多也就是今天就看完了。学习一个东西,如果有一点点耐心,有正确的方法其实不难,不是说脑子非要很聪明,大多数人都可以做到一个星期就学会iOS开发,其实就是读完这些文档,大多数人就会了。
         就像我强调了无数次,阅读英文文档不难,我自己从当年看英文文档非常吃力,必须查词典开始,认真的看英文文档,不会就查词典,一个多月过去,读英文文档就完全不需要查词典了。
         我们公司主程 @sycx 老师,也说他原来英语也很不好,甚至现在英语仍旧很烂,但是看英文文档完全没有问题,也就是几个星期的认真学习以后就突破了。
         其实学习iOS也如此。当然我不是说你看懂这10组文档就再也不用看别的了。而是说,如果你看懂了这10组文档,你就从初学者,或者是虽然会写一些程序,但是对iOS其实还不懂的状态,变成了一个入门者。
         我不希望这个文章可以一句一句的帮你学会iOS是什么,这个文章的目的是帮你快速入门。一旦你入门了,你再遇到问题该看什么,你就不需要我讲了,你自己就知道了。一旦入门了,你就会发现,Xcode里面别的文档讲的内容虽然不同,但是结构你已经很清楚了,你学习起来很方便。
         阅读本文的目的和检测标准是,遇到问题,知道看什么文档,想提升自己技术的时候,知道按照什么脉络自己组织阅读。
         

    如何查询文档

    最快捷的查询帮助文档的方法是不需要键入任何关键词的。你只需要在Xcode代码编辑器里,按住Option键,然后点击你想查询的关键词,就会获得关键词的帮助信息。如下图:

       

    帮助信息会包括,一些简单的描述、哪个iOS操作系统开始提供,头文件,参考文档。头文件和参考文档是可以直接点击的。

    即使你点击的关键字不是Cocoa库的内容,是自己代码里面的类或者方法,也可以获得相关的定义信息。如下图:


    与之相关的热键是Command键加鼠标点击,即可跳到任何一个类名或者方法名的所定义的头文件。

    快速查询帮助的另外一个方法是直接打开Quick Help栏,如下图,首先找到“右侧栏开关”,然后找到“Quick Help”开关即可打开。


    Quick Help栏的作用机制是,只要它在打开状态,只要输入光标在什么关键字上,Quick Help栏就会显示跟关键字相关的简要帮助信息,跟Option键加点击的信息基本一致,但可能略微丰富一点。

    写代码的时候,在大多数情况下,查询下快速帮助,看看头文件,就足以了。

    搜索帮助

    文档阅读界面最左面的上端的放大镜按钮就是搜索界面。下图是我们搜索uiimage,得到的搜索结果。


    首先值得注意的是,结果也是分类的,分为Reference、System Guides、Tools Guides、Sample Code这四类。类别很利于我们快速找到我们需要的信息。前面已经介绍过类别,跟那个基本一致,参照即可。

    另外需要注意的是,搜索框下面的选项,首先是Hits Must(什么样的结果才会命中),包含了三项:

    1. contain search term 这是最常见的就是结果包含搜索词
    2. start with search term 由搜索词开始
    3. match search term 必须完全匹配搜索词

    然后是Languages(语言选项),包含Javascript、C++、Java、Objective-C、C语言。

    然后是,Find in(在哪些文档库搜索),包含了你Xcode里面安装的全部文档库。

    阅读文档

    最后,我们简单介绍下怎么阅读文档。文档的阅读界面如下图:


    值得注意的是,标题下面这几样:

    1. Inherits from 继承关系,继承自
    2. Conforms to 遵循什么协议
    3. Framework 属于什么框架
    4. Availability 从什么iOS版本开始支持
    5. Declared in 头文件
    6. Related sample code 相关例子代码
    7. Companion guide 相关的指南(UIImage没有,很多其他的类有)

    在其次一个很重要的东西,其实是标题上面那一条窄窄的导航栏,那是一个多层树状导航栏,看文档的时候,可以点击那个栏的不同位置浏览。


    其实这个栏包含了整个文档库的组织结构树状图,可惜只有在这个界面才能浏览。有兴趣的可以慢慢浏览,里面信息量其实非常大。 
    展开全文
  • iOS开发文档英文对照翻译,帮助你快速学会看英文文档,如果你想尝试看原汁原味的英文文档,又感觉有困难,那这个就是你必备的资料。
  • 待分析的产品:石墨文档IOS客户端 作业地址: https://edu.cnblogs.com/campus/nenu/2016CS/homework/2505 第部分 调研, 评测 1.下载并使用,按照描述的bug定义,找3~5个功能性的比较严重的bug。请用专业的...

    待分析的产品:石墨文档IOS客户端

    作业地址:

    https://edu.cnblogs.com/campus/nenu/2016CS/homework/2505

     

    第一部分 调研, 评测

    1.下载并使用,按照描述的bug定义,找3~5个功能性的比较严重的bug。请用专业的语言描述(每个bug 不少于 40字),如有必要,请配图。

      下载了IOS客户端并进行了使用,界面简洁,扁平化的UI风格,符合当今APP设计的流行趋势,也契合IOS整体的系统风格;

      没有更多的花里胡哨,功能专注于文档和表格方面,能够让使用者更加专注于工作本身。在线编辑时较方便和简单,同时支持文字识别和语音速记;

      最惊喜的就是多人实时编辑文档,我也一直希望有这样一款软件,才知道是我的损失,同步响应速度很快,用户体验感很棒,能够满足用户云端实时协作的需求;

      支持导入文件,能够全局搜索与文件管理;并不像某些流氓软件比如WPS有强制广告或者水印行为,且收费模式较为合理,不破坏用于体验。

      美中不足的是部分功能的加载速度慢,比如表格加载、导入文件等(可能是因为升级到IOS12.1.2的原因,不多赘述。)

    BUG:

      1.可能是因为刚刚升级到了IOS12.1.2的缘故,在接收验证码时会存在自动填写验证码功能显示失败的情况。也许可能属于个别情况。

      2.操作逻辑上:对于其他人分享的文章,打开后会一直存在于我的账号内,甚至能看到编辑修改记录。隐私安全无法得到保证,且无法删除。

      3.同步后再打开时出现文字顺序混乱的情况,甚至偶尔会出现闪退的情况。

     

    2.选择需要使用这样的软件的用户进行采访,记录你的采访,记录形式不限,图片、文字或文档链接。
    (1)介绍采访对象的背景和需求(他们为何要使用这款文档软件,这款文档软件能为他们提供什么帮助?)

      采访对象为大四学姐,在软件公司实习,每天会处理一到两篇文档。

    (2)让采访对象使用5-15分钟石墨文档的功能

     


    (3)描述用户使用这个产品的过程, 用户的问题解决了么?软件在数据量/界面/功能/准确度上各有什么优缺点?用户体验方面有问题么?

      因为用户不会处理十分庞大的文件量,每天只有一两个而已,所以文件编辑软件的利用不会对她的生产力造成影响。她以前使用的是流氓软件WPS,但对于我所诟病的几个大毛病并没有特别在意。对于石墨文档,她表示即使下载了也可能不会用。第一是因为她是一个文档处理轻用户,不会对于文档处理软件有非常大的要求,用她自己的话来讲就是能用就行。二是因为了解一款新软件的学习成本太大,即使石墨文档的学习成本很小,但她觉得没必要为了这个去单独下载一个软件。第三是她只使用了IOS端,并没有使用MAC和WIN端,IOS只是为了手边没有电脑时的临时替补,谈不上生产力。
    (4)用户对产品有什么改进意见?

      她表示石墨文档对于她们公司所使用的企业版微信契合度不够,建议可以对于钉钉等企业用APP能够有更是深层次的定制功能,符合更多场景下的文档编辑需求。

    3.请给出你对这款软件的评价和理由。

      推荐
      用户其实选择一款APP 的原因有时候其实很简单,就是看有没有他们特别需求的功能出现,能够真正地从用户的角度去看问题。我认为石墨文档抓住我的原因就是因为有一个多人在线实时编辑的功能,非常符合我的日常使用情景。

    第二部分 分析

    1.使用此软件的所有功能(包括新建文档、文档导入等),联系第二部分的分析,估计这个项目做到这个程度大约需要多少时间(以周为单位、团队人数6人左右、计算机专业本科毕业生,并有专业UI 支持),人员如何分工?时间如何规划?

      估计时间在20周左右,6人分配,4人做前后端相应工作,1人美工,1人测试;

      时间分配:5%的时间用于定义问题和制定计划,15%的时间用于需求分析和建立软件的逻辑模型,5%的时间进行软件设计,45%的时间用于代码开发与美工,30%的时间用于软件测试和解决bug。

    2.分析这个软件目前的优劣(和类似软件相比),并给出团队在软件工程方面可以提高的一个具体建议。

      这类产品还是比较多的,国外的Google Docs 和 Quip,国内的有腾讯文档,有道云笔记,为知笔记,印象笔记以及微软的ONENOTE。

      功能是临时手写笔记功能。这个功能主要可以针对于IPAD,特别是在今年APPLE刚刚发布了新的IPAD PRO以及APPLE PENCIL,对于用手写笔对文档进行随意地涂改和标记。

    NABCD分析

    N(Need 需求)

           团队有协作办公的功能需求,以office为主,但是随着团队工作的复杂化和团队人数的增加,大家对协作类工具的需求也更强烈了。目前国外的一些协同工具比如 Google Docs 还无法在国内普及使用,给了本土企业很大的商机与空间。

    A (Approach 做法)

           针对不同行业用户的不同需求来设计功能板块,推出针对于不同职业人的不同版本APP,甚至可以对于某一类特殊的人群职业进行定制化的个性服务。

           比如针对单纯的文字工作者,需要的是快捷和高效,可以利用简洁的操作来吸引此类用户,简化编辑模式。

      甚至对于知名的公司和团队定制化服务,完全根据其内部的组织框架来进行APP开发设计。

     B (Benefit  好处)

    对用户而言:

      针对某一类人的专属APP能够让用户感到一种归属感,让他们对于自己所从事的事业产生认同感,让他们觉得自己所从事的没有白费。

    对团队而言:

      利用对知名公司的定制化服务打开知名度,谋求更大的影响力。

    C (Competitors 竞争)

      市场上的竞争非常巨大,人人都想分一杯羹,且在这之间就有许多类似的APP出现过了,而且这些产品,比如腾讯,利用自己先前的用户积累,能够迅速地吸引用户和积累用户,我们开发比较晚,相对于他们而言,我们处于比较劣势的地位。但是我们的目标是做的比他们更加齐全,我们的产品一定是竭尽为用户提供最简单、最纯粹的服务。不单单简洁,而且功能方面也要齐全,强大,这样的情况下,我们才可以有更多的优势去和别人进行竞争。

    D (Delivery 推广)

      推广方面:我们可以APP STORE和各种安卓下载平台打广告。同时请大公司用我们的产品提高影响力。

    第三部分 建议和规划

    1.这个软件有很多可以提高的部分,如果你是项目经理,如何提高从而在竞争中胜出?

      仅仅只作为一个项目经理,那只能从产品本身下手。我会尽力提高APP的完成度,UI功能两手抓,努力提升用户体验。
    2.目前市场上有什么样的产品了?你要设计什么样的功能?为何要做这个功能,而不是其他功能?为什么用户会用你的产品/功能?你的创新在哪里?可以用 NABCD分析。

      WPS等。

      想设计翻译功能,因为我英语比较烂。部分用户的英语也比较烂。

    3.如果你的团队有5个人, 4个月的时间,你作为项目经理,应该如何配置角色(开发,测试,美工等等)?

      1测试1美工3开发
    4.描述你的团队在16 周期间每周都要做什么,才能在第16周如期发布软件。

    第1-3周:制定计划,主要确定软件的开发目标及其可行性并进行需求分析,对软件需要实现的各个功能进行详细需求分析,和用户一起确定要解决的问题,建立软件的逻辑模型,编写需求规格说明书文档并最终得到甲方的认可。

    第4周:软件架构设计,根据需求分析的结果,对整个软件系统进行设计,如系统框架设计、数据库设计、功能逻辑设计等。

    第5-11周:代码开发与美工,将软件设计转化为可运行的代码。

    第12-15周:试运行、测试,解决Bug。整个测试阶段按照单元测试、组装测试、系统测试三个阶段进行。

    第16周:发布软件,并听取用户的意见反馈,完善软件。

    转载于:https://www.cnblogs.com/lvpengaaron/p/10171858.html

    展开全文
  • iOS开发帮助文档可以在苹果开发者中心在线查看,也可以在Xcode本地查看。 苹果开发中心在线查看示例图: 传送门:https://developer.apple.com/library/ios/navigation/ 网页导航栏可以搜索所有 iOS开发...

    iOS开发帮助文档可以在苹果开发者中心在线查看,也可以在Xcode本地查看。

    苹果开发中心在线查看示例图:
    传送门:https://developer.apple.com/library/ios/navigation/


    1. 网页导航栏可以搜索所有 iOS开发资源库。
    2. 网页左侧导航视图将所有文档按照资源类型主题框架分类。
    3. 网页左侧导航视图下侧是废弃的文档,据此可以维护和更新旧的代码库。
    4. 网页主体包含所有资源文档的标题资源类型主题框架发布时间的属性。其中主要属性作为导航分类列在左侧导航视图内,可通过点击左侧导航视图展开各级列表迅速找到所需资源文档。
    Resource Types(资源类型)
    1. Guides(指南) --通过阅读指南理解iOS的概念和编程任务。苹果的开发者指南包括:概述、教程、编程指南和针对开发者的工具、用户指南。

      指南是Xcode里面最酷最好的部分,学会看指南则大多数情况完全不用买书。Xcode文档里面的指南,就是一个一个问题的,从一个问题,或者系统的一个方面出发,一步一步详细介绍怎么使用Cocoa库的文档。一般程序员比较熟悉的是Reference,就是你查某个类、方法、函数的文档时候,冒出来的东西。那些其实是一点一点的细碎知识,光看那些东西就完全没有脉络。而Guides就是帮你整理好的学习的脉络。

    2. Reference(参考类关系) —— 查找详细的API信息在这些参考文档。一个一个框架一个一个类组织起来的文档,包含了每个方法的使用方法。
    3. Release Notes(发布说明) —— 通过查看发布说明可以得知关于最新发布的iOS SDK版本和相关开发工具的新闻和新的或者改变的特性。
      一个iOS新版本带来了哪些新特性,这样的信息,熟悉新iOS,比较不同iOS版本API不同,都需要参考这些文档。
    4. Sample Code(示例代码) —— 研究样本代码来学习如何采取技术和实现功能。每个示例代码项目是一个关于使用一个特定的技术来完成一项任务的可信赖、执行的源代码例子。代码显示了正确的调用序列和一般实现api的参数,您可以修改您的特定需求。
      苹果官方提供的一些示例代码,帮助你学习某些技术某些API。非常强烈建议学习的时候参考,一方面光看文档有时候还是很难弄明白具体实现是怎么回事儿。另外一方面这些示例代码都是苹果的工程师写的,你从示例代码的变迁可以看到苹果官方推荐的代码风格流变。
    5. Technical Notes(技术文档) —— 技术文档是以简短形式书写的说明文档,是关于特定的编码问题的详细技术信息。
      技术说明。一些技术主题文章,有空的时候可以浏览一下。往往会有一些收获。
    6. Technical Q&A(技术问答) —— 快速得到特定编码问题的答案在技术问答文档。
      常见技术问答。这是技术社区里面一些常见问题以及回答的整理。
    7. Video(视频) ——听苹果工程师讨论最新的技术和展示如何将其纳入您的开发工作。
      目前主要是WWDC的视频,实际上是登录到开发者网站上去浏览的,这里就是快捷方式。想深入学习的话,一定不能错过,大量的看,不仅可以学好技术,还可以练好英文。
    8. Xcode Tasks(xcode 任务)--视频合集,一步一步的指示来执行常见的Xcode操作。这些指令通常包括视频或插图作进一步的澄清。

    总结一下,这里面的Reference、Release Notes、Sample Code、Technical Notes、Technical Q&A,一般来说只是备查的。主要要看的是Getting Started和Guides。注意新版的(iOS 9.3)iOS Developer Library 将Getting Started去掉了。

    Topics(主题)
    1. Audio & Video(音频和视频) --
    2. Data Management(数据管理) --
    3. General(常见问题) --
    4. Graphics & Animation(图形和动画) --
    5. Languages & Utilities(语言和工具) --
    6. Mathematical Computation(数学计算) --
    7. Networking & Internet(网络) --
    8. Performance(性能) --
    9. Security(安全) --
    10. Swift(新的编程语言) --
    11. User Experience(用户体验) --
    12. Xcode(iOS应用开发工具)
    Frameworks(框架)
    1. WebKit -- 详细说明待更新。。。
    2. Cocoa Touch Layer -- 详细说明待更新。。。
    3. Media Layer--详细说明待更新。。。
    4. Core Services Layer--详细说明待更新。。。
    5. Core OS Layer--详细说明待更新。。。
    注意⚠️: 查看详细的内容请手动传送,每个传送门都可以传送到相关的技术文档或代码库。总体来说左边的导航区域就是用三种不同的维度,来帮你精准定位你需要的内容。

    现在我们看内容区域的右边。注意上面的文档过滤器。如下图:



    假设,你现在想看关于Graphics & Animation(图形和动画)方面的Guides,那么你应该做的就是在左面的导航,点击Topics -> Graphics & Animation,然后在右边的文档过滤器上面输入Guides。或者你也可以在左边的导航,点击 Resource Types -> Guides,然后在文档过滤器里面输入 Graphics & Animation。熟练使用导航和文档过滤器的话可以事半功倍的学习iOS Developer Library。

    Xcode本地查看示例图:


    展开左侧导航栏发现共分为iOS、OS X、tvOS、watchOS和Xcode五大类操作系统或IDE说明文档。四大操作系统的说明文档可以在苹果开发者中心网站导航栏的develop栏下找到(如下图:),Xcode针对各操作系统下的说明文档分散在各操作系统下的开发说明文档里面,可以在线按照platforms、resource types、topics和(非必要)technologies等属性找到。


    iOS9.3 Documentation导航目录

    将在线文档的topics和frameworks集合在一起,包括sample code、guides和reference文档。

    1. (topics.1)Audio & Video(音频和视频) --
    2. (frameworks.2)Cocoa Touch Layer() ——
    3. (frameworks.4)Core OS Layer()——
    4. (frameworks.3)Core Services() ——
    5. (topics.2) Data Management(数据管理) --
    6. (topics.3) General(常见问题) --
    7. (topics.4) Graphics & Animation(图形和动画) --
    8. (topics.5) Languages & Utilities(语言和工具) --
    9. (topics.6) Mathematical Computation(数学计算) --
    10. Media Layer() ——
    11. (topics.7) Networking & Internet(网络) --
    12. (topics.8) Performance(性能) --
    13. (topics.9) Security(安全) --
    14. (topics.10) Swift(新的编程语言) --
    15. (topics.11) User Experience(用户体验) --
    16. (frameworks.1)WebKit() ——
    17. (topics.12) Xcode(iOS应用开发工具) --

    (持续更新。。。)


    展开全文
  • 做项目一般都会要求写技术文档,特别是单干接项目的,客户多少都会要求除了提供code之外,还得提供技术文档,而如果我们手写这类的文档,那工作量不比写code少。一般的开发工具都会提供类似集成的功能,比如Java语言...

    做项目一般都会要求写技术文档,特别是单干接项目的,客户多少都会要求除了提供code之外,还得提供技术文档,而如果我们手写这类的文档,那工作量不比写code少。一般的开发工具都会提供类似集成的功能,比如Java语言本身就自带javadoc命令,可以从源码中抽取文档,几个配置,几条命令就搞定了。


    Xcode工具本身不具备这样的功能,但是我们通过一些插件和工具来达到这个目的。


    生成注释

    生成文档之前,我们需要给代码中的方法或者变量写上注释,然后再利用工具根据这些规范的注释自动生成文档。所以呢,注释一定要规范统一,但是每次都要手动输入规范化的注释,着实也麻烦,这里需要借助Xcode的开源插件VVDocumenter,规范注释生成器,非常方便!




    多行注释直接输入三个斜线 "///" 会自动格式化,如上图所示

    单行注释需要输入三个斜线+空格 “/// 注释”。输入两个“//”当然可以正确的被xcode识别为注释,但是在下面生成文档的时候不能被识别为文档注释。


    然后再配合 appledoc 、doxygen 或者 headdoc,就可以生成技术文档。

    对于Objective-C来说,目前比较好用的是appledoc 和 doxygen


    工具对比

    headerdoc
    xcode 自带的文档生成工具、基于命令行的操作、使用方便。但是只能生成以 /*! */ 的格式的注释。还有一个缺点是每个类文件对应一个注释文件,没有最后汇总导航的index文件。


    docxygen
    功能强大、三者中支持语言最多的、无headerdoc缺点、基于图形化的操作界面,但是配置较多,可以生成html文档或pdf文档。

    appledoc
    基于命令行的操作、使用方便、无headerdoc缺点、默认生成的文档风格和苹果的官方文档是一致的,即docset,集成到xcode中就跟苹果的官方文档一模一样,在源码中按住option再单击就可以调出相应方法的帮助。当然也可以生成html文档。


    工具使用

    appledoc

    从github下载源码,在终端里面cd源码文件夹,然后执行shell脚本安装

    [plain] view plaincopy在CODE上查看代码片派生到我的代码片
    1. git clone git://github.com/tomaz/appledoc.git  
    2. cd appledoc  
    3. sudo sh install-appledoc.sh  

    安装过程中如果出错,检查一下Xcode所在的路径中是否存在空格,去掉再试之。

    成功后在终端cd到项目文件夹里面,输入以下命令生成文档:

    [plain] view plaincopy在CODE上查看代码片派生到我的代码片
    1. appledoc --output ../doc --project-name weibo --project-company "wxhl" --company-id "com.wxhl.weibo" .  
    --output ../doc  设置文档输出目录为上级目录下面的doc
    --project-name weibo  设置项目名为“weibo”
    --project-company "wxhl"  设置公司名为“wxhl”
    --company-id "com.wxhl.weibo"  设置公司id为“com.wxhl.weibo”
    .  当前目录


    当该命令完成后,可以看到在上级目录的doc文件夹里面有一个docset-installed.txt的文件,这里面描述了docset文档所在的真正路径,一般都是在~/Library/Developer/Shared/Documentation/DocSets/ 里面,或者看看xcode中的Organizer - Documentation,会发现其中新增了帮助文档。




    生成HTML

    对于最新版本的appledoc来说,它默认时是生成docset文档并集成到xcode。当需要html文档时,可以加上“--no-create-docset”

    [plain] view plaincopy在CODE上查看代码片派生到我的代码片
    1. appledoc --no-create-docset --output ../doc --project-name weibo --project-company "wxhl" --company-id "com.wxhl.weibo" .  

    当该命令完成后,可以看到在上级目录的doc文件夹里面就 不是docset-installed.txt文件了,而是全部的html文档,直接打开index就行。



    doxygen

    doxygen支持源码编译安装与dmg安装。去doxygen官网下载最新的dmg,doxygen有图形界面,可通过Launchpad打开。

    在step 1中选择好项目的路径。
    step 2默认是Wizard->Project页面,在其中
    1) 在“Project name”中填写项目名。
    2) 勾选“Sacn recursively”,扫描所有的子文件夹。
    3) 在“Destination directory”中填写好文档的输出目录。这里我填的是“docs”。

    点击中间的“Expert”切换Expert->Project页面,在其中
    1) 将“OUTPUT_LANGUAGE”设为“Chinese”,使用简体中文。
    2) 勾选“JAVADOC_AUTOBRIEF”,自动将注释的第1段识别为简要描述。


    点击中间的“Run”切换Run页面,然后点击“Run doxygen”按钮生成文档。

    当文档生成完毕后,使用浏览器打开docs/html/index.html——

    生成PDF

    doxygen默认会为生成pdf做好准备。切换到Wizard->Project,会发现它自动勾选了“LaTex”与“as intermediate format for hyperlinked PDF”。

    doxygen本身并不能直接输出pdf文件,而是生成了latex目录,其中有一个 makefile 文件。若系统中装好了pdflatex,可在latex目录中运行“make”命令来生成pdf文件。
    怎样才能装好pdflatex呢?mac平台可安装MacTeX。打开 http://www.tug.org/mactex/ ,下载  MacTeX.pkg (约2.1GB)。MacTeX.pkg下载好后,可双击运行,根据向导来安装。

    环境装好之后,当在latex目录中运行“make”命令来生成pdf文件时,你会发现——纯英文文档能顺利生成pdf;而含有中文时,不能顺利生成pdf文件。

    对于latex排版,doxygen其实已经做了很多准备,比如——源文件是UTF-8编码,并默认使用了utf8 package。理论上是支持多国语言的。
    可对于中文来说,还需要加载 CJKutf8 package,并配置好CJK环境。这才能顺利的使用中文。

    用文本编辑器打开docxygen生成的latex目录中的refman.tex。找到“\begin{document}”这一行,将其修改为

    \usepackage{CJKutf8} 
    \begin{document}
    \begin{CJK}{UTF8}{gbsn}

    然后再找到“\end{document}”这一行,将其修改为

    \end{CJK} 
    \end{document}

    保存并关闭refman.tex。
    然后打开终端,使用cd命令进入latex目录,然后执行“make”命令。

    执行完毕后后,该目录中会出现“refman.pdf”——


    参考

    http://www.cnblogs.com/zyl910/archive/2013/06/07/objcdoc.html

    http://blog.devtang.com/blog/2012/02/01/use-appledoc-to-generate-xcode-doc/


    原文地址:http://blog.csdn.net/keyzhang_blog/article/details/19005691

    展开全文
  • iOS规范文档OC版

    2018-04-14 17:09:17
    iOS规范文档OC版 iOS规范文档OC版 目录结构规范 静态库 项目目录 命名规范 通用规范 清晰 一致性 驼峰原则 文件夹命名规范 类命名规范 类别名规范 方法命名规范 代理命名规范 ...

    iOS规范文档OC版

    目录结构规范

    静态库

    目录名为:Frameworks,存放所有的静态库文件

    项目目录

    项目目录下设置以下几个目录:

    Macro:宏定义文件夹,只放值一些自定义或第三方秘钥,其他的宏定义需放置在pch文件里

    NetWorks:网络请求文件夹,放置不同网络请求的文件

    Categories:分类文件

    Utils:工具类文件

    Models:数据模型文件

    Views:视图文件

    Controllers:控制器文件

    Managers:管理类文件

    DataBase:数据库文件(CoreDataFMDB

    Vendors:第三方SDK

    Resources:资源文件

    项目目录下的子文件根据功能进行分割,不同功能模块的代码需要分别使用文件夹分开,存放在子文件下或单独创建一个主文件夹。
    按大功能模块Controller至少创建一个父类 View看需求

    命名规范

    通用规范

    通用规范是在整个项目中,所有的命名都需要遵循的规范

    清晰

    所有的命名要清晰且简洁,以清晰为主。要做到见名知意。命名最好以英文为主,除专有名词外,不许使用单词缩写。严禁使用中文或拼音以及拼音与英文混合的方式

    创建首页文件件====
    
    正例:HomeViewController
    
    反例:shouyeViewControlle
    

    一致性

    做某件事的代码通常都叫这个名字,比如tag、setStringValue,那你也这么叫。在你不确定怎么起名的时候请参照《Apple开发规范》

    驼峰原则

    分为大驼峰小驼峰,每个类型需要遵循大驼峰或小驼峰中的一种
    大驼峰:首字母大写。
    小驼峰:首字母小写

    大驼峰:HomeViewController
    
    小驼峰:userName
    

    文件夹命名规范

    文件夹名需要遵循大驼峰原则,且功能集合的文件夹必须使用复数形式。文件命名需要与模块的功能相对应。

    类命名规范

    类名需要遵循大驼峰原则。类名最好加上项目的前缀缩写,如WP+类名。当需要在其他项目使用的类,可以不加或添加规定的统一前缀。

    封装通用的库,需要确认统一的前缀(WP)!
    

    类别名规范

    类别的命名主要是扩展名的命名规则,类别的扩展名必须要遵循 类名 + 标识 + 扩展功能的命名规范。

    UIImage (WPAdd)
    

    方法命名规范

    方法名的命名需要遵循小驼峰原则。规范的方法名应该看起来像一个完整的句子。尽量做到读方法名便可以知道函数的作用。

    /**
     发送获取地址列表请求
     */
    - (void)beginSendRequestForGetAddressList
    

    代理命名规范

    代理的命名需要遵从大驼峰原则。且开始必须要遵循当前代理对象 + Delegate的命名规范。例如:LoginViewDelegate

    变量命名规范

    变量名需要遵循小驼峰原则。除了公认的名称外,必须使用单词的全称命名。当需要使用多个参数时,按照顺序拼接。禁止使用缩写进行拼接。普通变量无需添加下划线开头,全局变量、成员变量需要以下划线开头。

    常量命名规范

    常量名规范分为3种:
    1、普通常量:需要遵循小驼峰原则。例如:kUserToken
    1、宏定义:需要全大写,例如USER_TOKEN
    2、枚举:需要遵循前缀 + 大驼峰的命名方式。例如:WPUserLoginType

    图片命名

    1、模块+功能命名法(公共使用:common+功能)例如:个人中心模块中我的消息按钮:personal_btn_my_message

    2、单词全拼,或者大家公认无歧义的缩写(如:nav,bg,btn等)

    注释规范

    所有使用//进行注释的代码,//后面必须要加上空格,即// 注释

    成员变量注释规范

    .h文件中,所有的属性使用 /** 注释 */的注释方法,例如:

    /** 用户Id */
    @property (nonatomic, copy) NSString *userId;
    

    当需要对属性进行详细说明时可以对/** 注释 */进行换行,来分行注释

    /**
     登录凭证
     每次登录时创建或者退出时删除
     */
    @property (nonatomic, copy) NSString *sessionToken;
    

    .m中的,所有属性在结尾处使用// 注释进行注释,且//与结尾处至少空一格。注释内容最好可以就近对齐,对齐可以使用Tab直接缩进对齐或使用空格键对齐,例如:

    @property (nonatomic, strong) ODSTopUpCountView *topUpCountView; // 充值金额视图
    
    @property (nonatomic, strong) ODSTopUpPaymentView *payTypeView;  // 支付方式视图
    
    @property (nonatomic, strong) ODSTopUpBottomView *bottomView;    // 支付说明视图
    
    

    非成员变量,在结尾处使用// 注释进行注释,例如:

    @interface ODSTopUpViewController ()
    {
        UILabel *_nameLabel; // 用户名文本
    }
    
    @end
    

    方法注释规范

    方法注释统一使用系统注释方法CMD + Opt + ?,当方法的参数名不重要时则可以删除。重要的参数名必须要要进行注释。
    除系统方法外,自定义的方法必须要注释!
    复杂的逻辑处理最好也要加上必要的注释说明,说明主要的处理逻辑

    方法与方法间,如果后面一个方法有注释,则换一行,没有注释则需要换两行

    代码组织

    .m文件中必须使用#pragma mark -进行方法分组。Controller中最好使用一下的方法进行分组:

    #pragma mark - - - - - - - - - - - - - - - - - Init And Dealloc - - - - - - - - - - - - - - - - -
    #pragma mark - - - - - - - - - - - - - - - - - Life Cycle - - - - - - - - - - - - - - - - -
    #pragma mark - - - - - - - - - - - - - - - - - Data Request - - - - - - - - - - - - - - - - -
    #pragma mark - - - - - - - - - - - - - - - - - Event Response - - - - - - - - - - - - - - - - -
    #pragma mark - - - - - - - - - - - - - - - - - Delegate Response - - - - - - - - - - - - - - - - -
    #pragma mark - - - - - - - - - - - - - - - - - NSNotification Response - - - - - - - - - - - - - - - - 
    #pragma mark - - - - - - - - - - - - - - - - - Public Events - - - - - - - - - - - - - - - - -
    #pragma mark - - - - - - - - - - - - - - - - - Private Events - - - - - - - - - - - - - - - - -
    #pragma mark - - - - - - - - - - - - - - - - - Setter and Getter - - - - - - - - - - - - - - - - -
    

    代码规范

    删除多余的空格

    属性变量

    使用@property时,括号中的nonatomicassignstrong等,中间用,隔开时,逗号后面必须空一格。后面的类名()必须空一格。

    @property (nonatomic, copy) NSString *userId;
    

    方法规范

    有处理逻辑的方法左侧的{需要换行。没有处理逻辑时,则使用{},且方法前的-、+必须与后面的()空一格具。体如下所示:

    - (void)loginButtonClick
    {
        // 执行逻辑
    }
    
    - (void)loginButtonClick
    {}
    
    

    控制语句

    1、switch块内通过break/return来终止
    在一个switch块内,每个case要么通过break/return来终止,要么注释说明程序将继续执行到哪一个case为止;在一个switch块内,都必须包含一个default语句并且放在最后,即使它什么代码也没有。

    2、在if/for/while/switch语句中使用大括号
    条件语句体应该总是被大括号包围。尽管有时候你可以不使用大括号(比如,条件语句体只有一行内容),但是这样做会带来问题隐患。比如,增加一行代码时,你可能会误以为它是 if 语句体里面的。此外,更危险的是,如果把 if 后面的那行代码注释掉,之后的一行代码会成为 if 语句里的代码。

    3、推荐尽量少用else,例如:

    if (isLogin) {
    
        //处理逻辑
        return;
    }
    
    // else的逻辑
    
    

    4、if/for/while/switch语句中,if/for/while/switch与后面的()必须要空一格,()与左侧{必须空一格。且if/for/while/switch语句中左侧的{不换行。

    5、if的条件判断中尽量不要使用函数方法作为判断,应新建一个BOOL类型的值接收,例如

    正例: 
        BOOL success = [self checkSaveIsSuccess];
        if (success) {
            
            // 处理逻辑
            
        } else {
        
        }
        
    反例:
        if ([self checkSaveIsSuccess]) {
            
            // 处理逻辑
            
        } else {
        
        }
    

    操作符

    除了一元操作符外,所有操作符两侧的元素必须要与操作符空一格。

    封装

    当项目或.m文件中,同一段代码出现三次以上的时候,则需要对这段代码进行封装。

    展开全文
  • iOS开发之规范文档

    2018-06-22 10:21:43
    .语言采用US(美式)英语,不使UK(英式)英语或汉字拼音.US: UIColor *myColor =[UIColor blueColor]; UK: UIColor *myColour =[UIColor blueColor]; 拼音: UIColor *wodeYanSe =[UIColor blueColor];二.命名规则1....
  • 做项目一般都会要求写技术文档,特别是单干接项目的,客户多少都会要求除了提供code之外,还得提供技术文档,而如果我们手写这类的文档,那工作量不比写code少。一般的开发工具都会提供类似集成的功能,比如Java语言...
  • iOS 11整理大集合

    2017-12-22 14:02:00
    掘金客户端适配iOS11简单记录 iOS 11 安全区域适配总结 iOS开发-适配iOS 11 适配iOS11&iPhoneX的一些坑 完美适配 iOS11 导航栏 腾讯WeTest 你可能需要为你的APP适配iOS11 iOS 11 适配看这篇还不够? iPhone X 适配 ...
  • iOS内购流程文档-Lion

    2017-08-29 09:50:10
    iOS内购流程: iOS内购 什么时候用到呢? 虚拟产品就需要用到iOS内购; 购买的商品,是在本app中使用和消耗的,就一定要用内购,否则会被拒绝上线,例如:游戏币,在线书籍,app中使用的道具等。 重要的大概步骤...
  • 自初春之际着手翻译《iOS11界面交互设计规范》(英文记《iOS Human Interface Guidelines》),迄今已近半载。断断续续,林林总总;终归曙光初现,也算圆满。更幸有梳理归整,章节目录也算清晰,得以纵览全文。奈...
  • iOS端的UI设计文档

    2017-12-22 14:40:53
    iOS端的UI设计文档    APP和网站,风格色调始终注意保持一致(平台一致性)  在App不断更新的过程中定义设计准则、风格、规范 设计规范:  1、分类合理(为了能让用户快速查找,合理的分类必不可少)  2、规范...
  • 下列文档来自geetest 相关链接: https://github.com/GeeTeam/gtapp-ios-oc/blob/master/geetest_ios_dev.rst  可下载geetest 的 iOS版 https://github.com/GeeTeam/gtapp-ios-oc 更多信息可查阅geetest官网
  • 导入&导出文档IOS开发者经常面临的开发需求。例如你开发文档阅读器允许用户导入他的文档到你的应用中以便离线阅读。又如,你的阅读器可以导出文档以便其他应用使用。  这篇文章,将介绍各种IOS开发中使用的...
  • Why 苹果官网的IOS Developer Library是开发者最喜欢用...这个链接返回的是XML数据,里面可以清晰的看到每个IOS版本的文档下载地址,以最新的ios9.2来说,拉到页面最底部,找到类似对称注释标记  dict> key>fi
  • iOS官方参考文档

    2014-01-13 14:48:29
    中文的指导手册 ...英文的关于iOS开发的类库,可以用浏览器翻译一下,知道大概意思,自己探究一下就行了。 https://developer.apple.com/library/i
  • 附:iOS开发者文档英文原文 已经有许久未更新博文了,最近主要回到iOS应用开发的横向项目上,所以在视觉、算法等其他领域暂时还木有空更新。 开发者文档解读 NSUserDefaults是个分层持久进程间(可选分布式)...
  • iOS Development
1 2 3 4 5 ... 20
收藏数 20,957
精华内容 8,382
热门标签
关键字:

11英文文档 ios