AJAX將成為移動Web2.0時代首選開發平臺_.Net教程

      編輯Tag賺U幣
      教程Tag:暫無Tag,歡迎添加,賺取U幣!

      推薦:Ajax簡單客戶登陸驗證
      服務器端操作方便之處我就不吹了,地球人都知道,它最煩莫過于頁面刷新,頭都被刷暈了,而且他在刷新的時候,還觸發服務器端的事件,現在Ajax的出現,他們的結合是發展的必然! 一、介紹一下A

      一、引言

      最近,Opera宣布通過他們的瀏覽器把AJAX技術應用于移動設備開發中。考慮到Opera瀏覽器在目前瀏覽器市場(特別是在移動瀏覽器市場)的流行性,我們可以預計這一宣布對于整個瀏覽器市場必然會產生重要影響。從加入到移動服務開發市場幾年的經驗來看,我相信現在的AJAX很可能會替換Java ME和XHTML而成為開發移動應用程序的首選平臺。

      在正式開始前,我想作一下說明-我相信,移動Web 2.0遠遠不止"移動AJAX"這一層應用。移動Web 2.0應該包含把Web 2.0的所有七個原則都將應用于移動市場。在本文中,我想只討論一下AJAX,也就是只討論Web 2.0的一個方面。

      二、什么是AJAX

      AJAX是Web 2.0的一種可選的增強技術,而不僅僅指一種技術。而是,它把許多現有技術結合到一起,也就是:

      · XHTML和CSS-用于基于標準的描述

      · 文檔對象模型-用于動態顯示和交互

      · XML和XSLT-用于數據交換和操作

      · XMLHttpRequest-異步數據檢索

      · JavaScript-用于把前面這些技術"捆綁"到一起

      在AJAX出現之前,實現"復制"本機應用程序所具有的豐富的和可交互的設計相當困難。AJAX在解決這些問題方面與其前應用的一些技術存在明顯不同,因為它基于已經為眾多開發人員所熟悉的現有的、非專利性標準。

      在傳統型web應用程序中,大多數用戶行為都會觸發一個HTTP請求。然后,由服務器進行一些處理并且把結果返回到用戶。在服務器處理過程中,用戶只能等待!從技術的角度來看,web應用程序的這種"開始-停止-開始"特征并沒有什么不好的地方,但是這并沒有從用戶交互的角度來解決問題(因為幾乎所有的用戶交互都要導致到服務器的處理,而在服務器進行這一處理時,用戶只能等待!)。

      通過使用AJAX引擎,AJAX解決了這個問題。在會話的開始,AJAX應用程序加載AJAX引擎。AJAX引擎以JavaScript開發(作為一個JavaScript庫)并處于一個隱藏幀中。用戶與AJAX引擎進行交互而代替原來的與web服務器交互。如果用戶交互并要求到服務器的處理,那么,該AJAX引擎自己來處理當前交互。當用戶交互需要一些來自服務器的數據時,AJAX引擎將進行異步地調用(經由XML/XMLHttpRequest API)而不會打斷的用戶的"思路"。

      AJAX是"異步的",其含義是指,AJAX引擎與服務器的通訊以及與用戶交互是異步的。因此,用戶能夠得到一種"無縫的"體驗(也就是說,用戶不必等待)。

      當前,AJAX背后存在一種"動力"-開發人員已經熟悉對于這種技術支持的背景,并且所有組成AJAX的技術都已經成熟并穩定起來。AJAX成為web上許多新型應用程序的基礎,例如Google suggest,Google Maps,還有Flickr和Amazon的A9.com的部分實現。

      三、移動應用程序開發模型及其缺點

      從上面的討論和有關參考文章來看,AJAX能夠明確地解決上面這兩種問題,也即是能夠提供一種優異的UI和一種標準化形式的數據檢索。其實,這兩個問題也可以應用到移動設備,而且通過擴展,AJAX也能夠有效地解決這些問題。然而,我相信,其功能遠非這些!具體地說,它將會解決移動環境中的下列問題:

      1、市場份額問題

      2、移植問題(特定于下載應用程序,就象基于Java ME構建的那種)

      3、應用程序無障礙發布問題

      另外,它還有大量的社區開發人員在背后支持它-這也是很重要的一個方面!

      讓我們考慮現有移動應用程序開發。移動應用程序共有兩種主要種類:瀏覽性應用程序和下載性應用程序。當然,還有其它類型(就象消息發送應用程序、SIM應用程序和嵌入式應用程序),但是我們今天所見的大多數的應用程序應該屬于下載性或瀏覽性應用程序范圍。

      瀏覽性應用程序:從概念上講,瀏覽性應用程序幾乎類似于瀏覽web的程序,但是又具有特定于移動性的限制(例如,小型設備尺寸)。類似于web,服務可以通過一種微型瀏覽器加以存取-它使用一個URL來定位一個位于無線web服務器上的服務。客戶端幾乎不具有任何處理能力。

      與瀏覽性應用程序相比,下載性應用程序(智能客戶端應用程序)是這樣一類應用程序:首先要下載它們,然后安裝到客戶端設備上。然后,這些應用程序在本地設備上運行。不象瀏覽性應用程序,一個下載(或智能客戶端)應用程序在其運行時不需要連接到網絡上。下載性應用程序也被稱作是"智能客戶端"應用程序,因為客戶端(也即,移動設備)能夠進行一些處理和/或具有一定的持續性存儲能力(緩沖)。當前,大多數基于Java的游戲都是下載性應用程序,也即它們被下載到客戶端,并要求在客戶端作一些處理并且不需要總是連接到網絡上。企業移動應用程序,例如銷售行業自動化,也是經常的智能客戶端應用程序的例子。

      Java ME是開發下載性應用程序最常用的方式,而XHTML是開發瀏覽性應用程序最常用的方式。下面,讓我們詳細闡述前面所提到的問題,然后討論AJAX技術是怎樣解決這些問題的。

      問題一:市場份額

      移動應用程序是主要的消費者應用程序。就象這一時期正在發展中的其它工業一樣,移動數據工業也是一個正在興起的行業,它僅占有一定的市場份額。為了達到商業性運營目的(特別是考慮到網絡效果的需要),消費者應用程序需要有大批的用戶群體。

      上面市場的運作可能基于單個的專利標準,例如來自于Qualcomm的BREW(這顯然有它的不利之處)或者通過不受任何企業實體控制的具有很少工業障礙的開放標準。

      為了說明市場份額怎樣影響一種新的服務的商業生存能力,我經常推薦使用下列途徑(其中,大多數的數據都能夠容易地從網上獲取)。其思想是,使用"同心圓"理論試圖估計出你的應用程序的目標用戶群。

      下面是我使用的一個示例步驟:

      1、準備發行你的應用程序的國家有多少人口?

      2、在上面的人口中,人均手持設備占有率是多少?

      3、在這樣的人口中,你想雇用什么樣的操作員?(大多數國家都有多種類型的移動操作員)

      4、在這樣的人口中,你的目標手持設備是什么?(并非所有的操作員支持所有的手持設備)

      5、使用什么樣的發布技術,是Java,SMS,還是WAP?

      6、應用程序是否有任何特殊技術需要,例如基于位置的服務?有多少人擁有支持這種技術的手持設備?

      7、你的市場分割分析提示了什么規律?(最簡單的分割是男性/女性,預付/后付,等等)

      8、你的市場渠道有哪些?

      9、我們期望達到什么樣的市場份額,并且基于我們的市場預算把它們轉化為多少顧客數?(也即,轉化率-典型情況下大約為2%)

      這將為你提供你的目標用戶群數,并且這個目標用戶群數乘以每月潛在的下載數應該為你計算出你每月的收入。而且,這還能夠直接聯系到你的費用底值-包括你的開發費,移植費等等-以達到一種更為客觀的在這種新型服務上投資所存在的成功/失敗率的認識。

      上面的方法揭示了一個市場份額問題,并且它暗示,今天很少的移動服務能夠贏利。因而,我們可以創建一種增殖服務-'廣播內容應用程序',例如ringtones和圖像軟件;但是,在大眾市場上具有極少的相應的工具應用程序。

      問題二:移植問題

      這個問題特定于所下載的應用程序(在Java ME中更為普遍)。在Java ME環境下,"書寫一次到處運行"只是個玩笑而已!請不妨考慮一下典型地使用Java ME開發的移動游戲(一種可載的應用程序)的情況。

      首先,好的方面在于:

      · 據報導,有些運營商,例如Sprint,目前其移動游戲和其它數據服務占居他們每年收入的大約百分之十;

      · 工業咨詢公司Ovum注意到,現在,全球市場上存在超過四億五千萬支持Java技術的手持設備,還有三千八百萬和一千五百萬支持BREW和Symbian的手持設備;

      · 移動游戲出版商在2004年在全球的銷售達到12億美元,并且在2005年有望達到一種更強的銷售勢頭,因為越來越多的消費者發現其實這種微型游戲控制臺實際上早已存在于他們的手機上。

      但是,接下來讓我們看一下不利的因素:

      · 游戲移植通常需要開發人員適合于不同的屏幕分辨率,處理器速度,內存量限制和音頻能力,所有這些都因設備不同而存在很大差異。

      · 對于出版商來說,這會使他們錯過在一個高度競爭性的工業中關鍵的市場機會。

      · 作為一個示例,設想你是一個中等規模的游戲出版商,總共有30部游戲。為了實現你的游戲能夠在全世界范圍內以五種語言并且僅在50種設備上可用,你需要創建7,500種不同的發布版本。以每一種發布版本需要花費$2,500計算,你需要一項接近于一千九百萬美元的移植處理預算。

      這嚴重地限制了業務規模,并因此使得極少的移動游戲能夠贏利。

      問題三:應用程序"無壁壘"發布

      前面使用Java ME技術進行移動開發的每一個示例所存在的困境說明,僅僅創建一種社區(正如Sun所做的,就技術而言,其一直運行良好)是遠遠不夠的。該技術和基于之創建的應用程序必須保持同類和可互操作以支持網絡效果并且獲得關鍵的客戶群體。一種平臺存在越少的"瓶頸",則對整個工業來說意味著這是更好的事情。

      四、為什么AJAX能夠替換JavaME和XHTML而成為更受歡迎的移動開發平臺?

      AJAX能否解決上面提出的問題呢?我的觀點是,可以。AJAX被通過瀏覽器加以存取。顧客能夠使用兩種方式得到瀏覽器-或由制造商把瀏覽器預安裝到手機中,或把瀏覽器作為一種獨立的應用程序進行安裝。

      任何人都可以下載一種智能手機瀏覽器,正如這里的Opera鏈接所顯示的60種系統的手機的情況一樣。這意味著,所有的顧客能夠潛在地安裝他們自己的瀏覽器,并且如果有足夠人這樣做,那么我們就有了關鍵的用戶群體問題-憑借著極少的"瓶頸"。

      而且,AJAX提供了一種優異的用戶體驗并且已經得到開發人員社區對它的支持。解決了關鍵的用戶群體問題可能性(由于更少的瓶頸)意味著更多的應用程序贏利機會-導致一種更好的應用程序的良性循環。

      今天的Java ME已經表現出存在嚴重的缺陷(并不是這一技術本身而是業務模型),而XHTML也將成為"過時",因為AJAX將提供一種優異的用戶體驗。因此,我相信,AJAX將會成為移動應用程序的更具優勢的開發平臺,從而嚴重影響Java ME和XHTML的市場。

      五、備注

      · 我已經說過"首選"而不是"替代",也就是說,我也并不盼望AJAX取代任何技術

      · AJAX不可能解決所有的問題。你仍然需要創建一種對移動顧客有用的服務

      · AJAX并非是創建一個更好的接口的唯一嘗試。也存在其它一些技術嘗試,但是僅有非常有限的成功,而且不是"跨工業性"的(或是專利性的)。例如來自于bitflash的移動SVG,superscape的用于3D游戲的轉向技術(其實,它是JSR 184-針對Java ME的移動3D圖形API的一種實現),還有Macromedia(現在的Adobe)的移動技術,等。

      · 并不是有大量的人在實際瀏覽移動互聯網。盡管WAP的使用顯示出一種增長勢頭,但是,這些數據(包括把WAP作為一種傳輸機制使用)典型地僅用于下載內容。換句話說,你每次都要下載一個ringtone,而且你還要隱式地創建一個WAP頁面。總之,我懷疑實際瀏覽移動互聯網的消費者數字可能很低

      · 極少的移動操作員曾經嘗試過加入到社區開發人員中。實際上,我能夠想到的唯一例子只是source o2

      · 一部分開發人員可能會從我與一個北朝鮮供應商的討論(當時我是在漢城的imobicon進行這一談話的)中得到一些啟示。這位供應商最終設法把他的游戲顯示到一家UK portal上。然而,這是因為一個北朝鮮聚合器設法與一個UK聚合器通訊的結果。因此,他現在擁有兩個聚合器和一個雇傭操作員!而他自己卻留下很少。這真是一件極其令人難過的事情。肯定存在某種方法來全球性創建和發布應用程序,也就是說,你要進行瀏覽器編程并且使用瀏覽器的任何人都能夠下載和運行你的應用程序

      · 移動操作員經常在處理收費和位置服務,等等問題上進行爭論。這是不錯的-但是讓我們還是首先關心一下數字的問題吧。另外,收費都要付出一定的代價并且可能網上存在更好的收費機制。

      六、小結

      總之,移動應用程序首先是消費者集中的。他們需要關鍵的用戶群體問題。當前,該市場還相當不成熟,而且當前的商業模型也支離破碎。AJAX提供了一種潛在的更好的解決方案-比較于Java ME和XHTML來說,因為它的良好的發布機制而且組合了更少的潛在的瓶頸。所以,當前的經濟模型并不積極支持Java ME,而AJAX提供了一種比XHTML更為優異的用戶體驗。它得到社區開發人員的大力支持。

      最后,請注意,我已經說過AJAX將成為"首選"模型而不是"唯一"模型,我也并不盼望AJAX取代任何技術-Java ME或XHTML。

      分享:在指定應用程序域中執行代碼
      以下為引用的內容: // // 在指定應用程序域中執行代碼 // // // using System; using System.Collections.Generic; using System.Text;

      來源:模板無憂//所屬分類:.Net教程/更新時間:2008-08-22
      相關.Net教程