`
sweetbox1519
  • 浏览: 12424 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
最近访客 更多访客>>
社区版块
存档分类
最新评论

WAP 2.0设计原则

    博客分类:
  • WAP
阅读更多

做了一年wap开发了,把收集的相关资料晒一晒

 

1 设计站点前的准备工作

      在设计一项既要面向移动设备又要面向PC的服务的时候,首先需要进行移动设备用户界面的设计。把面向移动的服务扩展到PC环境通常要比其相反方向扩展要容易一些。
如果起始站点是一个PC Web站点,强烈建议把PC服务分解成若干部分。在移动环境中,仅挑选那些可以作为服务核心的部分。在设计移动服务时,要把注意力集中在这些核心部分上。
研究市场上各种移动浏览器的物理特性,以便用XHTML和CSS进行有效的应用软件设计。你需要知道文档、样式表以及图像的最大许可大小,可以用于显示内容的屏幕空间的物理大小,以及为其它物理实体,如软键文本、图标、标题等,预留的屏幕空间。诺基亚手机有一个包含图标的标题行,标题行还可以包含XHTML页面的标题。还有一个用于显示XHTML页面(不包括标题)的内容区域,以及包含一个或多个软键文本的区域,软键的个数取决于移动设备的类型。


2 设计优秀站点的基本原则

       XHTML MP 和CSS的引入创建了多种新的用户界面结构。XHTML MP包含的元素比WML多,并且利用CSS,可以通过多种方法修改元素的可视化显示。XHTML MP为服务提供者提供了更多把他们的服务变得更有吸引力的可能性,但同时,XHTML MP也增加了设计的复杂度,从而在可用性上面临更多的挑战。


3 关注导航模型

       应该基于一致、易学的导航模型创建便于使用的用户界面。这比使用XHTML的所有花哨的显示功能都重要。
       移动用户的需求及期望与使用台式PC的用户不同。移动用户不是浏览者,他们更希望能够快速、轻松地访问特定信息。因此,应提供简洁、精确且快速的信息。
避免在过多页面或闪烁屏幕中显示核心服务内容;然而,可以在其中显示一个小logo或其它的加亮商标,以使用户熟悉服务。无论如何,应能立刻显示用户要求查看的重要信息。
       在移动设备中,数据的输入非常有挑战性,并且比较费时,故在创建站点时,尽可能少地要求用户输入,尤其是文本输入。
       如果可能,在用户做选择时,应避免让用户打字,考虑利用选择列表、复选框或单选按钮让用户从默认的列表中做出选择,或提供一个默认列表和一个输入框。
当不得不要求输入的情况下,利用属性-wap-input-format设置输入模板,例如,*N代表数字输入。这样可以避免手动转换输入模式。
       CSS的属性–wap-input-format为用户输入的数据定义了一个输入模板,从而去除了为文本或数字转换输入模式的需要。因为一些非诺基亚XHTML MP浏览器的早期版本不支持该属性,它们支持旧属性format="…",因此,对同一格式字符串,应同时定义CSS属性–wap-input-format和属性format。关于WAP Format输入模板的语法,可参见WAP June 2000 specification [WML] 或 WAP Overview [WAPOver]。
       许多用户以分钟为单位支付移动服务,因此,如果他们无法在短时间内获得要查找的信息,就会停止使用该服务——这也是遵守以上要点的一个重要原因。


4 设计导航层次

       导航模型是用户浏览XHTML页面的方法,XHTML页面由服务、通过链接进行的交互、菜单和数据输入组成。在设计导航模型时,牢记以下原则:
• 在整个服务中保持导航模型的一致性。
• 对于XHTML服务,避免加入返回到之前访问过的页面的链接,因为诺基亚移动浏览器有一个永久的Back软键,可以自动地实现该操作。
• 避免创建过于“深”的服务。如果一个服务包含的层次多于4或5个,用户通常就难以保留服务的总体印象。
• 加入返回到服务的起始页或其它主要分支页面的导航,这样用户就可以轻松地返回到他们的起始点。导航层次越多,就越需要一个返回到起始页的方法。

5 针对小尺寸屏幕的设计考虑

预测显示,全世界移动设备的数量将很快超过PC的数量,这给适用于小尺寸屏幕的界面友好的应用软件带来了巨大的商机。当然,在小尺寸屏幕上设计富有创造性的应用软件更有挑战性,但为移动设备设计具有吸引力的应用软件并非不可能。牢记下列条款:
• 确保用户进入页面时有可见内容。
• 在<head>元素中用<title>元素为每个页面定义一个短小标题。通常,标题不应多于14个字符,除非你能够定制页面使其适应用户设备的特定特征。
• 在一个服务的所有XHTML页面中使用一致的样式。一致性增加了易用性——尤其是对于重复使用该服务的用户。
• 尽量减少水平滚动的需要。水平滚动除了比较费时之外,用户还将难以判断他们在整个页面中的位置。如果可能,设计的内容不要宽于或长于目标设备的显示屏。
• 利用元素的对齐属性(lef, right, center)来增加可读性,但不要在同一页面中使用多于两个或三个属性,因为这阻碍了用户获取组织结构。
• 使用空白空间,尤其是在高而窄的图像旁边。可以通过在<img>元素中使用属性align实现此目的,例如:
<img align="left" src="sky.gif" alt="Sky Picture"/>
       此外,可以在CSS中为<img>元素设置悬浮属性和其它属性来实现此目的(以及更多其它目的)。悬浮图像允许在图像旁边显示文本 ,从而利用了整个显示区域。
• 避免过多使用文本强调属性,如粗体,斜体和下划线等,因为这降低了小显示屏上内容的可读性。
• 如有可能,尽量使用短小、精确的字词,避免使用冗长、复杂的字词。
• 避免在同一页面中使用过多不同颜色。尽管颜色可以给一个服务带来更多“活力”,但是过多颜色会导致超载。使用颜色时要尽量保持一致性,例如,整个服务中的相同XHTML元素使用同一种颜色。
• 不要用名字描述颜色,例如,“按下红色链接继续”。没有彩色显示屏的客户终端会以黑色和白色显示彩色内容。


6 保持较短的文档大小

       因为移动设备中可用的内存有限,故应使文档尽可能短。然而,因为XHTML MP与WML不同,它不能在一个文档中支持多“卡片”,故把内容分为多个独立页面将会使载入的速度减慢。因此,应把所有相关信息结合在同一页面中,并利用分段锚来帮助跳转至相关章节部分。
保持文档较短的有用方法包括:
• 代码中不要包含长注释。尽管在代码中添加注释通常是良好的编程习惯,但对于移动设备来说,这是不适用的。
• 在缩进时利用tab而非空格,或者不使用缩进。空格越多,文档大小增加越快!
• 文件名、CSS类和CSS ID应使用简短名称。
• 在可能的地方,用层叠规则定义样式,而不是在元素中用类或属性ID。例如,在WAP CSS样式表中,使用如下的属性:
p (color:red)
而不是下列的类属性:
.red {color:red}
这样就没有必要在文档中的每个<p>元素内定义字符串class="red"。

7 为移动电话设计应用软件

当开发人员要决定移动终端的各种应用软件应包含什么信息时,他们应考虑用户在什么情况下使用移动电话。服务内容应满足目标用户群的需要,并且应该对最常见的任务进行最优化。由于较小显示设备便于移动,所以,在没有PC机的情况下,用户可能会首先使用移动电话访问英特网以及获取急需信息。相应的范例包括快速访问航班信息、查看简讯和天气情况等。但用户使用移动电话上网冲浪的可能性要小。


8 保持用户任务流的流畅及图像的合理使用

       彩色页面看起来很诱人,但当图像传输使得服务减慢时,彩色页面也许并不让人觉得很舒服。根据可用性研究1, 用户不太热衷于那些由于图像传输而中断他们任务流的服务。特别地,当用户在搜寻目标页面时,大的图像就不太合适。含有信息价值的图像是令人青睐的,但在多数情况下,用户或是关掉图像以节省时间和金钱,或是不等图像下载就切换到下个页面。在下载所有图像之前允许用户继续浏览页面,是很重要的。
       大表格也许会产生相似的问题——也就是说,在某一页面下载完之前,用户的操作被冻结;或者在页面下载完之前不能继续进行其他操作。因为移动电话显示屏的大小不同,所以开发人员应确保即使是在最小的显示屏上,也能够阅读数据表格;通常这些数据表格要进行压缩以符合显示屏的要求。

9 结构对新用户要简单但也不能忽视熟手用户

       在移动通信服务中,浅层结构似乎常常比深奥结构更容易理解。链接和页面应该冠以描述性的名称,这样可以帮助用户找到他/她需要的信息。很难说在一个链接列表页面上应该提供多少个链接。如果链接明显属于同类且容易浏览(每个链接占一行,以字母顺序,或另外以逻辑顺序排列,这样用户就不必把每个链接都读一遍),那么,比较好的方法是在一个页面上提供30个链接,而不是每个页面上提供5个链接,总共需要6个页面。如果有好几十个链接,在显示这些链接前提供排序选项是个不错的主意。如果链接能放置在一行上,则选择起来一目了然,页面也更美观.
       WAP 2.0没有<do>元素,相反,它们由access keys取代。然而,大多数用户似乎并不了解access keys元素,并且无法找到他们。为了帮助用户理解accesskeys的概念,开发人员应确保accesskeys在屏幕上可见,而且以类似电话键的形式出现。如果有可能,应提供搜索功能。熟手用户很欣赏这个功能,正如新手用户浏览著名站点一样。


10 在页面上提供足够信息


       交互式页面应该简短,信息页面应该较长32。不建议使用门面页面来启动站点,门面页面除了问候访问者和显示logo外,没有其他作用。较好的方式是用户能够直接访问服务。
在XHTML下,信息以页面形式下载,而不是以WML下的deck形式。这意味着向用户提供单个页面上的信息以支持他们的任务流就显得更为重要。由于XHTML页面是各自独立下载的,所以在XHTML页面间来回切换可能会消耗更多的时间。后向导航尤其存在这种情况,在这些情况下页面不能缓存,例如,与付帐或提供私人信息有关的系统就是这种情况。
       任何页面的第一屏(最顶端)都是最重要的。所有经常使用的导航链接、搜索域、登录屏幕和大量信息都驻留在那儿。用户可在页面的剩余部分加载之前向前浏览,并且无需滚动页面。
       应避免在页面顶端放置横幅广告或没有任何信息的图形。最好是把广告放在页面的左侧或右侧边框。
       上下滚动页面是困难的,因此带有表格的交互式页面不应该太长,因为用户不能确信他们是否已经填完长表格上的每个域。如果表格所占空间超过两屏,用户可能容易失去控制感。
       用户访问的目标页面应该具有足够多的信息。例如,如果目标页面包含故事或用法说明,则应该在一个页面上显示所有内容。当用户浏览一个长而信息量较大的页面时,能够在页面内引导用户的子标题将帮助用户浏览页面。
       信息是以单个页面下载而不是以deck下载的这个事实是影响导航以及WML和XHTML之间结构性差异的最大单个变化。


11 为用户操作提供信息反馈

开发人员应该对用户操作、以及错误和问题情况提供正确的反馈。例如,在用户点击链接之后,页面标题应该与链接名相同。减小导航步骤应该不增加用户的不安全感,例如,用户操作的确认页面是必要的,尽管这些页面需要再次点击。如果确认页面丢失,用户也许觉得她/他需要检查,以确认这一行为是否发生——这会导致更多次的点击。应该认用户觉得他们始终在控制着系统
如果出现问题,应提示用户下一步该怎么办。向用户解释期望输入的格式以及对必填项进行标记可阻止错误发生。

12 尽可能减少图像数量和减小图像容量大小

       应该认真考虑一个XHTML页面上图像数量和容量大小。页面上的每一幅图像就产生一次独立的来回,这反过来使整个页面的显示速度减慢。因此,应该尽量减少来回的数量。还要注意的是,当每次一幅图像到达移动设备时,整个页面的内容可能需要重新排列,这会占用时间和处理器资源。因此,一个仅有几幅图像的页面也许比一个有许多更小图像的页面下载得更快。如果有可能,建议在全部服务中各个页面上使用相同的图像;那么一个特定的图像只需下载一次且能够保存到高速缓存器中。例如,如果自定义的图像被用作bullet,则在整个服务中应该使用相同的图像。
       TCP/IP 连接也许会造成页面下载速度的不同,即使其数据量相同。例如,下载一个包含四个图像(每个图像大小为2 KB 的XHTML页面)要比下载一个包含八个图像(每个图像大小为1KB的页面)的速度要更快。
       如果使用WAP网关,则WAP网关应与GPRS支持GGSN放得近一点。在这个例子中,“近”是指数据延迟及数据包丢失的概率。由于HTTP重传,丢失信息会产生附加延迟。WAP网关和内容服务器间的时延应尽可能的小。


13 定义图像高度和宽度属性

       建议内容开发人员在标记语言中明确地指定图像的高度和宽度,以使浏览器为图像预留适当的空间。如果在图像标签中使用高度和宽度参数,那么XHTML浏览器就能在下载图像之前为图像预留空间。因此,在图像下载之前页面就能够显示出来,当然,图像在下载后也能够出现在页面上。这并不影响XHTML页面的完整下载和处理时间,但却大大改善用户的感受,因为在下载图像之前用户可浏览页面。例如:
<img src="pics/header_main_page_001.gif" width="175" height="41" />


14 谨慎使用表格

       XHTML页面浏览器支持表格和嵌套表格的使用。在定义表格单元宽度,尤其是处理嵌套表格时,开发人员应谨慎行事。
      CSS single-pass (固定)算法能够用于设计表格布局以便优化CPU利用率。然而,与CSS multi-pass (动态)表格布局算法不同,固定表格布局算法根据表格的第一行来确定表格的列数及其大小。因此,通过使用具有明确列宽的矩形表格可以获得最佳性能。
       如果要用嵌套表格,当明确指定子表格的宽度时,开发人员应避免用子表格宽度的一定比例来指定其父表格的宽度。因为设备具有不同的屏幕尺寸,所以百分比不一定能够表示相同数量的象素。因此,建议在父表格及其嵌套表格中使用绝对宽度(像素)以确保内容能正确显示。注意必须确保表格的总宽度与所有列的宽度加上边框和单元格间隔的总和是一样的。一般而言,当表格嵌套层数增加时,页面的复杂度和显示页面所需的处理时间也会增加。为了确保能够及时显示页面,应该避免使用嵌套很深的表格。
       另外,表格的边框不应该太粗,因为对于显示屏尺寸受限的设备来说,其边框宽度容易占用很多像素,从而使得实际可用的内容区变得太小。


15 考虑添加样式定义选项

       开发人员可以用各种方式来定义自己的样式,例如:使用外部样式表、使用文档头部的样式元素,或通过使用指定元素的行间样式属性等。一般而言,虽然使用外部样式表无论何时都有可能把样式从标记语言中分离出来,这是一种好的方法,但应注意权衡考虑。如果样式定义包含在XHTML代码中,则XHTML页面的显示就更快,但是外部样式表的使用提供一种在整个服务中更改样式的便利方法。在整个服务中应该使用相同的外部样式表以避免把多个样式表下载到电话上。外部样式表仅需下载一次并能够保存在高速缓存器中。 


16 删除代码内不必要的空白区和代码内的注释

       确保代码内没有多余的空白区非常重要。虽然空白区在屏幕上是不可见的,但仍要被处理,因为浏览器要对空白区进行分析、排版、CSS分配和显示等。
XHTML代码内注释数量应尽量地少,以使代码尽可能地紧凑。


17 使用HTTP标题指示来支持页面缓存

       浏览器能够把已经阅读的XHTML页面放在缓存器中。然而,内容开发人员不应假定页面缓存是默认的。如果可能,应与文档一起发送明确的缓存标题以确保页面在客户端能够缓存。另外,应将过期时间设置为至少数天,这是为了确保在跨越多个时区的情况下,内容能够缓存一段适当的时间。
浏览器不支持在Meta 标签内 (例如,使用 HTTP-EQUIV)放置缓存指示,但可用HTTP标题控制缓存。HTTP 服务器可设置"Cache-control: no-cache" HTTP标题指示,而此服务器放置了能够定义“页面不进行缓存”的页面。
       缓存使用“最近最少使用”算法,这意味着最少使用的项首先被清除。建议重复使用所有XHTML页面内的图像和外部CSS,以确保它们留在缓存中,以便每次使用它们时不需要重新下载。
注:在Series 60移动设备中,默认设置是缓存内容,除非在HTTP头中有其它要求。而在Series 40移动设备中,默认设置是不缓存内容。

18 使用Unicode 2.0字符集编写XHTML的内容

       诺基亚XHTML浏览器支持ASCII 和 Unicode 2.0字符集。因此,为了确保XHTML最大程度的互操作性,应该使用非拉丁语的Unicode来创建所有的XHTML内容。对于拉丁语,也可使用ASCII来创建 。有些网关和代理能把本地字符集转换成Unicode ,但并非所有的字符集都能转换。所以,保证终端接收Unicode的唯一方法就是用Unicode创建内容。有关Unicode和其他非拉丁语的更多信息,可在下列书中找到:
• CJKV Information Processing, Lunde, Ken. 1st edition. O’Reilly & Associates (December 1998)
• Unicode: A Primer, Graham, Tony. John Wiley & Sons (March 2000)

19 使用正确的MIME类型和经过验证的XHTML代码

       由OMA定义的XHTML MP内容的首选MIME类型为:“application/vnd.wap.xhtml+xml”。这一类型可以用于向XHTML用户代理提供XHTML MP文档支持。另外,也可使用 “application/ xhtml+xml”。在一些 Series 60 浏览器上,必须使用MIME类型“application/vnd.wap.xhtml+xml”以确保正确的XHTML MP内容视图。MIME类型“text/html”也是可用的,但是,对于XHTML来说,这种类型应被保留,以便用于在现有的HTML用户代理上的显示功能。应注意“text/html”格式的XHTML文档将不作为XML格式来处理。例如,这意味着用户代理也许不能检测到形式上不像错误的错误。对于既想支持XHTML用户代理又想支持HTML用户代理的软件开发人员来说,可以通过让HTML文档作为“text/html”类型,XHTML文档为“application/vnd.wap.xhtml+xml”类型来使用内容协商机制。
建议所有XHTML MP内容使用*.xhtml的文件扩展名。为了避免出现任何互操作性问题和提高性能,应该对XHTML代码进行验证。例如,可用http://validator.w3.org上的 W3C验证器来验证XHTML内容。如果动态地创建XHTML内容,则生成的代码是合法的DTD XHTML MP 1.0代码。 


20 使用描述性页面标题和元素标签

       页面标题描述所显示的页面内容。在WML中推荐使用标题,而在XHTML中强制使用标题。标题帮助用户浏览应用软件,因为它们会提醒用户她/他处于应用软件的什么位置。一个较好的方法就是标题用应该用服务的名称开头并且应该很短。用户以前选择的栏目将决定标题文本。例如,标题“书签”告诉用户显示屏包含了应用软件的一个书签列表,以及前一次选择的选项项目是“书签”。
标题文本应该使用比例字体,如果标题文本太长,文本会被自动删减。通常,删减标题的效果要比缩写更好,因为用户可能会对不熟悉的缩写困惑不解。
虽然建议元素标签使用缩略词,但不应该使用目标用户群不大熟悉的首字母缩写词。相同的标签应该总是用于相同的操作,尤其是诸如Delete、Remove、 Erase、Clear和 Destroy的功能标记。


21 使用多段/混合方式更快下载XHTML页面

       多段方式可以用来请求和传送单一多段消息中的XHTML页面内容,它可以取代目前的多个独立页面对象请求。这使得页面下载的速度更快。例如,如果一个XHTML页面包含文本、7幅图片和一个至外部样式表的链接,则所有内容可以通过一次请求获得而无需提供9次单独的请求。为了使用这一功能,Web服务器和浏览器都要支持多段方式。内容开发人员必须考虑到将页面中的所有可显示内容编码为多段消息。
如需查明哪款诺基亚手机支持multipart/mixed MIME类型,参阅www.forum.nokia.com/documents中的文档Browser MIME Types In Nokia GSM Phones。


22 进行可用性测试

       对新的应用软件进行可用性测试总是正确的选择。没有参与设计和开发应用软件的人往往会注意到潜在 的可用性问题,这些问题对于那些非常了解设计的人常常不是显而易见的。可用性测试应该在开发过程中尽可能早地进行。这样,在开发时间表内能够完成根据测试结果需要进行任何必要的更改。应该邀请能够代表未来最终用户的测试人员进行测试。如果日程安排不允许进行大量测试,至少应进行小规模测试。

分享到:
评论

相关推荐

    从Web到WAP移植的设计原则

    从Web端直接移植为WAP2.0形式,突出的矛盾是信息架构不适应小屏幕设备,垂直页面的冗长和WAP2.0表现形式的限制。 提升小屏幕浏览的体验,在设计中应包含以下几个核心任务: 控制信息的维度 信息布局,更好利用首屏的...

    手机交互设计原则

    在设计e指通客户端和wap2.0页面时,积累些手机交互设计经验,不断总结,理清设计思路。以下设计总结出手机交互设计原则,仅供参照。屏幕手机屏幕尺寸分为物理尺寸和显示分辨率。物理尺寸是按英寸对角线计算。显示...

    CSS参考手册3.0(中文)

    本手册服务对象为网页前台设计师,在参考使用中如果发现有不妥、或冒犯之处请及时与作者联系,本着取之于民、用之于民的原则,我们会不断完善和升级本手册。 使用说明: 基本特性是CSS属性的基础,初学者不易理解,但...

    Zoomla!逐浪CMS v3.1

    8、专业的WAP站点解决方案,支持智能输出WAP,并支持各类UBB编辑协议。 9、支持FLV等流媒体上传与智能播放,专注打造Web2.0时代最卓越的CMS管理系统。 10、集成OA办公系统,“云”时代让信息管理轻松惬意(商业模块...

    XML高级编程pdf

    14.2.3 WAP如何解决无线网络应用遇到 的问题 14.3 介绍WML 14.3.1 怎样将第一份文档传送到电话上 14.3.2 WML文档的结构 14.3.3 通用属性 14.3.4 WML包括什么 14.3.5 Meta信息 14.3.6 基本字符、表格和演示 ...

    XML高级编程 (Extensible Markup Language)

    14.2.3 WAP如何解决无线网络应用遇到 的问题 14.3 介绍WML 14.3.1 怎样将第一份文档传送到电话上 14.3.2 WML文档的结构 14.3.3 通用属性 14.3.4 WML包括什么 14.3.5 Meta信息 14.3.6 基本字符、表格和演示 ...

    XML 高级编程(高清版)

    14.2.3 WAP如何解决无线网络应用遇到 的问题 14.3 介绍WML 14.3.1 怎样将第一份文档传送到电话上 14.3.2 WML文档的结构 14.3.3 通用属性 14.3.4 WML包括什么 14.3.5 Meta信息 14.3.6 基本字符、表格和演示 ...

    JAVA上百实例源码以及开源项目

    例如,容易实现协议的设计。 Java EJB中有、无状态SessionBean的两个例子 两个例子,无状态SessionBean可会话Bean必须实现SessionBean,获取系统属性,初始化JNDI,取得Home对象的引用,创建EJB对象,计算利息等;...

    JAVA上百实例源码以及开源项目源代码

    例如,容易实现协议的设计。 Java EJB中有、无状态SessionBean的两个例子 两个例子,无状态SessionBean可会话Bean必须实现SessionBean,获取系统属性,初始化JNDI,取得Home对象的引用,创建EJB对象,计算利息等;...

    XML高级编程

    14.2.3 WAP如何解决无线网络应用遇到 的问题 624 14.3 介绍WML 626 14.3.1 怎样将第一份文档传送到电话上 626 14.3.2 WML文档的结构 627 14.3.3 通用属性 629 14.3.4 WML包括什么 630 14.3.5 Meta信息 630 14.3.6 ...

    java开源包1

    设计原则 容易维护扩展(不需要修改主类就可以添加新的API支持) 注入型解释器(依据不同的返回格式注入相应的解释器) 集中管理请求参数与参数映射 以运行时异常的方式来管理错误的响应 使用泛型来做强类型编程 多...

    java开源包11

    设计原则 容易维护扩展(不需要修改主类就可以添加新的API支持) 注入型解释器(依据不同的返回格式注入相应的解释器) 集中管理请求参数与参数映射 以运行时异常的方式来管理错误的响应 使用泛型来做强类型编程 多...

    java开源包2

    设计原则 容易维护扩展(不需要修改主类就可以添加新的API支持) 注入型解释器(依据不同的返回格式注入相应的解释器) 集中管理请求参数与参数映射 以运行时异常的方式来管理错误的响应 使用泛型来做强类型编程 多...

    java开源包3

    设计原则 容易维护扩展(不需要修改主类就可以添加新的API支持) 注入型解释器(依据不同的返回格式注入相应的解释器) 集中管理请求参数与参数映射 以运行时异常的方式来管理错误的响应 使用泛型来做强类型编程 多...

    java开源包6

    设计原则 容易维护扩展(不需要修改主类就可以添加新的API支持) 注入型解释器(依据不同的返回格式注入相应的解释器) 集中管理请求参数与参数映射 以运行时异常的方式来管理错误的响应 使用泛型来做强类型编程 多...

    java开源包5

    设计原则 容易维护扩展(不需要修改主类就可以添加新的API支持) 注入型解释器(依据不同的返回格式注入相应的解释器) 集中管理请求参数与参数映射 以运行时异常的方式来管理错误的响应 使用泛型来做强类型编程 多...

    java开源包10

    设计原则 容易维护扩展(不需要修改主类就可以添加新的API支持) 注入型解释器(依据不同的返回格式注入相应的解释器) 集中管理请求参数与参数映射 以运行时异常的方式来管理错误的响应 使用泛型来做强类型编程 多...

    java开源包4

    设计原则 容易维护扩展(不需要修改主类就可以添加新的API支持) 注入型解释器(依据不同的返回格式注入相应的解释器) 集中管理请求参数与参数映射 以运行时异常的方式来管理错误的响应 使用泛型来做强类型编程 多...

Global site tag (gtag.js) - Google Analytics