在看這些經驗總結之前，我強烈的建議無線開發人員及產品人員熟讀WML的規范，手冊地址：
http://www.w3cschool.cn/index-18.asp.htm
根據我們長時間開發的積累，我們在使用過程中確實遇到的一些問題，通過這些積累，使得我們找到移動互聯網開發的一些規律：
1、我可以在屏幕上顯示幾行信息？
事實上，對顯示多少行沒有特別限制，只要不超過面板的最大尺寸就行（隨設備的不同而不同）。然而，為了避免太多滾屏，每屏（即卡片）5 至 7 行最佳。當然屏不要太多，3-4屏為極限，因為考慮到目前市場上很多的山寨手機對WML頁面大小支持的不好。
2、我們應該權衡GET/POST哪些問題？
在實際開發中，確實遇到一些電話不支持使用 POST 方法發送表單數據，這種情況，我們確實沒有辦法去做兼容了。因為在實際開發中，有些數據我們必須要為用戶保密，例如用戶名和密碼必須通過 POST 方法發送。
在 WAP 網關上，如果日志功能被激活并且請求已被記錄，管理員就有能看到用戶名和密碼。如果網關是由 ISP 或其它第三方提供的，這個問題就會特別突出。
即使一個安全的連接也不能完全消除安全隱患。那些發送到 WAP 網關的數據使用 WTLS（Wireless Transport Layer Security）加密，它使用與標準 TLS 相同的算法。然而，發送到 WAP 網關的數據是二進制的編碼格式（對 WAP），所以這些加密后的數據必須用 TLS 解密和再加密以適用于因特網。經過一段時間以后，敏感數據在 WAP 網關上以明文的形式出現。黑客則會在適當的時刻，將內存中的信息轉儲出來，進而成功地訪問這些敏感數據。
按照注釋，解決該問題的一種辦法是在自己公司（而不是在 ISP）設一個 WAP 網關。在這種情況下，一個可信的人可以操作網關，并且可以關閉日志功能。
您也可以用 WMLScript 來編寫自定義的加密算法，以對客戶端的用戶名和密碼進行加密。這只有在使用簡單的算法時才有可能實現；在支持 DES 類的算法上，WMLScript 不夠強大。雖然有這么多的顧慮。
我們在實際的開發中選擇的依然首選的是GET。我們建議使用GET方式提交參數，是考慮到URL可移植、保證參數完整，但是同時我們為了保密、限長度可以在合適的地方（用戶保密數據、參數可能出現過長）應用POST。
3、我怎樣保持 Session？
我們再做任何一個模塊設計的時候都不要假設手機終端都支持cookie(雖然部分手機支持cookie，但不能保證用戶都開啟cookie)。這樣，當用戶在您的站點的不同頁面之間穿梭時，為了在服務器端保留關于客戶端的信息，在向服務器發送每個請求的同時，一個 Session ID 必須被當作參數傳遞。Session ID 的參數名根據 Servlet 引擎的不同而不同。
有時，缺省的 Session ID 長度很大幅度地增加了每個請求的長度。結果導致客戶端或 WAP 網關可能將此請求看作一個無效的 URL 而拒絕。這樣有必要縮短 Session ID 的長度。可自定義一些所短sessionID長度的方案。
4、Select 框參數的提交？
因為WAP瀏覽器的簡陋、多而雜，在不同的瀏覽器里，select提交被截獲的參數值也是不同的，如在select中，你選中了1/2/3提交后，截取的值，可能是1,2,3，也可能是1；2；3。
這點跟WEB上有些許差異，請大家多注意
5、參數簡單化？
在開發過程中，我們經常是為了頁面參數提交的簡單，即為了減少參數的提交個數，我們喜歡在WML頁面對一些參數進行拼裝。如下：
<postfield name="content" value="$(bwBall)~$(swBall)~$(gwBall)"/>，實際操作中，我們應該避免這樣的參數拼裝，僅管在WAP1.1之后確實支持一些分割符的分隔
6、編碼問題同樣是個詬病？
無論我們在J2EE/J2SE開發過程中，都會遇到編碼的問題，不同的是WML中遇到的編碼問題大多數并不是我們服務端導致的，手機廠商對編碼沒有固定的設置，很多用戶不會去關心手機的編碼，在參數提交時如果帶有中文參數，在參數接收時，就需要對參數進行處理，因為客戶端提交過來的可以是ASCII碼
7、“內部服務器錯誤”？
如果做WML開發你沒遇到過這類錯誤，那你絕對不是一個稱職的開發。在手機中報這類錯誤，基本上都屬于功能機，對應的 response code 是500。
8、WML頁面對圖片的支持度？
在WML頁面里，圖片是不被建議的，如果非要使用的話，請注意圖片不要多于5張，圖片最好要經過處理，越小越好。另外圖片的格式最好是PNG，如果有條件的話PNG、GIF、JPG最好都備上。
9、轉義字符的使用？
在WML中，跟HDML一樣，多個連續的空格只顯示一個空格；在WML中，一定要注意使用轉義字符，如：
< ----- <
> ----- >
‘ ----- '
“ ----- "
& ----- &
$ ----- $$
空格 -----
- ----- ­
特別是在URL參數傳遞過程中，源碼中&必須寫成&
10、一個標準的crad？
card是WML的單元，由此，我們可以知道一個WML頁面可以有多個card（靜態文字預加載推薦使用）。
如下是一個WML最基本的元素：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<head>
<meta forua="true" http-equiv="Cache-Control" content="max-age=0"/>
<meta forua="true" http-equiv="Cache-Control" content="no-cache"/>
</head>
<card id="index" title="愛彩票">
<p>內容</p>
</card>
</wml>
11、關于WML頁面的表單參數提交<anchor>？
有一個標準的表單提交的實例：
源碼：
<img src="http://wap.baidu.com/logo.gif" alt="Baidu"/>
<input name="word" size="4"/><br/>
<anchor>
搜网页
<go method="get">
<postfield name="word" value="$(word)"/>
<postfield name="tn" value="wisewml"/>
<postfield name="rn" value="5"/>
<postfield name="ie" value="unicode"/>
<postfield name="cl" value="2"/>
<postfield name="vit" value="uni"/>
<postfield name="from" value="578b_w1"/>
</go>
</anchor>|
<anchor>
进贴吧
<go method="get">
<postfield name="kw" value="$(word)"/>
<postfield name="from" value="578b_w2"/>
<postfield name="inb" value="1"/>
</go>
</anchor>
在這里有個很好的體現，提交文字所在的位置，這個問題，針對小部分手機會有差異（會產生頁面解析失敗的情況）。我們最好的習慣是將提交文字寫在<anchor>與<go href=”” method=”get”>之間。
12、WAP如何保證表現層可維護性？
這可能是最可怕的事情了，由于WAP業務的特殊性，合作推廣相對WAP較頻繁，如果系統開發人員沒有一個好的思想，好的編程習慣，喜歡將代碼粘來粘去（特別是頁面代碼），時間長了，這將給系統帶來毀滅性的結局。
13、低端機對WML標簽的支持？
移動終端，大家要清楚的就是這是個以簡潔為主的地盤，無論從業務上還是從技術上，WEB人員都喜歡將WEB的一套模式照搬到WAP中來，如果你真的那樣做的話，我要告訴你，你會死的很慘，很多WEB上的業務是跟WAP的用戶群的截然不同的，那么從技術上來說，也是不能通用的。
特別是低端機，很多好的效果，好的模式都是不支持的，所以說這是個簡單的平臺。
舉例：在html頁面我們會用各種顏色，各種字體，想方設法的讓展示更炫，WAP行不通的，如下標簽就不能通過---一般手機會報：內容格式錯誤
<b>粗體</b> ---------低端機不支持
<i>斜體</i> ---------低端機不支持
<img alt="pic" src="" /> ---------在使用img標簽時，alt標簽必填
如果你想你的應用以展現為主，那么有些豐富頁面的標簽你可以嘗試一下，如果你的平臺是電子商務，那么我奉勸產品及開發人員，這些標簽你還是離它們遠點。
14、如何去除WAP頁面輸入框緩存？
在WAP頁面輸入框的緩存是讓用戶感到很頭疼的東西，很多時候我們第二次訪問同一個輸入框是想重新輸入值的，結果頁面響應給我們的框里卻遺留了上一次輸入的值。還需要手動的刪除上一次數據再重新輸入數據。從這個操作上來說讓用戶體驗很不流暢，或者說給用戶使用帶來了阻力。
為了規避這種輸入框緩存，我們可以利用隨機數，如參數param我們可以寫成 param + random
15、部分手機對下拉框的支持度？
在開發過程中，我們遇到一些奇怪的問題，在WAP1.0的手機里，有些低端的手機不支持下拉框的定號選擇。如：
<select name='params'>
<option value='1'>value1</option>
<option value='3'>value3</option>
<option value='5'>value5</option>
<option value='7'>value7</option>
<option value='9'>value9</option>
</select><br/>
原本我們是希望用戶選擇的是3，則我們接受到的也是3，可是不幸的是，我們接收到的是1，通過多次的查日志驗證，確實有這樣的情況存在，即：該類型的手機下拉框全部是按照升序的值進行傳遞的。那么在我們這個事例的值就是，0,1,2,3,4而不是1,3,5,7,9。
16、部分手機對復選框的支持？
這個特性需要產品設計人員注意了，在產品設計的時候盡量避免這些復選的出現。因為在出現復選框的時候，部分手機是會默認全選的（如MOTO手機）。