开发跨UI体系的Symbian应用

一直以来,Symbian都是基于OS + UI体系分离的设计,这种分离又不同于Android,后者的不同UI只是视觉呈现的差异,对应用而言,是完全兼容的。但Symbian的不同UI体系,如S60、S80、UIQ、QT等,彼此间连UI的API都不兼容,对应用开发者来说,这真是一个噩梦。虽然也可以通过将UI API的使用限定于Uikon UI(S60、S80、UIQ等当代UI体系共同的继承源),从而实现最大程度的兼容,但这样做是以牺牲广泛的可用UI元素为代价的,对稍复杂的应用而言都不太现实。况且即将取代现有各种UI体系的QT,又是一次颠覆性的变革,不用指望任何的兼容可能了。

那么,在这样一个变革到来之前的暗夜,如何开发一款可跨UI体系的Symbian应用呢?这并非没有可能,但有着诸多的限制。如果你的应用能满足这些限制的话,那么完全可以成为真正意义上的跨UI体系的Symbian应用。

以我在2004年开发的FontRouter为例,它可以堪称一款具有代表意义的跨UI体系应用。从2004年到现在,它只发布过两个版本体系,一个适用于Symbian OS的6、7、8版本,另一个则适用于现今的Symbian OS 9.x,却可以用于目前所有已知的Symbian机型,包括最早期的Nokia 9210到最新的N97。之所以仍然出现了两个版本体系,并不是为不同的UI体系。做Symbian开发有一定时日的朋友应该都明白其中的原委,简而言之,Symbian OS 9是一个全新架构的OS版本,它甚至忍痛抛弃了对此前OS版本应用接口的二进制兼容性。因此,没有任何应用可以同时兼容Symbian OS 9前后的手机。由于FontRouter只使用到Open Font System接口,这是属于OS体系内的部分,与UI体系无关,因此无论是S60还是UIQ的手机,都可以无障碍的使用它。FontRouter最后一个版本发布时,S60 v5还未推出,但它却能很自然的兼容新的UI体系。对与即将到来的采用QT UI的Symbian^3,不出意外的话,也完全能够正常使用FontRouter。以前很多朋友问及为什么不给FontRouter编写一个配置程序,答案很简单,因为我希望继续保持它“无UI设计”的魅力!:)

当然,FontRouter只是一个很极端的例子,毕竟大部分称得上应用的程序,都不可避免的要与用户进行交互。那么如何才能实现包含用户交互的跨UI体系的应用呢?

对于开发者而言,有一个简单易行的办法,就是使用“Console API”,比如调用printf()和scanf()实现简单的交互。但这毕竟也不能作为一个应用的正式UI,那如何才能实现真正意义上的跨UI体系用户交互呢?

仍旧拿一个典型的例子来说明,比如一款“短信过滤软件”。这个应用有两个主要的用户交互:

(1)编辑过滤规则和行为
(2)让用户查看过滤的短信

对于第一个交互,我们可以采用这样的方式:软件安装时,事先在手机的联系人中创建一个分组——“短信黑名单”,并在其中创建一个示例联系人“XX商城”,其“电话号码”一栏即需要过滤的短信发送源号码。这样就直接利用了手机内置功能的UI为我们的应用提供了支撑。这样的设计不仅避免了引入应用UI,还能起到与手机操作习惯无缝集成的效果。比如用户收到一个新的垃圾短信,需要过滤发送源时,只需要直接从短信界面中创建一个联系人,并将其添加至“短信黑名单”分组即可,而不必像很多现有的短信过滤软件那样繁琐:进入到该应用中,创建一条规则,还得把短信源号码复制过来。而如果希望按字词过滤,则可以创建一个包含“备注”字段的联系人,并在该字段中填入希望过滤的字词。

同样的,第二个用户交互也可以很轻松的借助手机内置功能的UI。被黑名单过滤的短信可以直接移入一个特定的短信文件夹,比如“过滤的短信”。这样用户可以方便的直接从熟悉的短信界面中查看这些过滤的短信,而不必去学习和适应第三方应用的界面,其实也从一定角度改善了用户体验。

当然,直接借用内置功能的UI对新用户而言也有一个了解的过程,他很可能因为找不到这个新安装的应用图标而陷入困惑中。那么,我们其实可以采取一个简单方式引导用户,那就是在用户的短信收件箱中直接放入一条新彩信,包含一个简短而图文并茂的“快速入门”(最好在用户从收件箱删除该彩信后,再为用户在短信文件夹中保存一个备份)。这样,整个用户体验就完整无缺了~

或许你还是会坚持说,“短信过滤软件这个例子仍然无法代表更普遍的应用场景”,那么接下来我们再探讨一些更为通用的跨UI体系交互的手段:

(1)借助类短信的方式实现问答式交互。很典型的例子是移动运营商的短信服务号(比如10086),你可以通过发送约定的语法(以及可能的后续多次回复)到该服务号码完成功能的定制和修改等操作。应用程序也可以借鉴这种思路实现一个简单的配置交互,唯一不同的是,用户只需把该短信保存在草稿中,应用就可以提取该信息并通过在收件箱创建新信息完成问答式交互了。

(2)Widget方式。这应该是最有潜力的一种跨UI体系交互方式,但考虑到目前Widget并未被广泛支持且标准尚未统一,所以可能适用的机型并不算多(以Nokia新机型为主),也就失去了起跨UI体系的意义。

(3)借助Web UI。应用中集成一个微型的Web/WAP Server后台服务(可以直接采用Nokia Labs发布的Mobile Web Server),并在安装时创建一个应用入口的书签,提供基于XHTML/WML的UI。毕竟大部分的手机都含有基本的Web/WAP浏览器,所以理论上的通用性还是不错的。但并不是所有机型的浏览器都可以像Nokia那样方便的进入(待机界面长按“0”键),所以易用性上仍有些许障碍。

更多的思路和看法,欢迎各位前来发表你的见解!

《开发跨UI体系的Symbian应用》有9个想法

  1. 顺便透露一下,目前正在开发中的一个应用,也将采用UI-less的思路,并且具有比上面例子中的“短信过滤软件”更优雅的用户体验无缝集成。:)

  2. 我第一次知道Fontrouter可以应用于S60 5th上是在国外的某个博客上,一直以为它只能运行于Symbian 2nd和Symbian 3rd。其实我之前对于Fontrouter有一次想法,就是有一个用户界面,用户可以在里面设置字体大小之类的功能,而不用通过Fontrouter.ini,现在看来如果Fontrouter是这样的话,可能就无法和新的系统进行兼容了。

    另外就你刚刚说的,利用系统UI,我个人觉得这是一个很不错的想法,这样的界面对于用户比较熟悉,而且可以大幅减少软件的体积,提高工作效率,不论对于用户还是开发者来说,都是好事。

    确实,现在widget都无法运行在部分MR机型上,更多的S40就别说了,所以这个我觉得不可行;关于短信实现交互界面,我觉得这个比较复杂,而且不同的软件有着不同的使用方法,这样会让用户觉得麻烦而放弃使用该软件;由此可见,我赞同最后一个方案。

    个人愚见……

  3. 你好,不知道通过严格将系统中使用ui类限制在所有上层ui框架的共同基础(比如UIKON),这样能不能实现类似的跨ui程序呢?

      1. 你的这个UI less的设计方法很有用,现在我做的一个小程序就无法实现跨ui体系。虽然几乎没有用任何avkon的ui控件。应该再调整一下在原理上是可以实现跨ui体系程序的哈。

        不过在这个console app中所有消息都自己处理了,所以现在没有办法使用eikedwin这个类让他帮忙调出fep。现在正在想办法。。。

        希望能和您交流一下,如果在console程序中调出默认输入法并获取它输出的字符。。。:)

  4. 你好像提到了,确实也会牺牲大部分可用的UI元素。今天搜fep的实现来到你的blog,真的很好。:)

  5. 你好,看到你之前发表的:当心PayPal支付中的汇率陷阱 一文,我想请教一下,“兑换选项”:

    PayPal提供了两种方式来兑换货币。

    * PayPal币种兑换程序
    * MasterCard 与 Visa 币种兑换程序

    以上这个选择是:
    在每次发生交易时,我们要在交易页面寻找后选择?
    还是在自己的:PayPal管理页面中一次性设定?

    谢谢指教。^_^

发表评论

电子邮件地址不会被公开。 必填项已用*标注