我們已經研究過XHtml和CSS了，現在開始看看最後一部分，也就是JavaScript，以及它所提供的交互能力。
第一種我們要看的交互，是完全不使用JavaScript，這其中一個例子就是GMail。GMail的iPhone版其實就是由普通的>GMail移動版修改過來的，界面上更貼近桌面版GMail了，然而交互性並沒有怎麼提高，每一個點擊都對應一次刷新，沒有任何AJax可言。
事實上，不用任何Ajax效果並不會讓你的iPhone Web App低人一等，如果有人譏笑你的應用沒有引入任何Ajax功能，你可以直接跟他說“GMail也沒有”。因此，如果你在開發的過程中決定不把任何時間投入到AJax相關技術的研究，這是沒問題的，確保你的服務器響應速度，並且交互設計得當，那就行了。
接下來我們看看另外一些應用，例如之前說到的幾個，就拿最簡單的AppMarks來說說吧。首先，使用User Agent Switch更改你的Firefox的user-agent屬性，偽裝為iPhone，然後打開AppMarks，並且打開Firebug。接著點Menu -> Add -> Browse，看到出現AJax請求了吧？猜猜這個請求是什麼類型的，面向內容（傳輸更新上去的XHtml）、面向腳本（傳輸進行更新操作的JavaScript）還是面向數據（傳輸更新相關的JSON）？答案是——面向內容的！
這可是Web App哦，不是一般帶有一點點AJax的網頁哦，我們要MVC，我們要“先進”的面向數據，為什麼要“落後”的面向內容呢？至今為止，我們能夠看到的大部分iPhone Web APPS，都將MVC保留在服務器端了，客戶端唯一需要知道的就是內容更新，不存在任何的客戶端MVC模型。暫時我還沒看到有面向腳本或者面向數據的，如果你見到有應用這樣做了，請告訴我。
我們繼續說MVC的事情。現在大多應用的設計方式是這樣的：每一個應擁有一個view framework，然後每一次點擊所作的操作就是切換view。例如剛才說到的AppMarks，從Menu進入Add是一個view切換，不過因為Add這個vIEw的內容是固定的，因此一早就包含在頁面裡，不用Ajax請求直接加載就行了。另外一種情況，就是好像加載Browse那樣，是需要AJax把view請求過來才能加載的。除了切換vIEw，我們還需要action，例如提交數據就一定需要action的。說到這裡，感覺是不是和RoR或者類似框架扯上關系了？事實上，RoR，或者類似框架，確實很適合用來做iPhone Web APPS。
那麼除了RoR，我們還有別的選擇嗎？我們可以選擇使用一些客戶端框架來實現類似的效果。這樣說吧，類似RoR那樣每一個vIEw都是一個模板，但不是rhtml，而是普通的html，沒有復雜邏輯，點擊連接後不是由RoR引擎調在服務器端用rhtml，而是客戶端自己直接攔截了鏈接點擊並用AJax的方法去請求該Html然後更新內容。這樣一個框架，可以在Wrox的>Professional iPhone and iPod touch Programming : Building Applications for Mobile Safari一書中見到。這本書寫著2008年1月出版，但實際上已經出版，並且可以下載源代碼。我暫時還沒辦法買到這本書，但源代碼中就包括了這樣一個客戶端框架。
然而，這種以客戶端為中心的做法並沒有真正在客戶端引入一個MVC，它只是簡單地把服務器端的MVC裁減掉了，服務器端只能簡單的發送內容或響應提交，因此只適用於比上面的以服務器端為中心的模型更簡單的情景。如果你正在編寫的應用不涉及大量的提交操作，或者根本就是Web1.0網站，我的意思是，單向傳遞信息不接受任何用戶提交的網站，那麼這種輕量級的模型就非常適用了。
在這次的文章裡，我們介紹了三種常見的iPhone Web Apps交互方案，沒有哪一個是絕對更好或者更壞的，按照你當前開發的應用做出選擇吧。將來我們寫文章深入探討其中的一些實現細節，或者是交互模式，但前提是我先完成了幾個iPhone Web APPS。