介紹
對於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，必須提供必要的接口。

在第二部分，我將繼續討論框圖中各個模塊的細節。包括“書店管理器”委托協議、期刊模型、如何通過網絡高效地檢索信息。