你好,游客 登录 注册 搜索
背景:
阅读新闻

如何编写iOS5杂志程序(1) - kmyhy的专栏

[日期:2013-04-07] 来源:  作者: [字体: ]

原文: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,必须提供必要的接口。

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

 






收藏 推荐 打印 | 录入:admin | 阅读:
相关新闻