在看这些经验总结之前，我强烈的建议无线开发人员及产品人员熟读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 href="http://wap.baidu.com/baidu" 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 href="http://wapp.baidu.com/f" 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手机）。