如何编写iOS5杂志程序（1）

原文：http://ios-blog.co.uk/tutorials/how-to-make-a-magazine-app-in-ios-part-i/

介绍

对于iPad用户来说，iPad最有用的特性之一恐怕是用来阅读：书记、杂志或者报刊。事实上所有有影响力的出版社都已经把他们的产品陈列在了App商店，而越来越多的小出版社都在尝试占领iOS领域。

准备进入App商店的出版商们，需要考虑下面的几个问题：

• 准备将杂志发布为特定的app，还是作为newsstand app?
• 一旦决定使用单独的app，那么是准备进行定制开发，还是做一个web应用以便进一步迁移到newsstand？
• 是采用第三方的发行渠道还是自己来发行？
• 是准备重用已有的PDF，还是制作全新的数码杂志（你可以使用
•  Adobe Digital Publishing suite）？

你考虑的结果将直接影响开发费用、web维护和支持的方式、最终杂志的设计风格。

本文作者在杂志的开发方面有一些经验，曾在App商店中发布过多个杂志应用。本系列文章总结了一些开发中的经验，试图从头到尾全面描述iPad杂志应用的构成。希望开发者们能从中获益。

第 1部分 – 构成

下图展示了一个典型的杂志应用的3个主要的界面。

注意：虽然我们主要是针对iPad，但本文内容也适用于iPhone。

一个杂志应用的主要界面

1、Store界面“书店”

这是用户第一眼看到的界面（除了出版商的splash窗口）。它提供了一个当前用户能够购买的所有期刊的列表（“购买”一词也包括“免费”期刊，虽然是0费用）。

注意：一个典型的杂志应用通常仅仅是一种杂志，因此只能选择最近一期和一系列过期刊物。

对于更复杂的情况，例如图书的销售，或者多杂志应用，这个界面会变得更复杂，因为需要对不同的书进行分门别类，用某种“层次”进行展示。通常期刊以封面展示，封面在网格中陈列，或者以“coverflow”的风格通过滚屏显示。

每本期刊的封面上应该有期刊名、发行日期和价格。与之相关联的 *** 作包括：购买、下载、预览。

2、Library界面“藏书”

一旦期刊被购买，会自动转变到Library界面。这个界面（通常通过底部的tabbar访问）将显示已购买的期刊。通过这个界面，用户可以对每本期刊进行阅读、删除、打包或下载。

3 、Reader界面“阅读”

用户在Reader界面 阅读杂志：它可能是一个普通的PDF/e-pub阅读器，或者使用系统自带的预览功能（不推荐，功能有限），或者定制的阅读器：取决于期刊的格式。

有点出版商会要求合并Store界面和Library界面：这些杂志通常都是月刊（或者更短的发行周期），所有封面在同一界面显示，根据杂志是否已采购提供给用户不同的菜单。

一个杂志的正确结构应当把功能和界面分离。因为出版商和UI设计师经常对UI产生新的想法，这对程序员来说是个噩梦——每次界面的修改他都需要将代码和新的UI设计进行整合。为了最大限度的重用及模块化，采用苹果推荐的MVC模式是一种好的做法。

下图为功能框图。

其中代表“出版商服务器” 的云表示各种internet服务，不应该属于应用的一部分。通常指服务器集群，用于存储杂志数据以及各种web服务，并提供所有在书店中展现的杂志信息。后台可以位于顾客自己的服务器上，或者某些站点如AmazonS3，甚至是开发者的服务器（这种情况下需要保证带宽，避免长时间下载）。

方框“书店管理器”是程序的核心模块。用于与后台服务器通讯，向其他模块提供所需的数据。

首先，“书店管理器”模块需要从后台服务器获得有效期刊的列表。具体依赖你实现的方式。如果数据不大，可以简单地使用XML/JSON文件。如果每次需要下载的数据太大，可以建立复杂协议，例如对杂志进行分类，每次提供较少的数据，或者设计一个搜索功能。

注意:服务器和应用之间的通讯是单向的——数据从服务器传到app，同时相反反向的通讯仅限于小量数据交换比如订单交易、简单http查询或者分析应用程序的使用。

从开发者的角度，应当在服务器和“书店管理器”中间加入一个通讯层（图中未显示）。这将使得“书店管理器”仅暴露简单和通用的API,同时通讯层负责具体的后台API。

每当收到服务器发来的新数据，“书店管理器”会创建一系列“期刊模型”。

一个“期刊模型”是一个期刊的逻辑表示，包含期刊号、标题、封面图片、出版日期，以及根据情况附加的其他信息：多张预览图片、期刊内容简介、目录等。

注意：“期刊模型”拥有一系列字段，其中一些字段由“书店”填充。另外一些，可能来自应用程序内购系统（例如价格），或者来自已购买和下载的产品信息。因此在图中我们把“期刊模型”以本地数据库的形式表示。

“书店管理器”每创建一个新的“期刊模型”，将附加上一些额外信息，这些信息来自于本地存储。对于本地存储，可以采用Core Data，但使用plists则更加简单，或者对数据模型进行序列化。

“书店视图”提供了书店的图形界面。

注意：“书店管理器”是一个高度重用的组件，而“书店视图”则根据出版商的需求来定制：可以以书架的形式呈现（就像iBooks），也可以以封面滚动和flow-over的风格呈现。为了使数据模型于视图分离，“书店视图”通过委托协议的方式来调用“书店管理器”。

此外，“书店视图”应当通过某种机制（比如“通知中心”或KVO）监听“书店管理器”的某些改变。例如，当“书店视图”向“书店管理器” 通过委托方法请求数据（例如书刊数目、书刊名、每种书刊的期数，每期的标题、封面图片等），很可能是异步的（例如，用户在阅读刊物时，可能会发生其他期刊下载完成的事件），因此必须随时将此类事件通知给“书店视图”以便更新UI界面。通过“通知/KVO机制”，“书店视图”得以知道“书店管理器”的某些变化，从而调用协议方法进行查询，并根据查询结果更新UI。

“藏书视图”也是一个类似“书店视图”的ViewController，但仅用于显示用户已购买的期刊。它仍然会与“书店管理器”交互，采用的协议与“书店视图”一样。它也需要监听“书店管理器”，但提供给用户的选择是完全不同的。一旦开始购买，订单会被记录，一系列 *** 作可能因为网络问题而导致延误或者终止，问题可能出现在下载期间（可能从服务器下载几百M的期刊数据）或安装期间（尤其是在解压缩、创建程序图标等过程中）。因此“藏书”管理需要提供给用户继续 *** 作的选项：下载——如果问题出自购买环节而不是下载出错；停止/取消下载——如果问题出自下载过程，安装——如果期刊已经下载但未安装——然后再开始打开杂志准备阅读。

在框图中我们将“书店视图”和“藏书视图”分开来构成了典型的“分三屏显示”的应用程序结构，以此来突出二者的不同需求，但它们也可以被合在一起。但前者在App商店中更常见，被许多知名的杂志应用所采用。

注意：“书店管理器”与两个基于internet的苹果服务有关：应用内购买（Store Kit 框架）和Newsstand（当前为beta版，最终将内置在iOS5中）。

由于苹果商店的策略，应用内购买是App商店中购买杂志的唯一方法。出版商的后台服务器无法直接访问应用内购买系统，“书店管理器”负责向“期刊模型”通知来自于应用内购买服务器的价格信息。

因此建议在“书店管理器”和StoreKit框架间插入一个中间层，用于负责与Store Kit框架的异步通讯，同时向“书店管理器”提供简单接口（例如期刊是否在商店中有效？在该地区的当前价格是多少，用户是否已购买过该期刊？)已知的一个用于中间层的不错的开源框架是 MKStoreKit 。

Newsstand(书报摊)是来自iOS5的新特性。由于苹果的NDA(保密协议）的限制，我们不能过多暴露某些细节，只能使用苹果网站上的市场信息。Newsstand是一个所有基于订阅的杂志应用程序的中心，其实就是一个Springboard文件夹，包括了所有杂志应用的信息，可以用它来显示、下载最新期刊。“书店管理器”要支持Newsstand，必须提供必要的接口。

在第二部分，我将继续讨论框图中各个模块的细节。包括“书店管理器”委托协议、期刊模型、如何通过网络高效地检索信息。