doon的专栏

嵌入式GUI的专业模板

未来GUI及其应用的研究(1) -- 原型和框架(1)--我们需要什么样的原型

1. 原型的重要性

原型的重要性在于,对于所有参与者来说,原型就是一个锚,把所有参与者都锚在一个目标之上,不至于出现偏差。

就像我们给葡萄藤搭的架子,是沿着向上延伸到基础和框架。

原型的另外好处是,它可以先行做很多可行性的验证,可以给开发者和客户带来信心和希望。


好的原型,以及可以在该原型基础上衍生的程序和应用,对一个UI组件库的推广和应用,有直接推动的作用。

一个好的开始,更容易让人接受;而原型已经事先考虑了开发中可能遇到的情况,可以从原型提供的各种示例和程序中,找到解决问题的办法,

从而,让开发人员更有信心做出好的界面来。


2 原型要做什么?

一个手机到原型,自然要有主菜单、电话、通讯录、短信等等基本的应用,而一个什么都不针对的原型,它应该包括的有:

  1. 启动画面
  2. 主界面,或者是主菜单,能够显示图标,进入到其他程序
  3. 系统级应用,比如:
    1. 文件浏览器
    2. 系统设置,如时间日期,语言设置、主题、用户管理等
    3. 设备管理,包括设备的查看和管理,如内存或者flash,屏幕、电池管理等
    4. 应用程序管理,一些应用的安装、卸载等
  4. 一些常用的应用,如:
    1. 计算器
    2. 记事本
    3. 备忘录
    4. 闹钟
    5. 日历
    6. 相册
    7. 等等
  5. 一些领域内常见的应用,如:
    1. 音频播放器
    2. 视频播放器
    3. 收音机
    4. TV
    5. 浏览器等

这是从需求的角度上分析。无论这样的系统,是应用在手机(山寨机),MP3、MP4、学习机等民用产品上,还是用于一些工业控制、医疗设备等工业设备上,只要稍微复杂一些,总是是离不开这些东西的。

工业控制和医疗、军工、安全等行业,它们的UI相对简单而且需求各异。我虽然了解不多,但是,除了上面原型中,一些具体应用和这些领域有很大差异外,其余的应用的管理等方面还是一致的。


实际上,界面是容易做的,简单的逻辑也很容易编写,但是,把他们放在一起,形成一个完整的程序,就需要仔细考量了。


从外观看起来,原型相当于一个小的完整的操作系统。但是,它和普通的操作系统还有很大的区别。它实际上是外部的UI和UX的外壳,负责管理所有和UI和UX相关的内容。


3. 原型的框架

除去对具体应用的考虑,一个合理的框架是一个原型或者说一个系统重要的灵魂。

  1. 这样一个原型的框架,至少应该包括如下内容:
  2. 对模块和应用的管理,包括应用的安装和卸载
  3. 管理应用之间的通讯和相互调用
  4. 构建统一的界面元素,管理统一的外观和主题
  5. 管理语言及其切换
  6. 构建统一的应用界面框架
  7. 为各种系统调用,提供统一的接口

3.1 应用程序的枚举


枚举已经安装的应用程序,获得他们的信息,这些有:
  1. Name,应用程序的名字,内部使用
  2. Version,
  3. Caption,显示使用提供多种语言
  4. Description,描述,提供多种语言
  5. Icons,应用的图标,可以有多个,比如,大、中、小分辨率的图标等
  6. Path,安装的位置等

3.2 应用程序的安装和卸载

这需要考虑两类程序,一类是和系统固定在一起,不能卸载的;一类是第三方开发,可以在系统安装后添加和删除的。
在很多嵌入式应用,他们和系统编译在一起,不能动态卸载和安装。所以,我们首先考虑静态的安装和卸载

3.2.1 静态安装和卸载

静态的安装和卸载是发生在开发和编译期。这些情况下,需要考虑它们对编译选项的影响。

我们的系统,可以运行在多进程内部,也可以运行在一个进程内部。所以,在多进程的情况下,每个应用可以单独编译和加载;而在多进程的情况下,则是编译在一起的。

但是,不管是那种情况,我们都采取单独编译,最终合成的办法。这就是说:
如果是多进程的情况,
  1. 系统的基础库(UI库等)以动态库方式编译
  2. 每个应用(包括启动画面等,都是以应用程序的方式提供)都编译成可执行程序
  3. 最后安装时,所有应用及其资源都放在统一的目录下

如果是单进程的情况,
  1. 系统的基础库(UI库等)以静态库的方式编译
  2. 各个应用都编译为静态库
  3. 自动生成静态的应用程序列表
  4.  最后链接为一个统一的程序

以上两种情况,依赖于一个应用描述文件:apps。apps是一个xml的描述文件,使用xml的方法描述上面我们提到的应用程序的信息。

这个apps文件,在静态安装的时候,有很大的作用:
  1. 编译脚本根据该文件,生成一个Makefile,包括了那些应用应该被编译,应该如何被链接。根据是多进程还是单进程的区别,可以生成不同的脚本
  2. 生成一个c或者c++的源代码文件,这个源代码文件,定义一个应用程序列表的数据结构,这个数据结构中,除了包含应用程序的名称信息外,还需要包含其入口函数的地址(仅对单进程有效)
apps文件相当于一个全局的配置文件,在其中添加或者减少app的描述,就能影响到编译脚本,从而在静态情况下,完成对应用的添加和删除。

3.2.2 动态的安装和卸载

动态的安装和卸载,同样也涉及到多进程和单进程。

在多进程的情况下,可以通过安装单独的文件来实现;在单进程的情况下,可以通过动态库的方式来实现;而如果系统支持脚本,则可以通过脚本引擎直接加载的方式来实现。

无论是那种方式,都需要安装和注册的过程,其方法,可以通过一个简单的配置文件来解决:安装时,把信息写入到配置文件中,并保留path数据内容,让系统直接从path处加载对应的代码。

可以设定一个类型,表示应用的接口,如可执行程序,动态库,脚本库等。如,使用类似mimetype的方法定义:
execute/exe|so等 表示所有可执行程序或者是动态库
script/lua 则表示该程序是脚本,用lua解析等

卸载的方法通上。

这两种应用程序在查询时,应该区别对待


3.3 应用程序间的相互调用

应用程序间,存在很多相互的调用,有些应用,是专门以服务的形式存在。

分析应用程序之间的调用,存在有几种:
  1. 一种应用,启动另外的应用,暂时接替自己来运行。如照相程序,拍照后,转入到相册程序中,启动它来浏览拍照的图片等。我们称为父子程序。这种情况下,父程序隐入后台,暂时不在做什么事情,而子程序出现在前台,直到它退出。
  2. 嵌入式应用。很类似windows的OLE程序,子程序和父程序似乎嵌入到其中,没有区别一样。这种比较常见的是音频和视频播放。如在资源管理器中预览视频等。子程序在父程序的一个窗口内运行。父程序可以随时取消或者杀死对应的程序
第一种相互调用,很类似函数的调用,传递参数,然后得到返回值;第二种应用,则很类似一个控件,或者,类似一个COM的调用。

3.4 UI应用和非 UI应用的相互调用

大部分系统,都不会简单的显示界面,而是要和系统做大量的数据传递。通常这种情况下,会以两种方式进行数据传递:
  1. 进程间的数据传递
  2. 线程/任务之间的数据传递

传递的方法,有可以分为:
  1. 同步传递
  2. 异步传递
很多情况下,很多和底层交互的代码都是写好的,有些已经提供了通讯的方法,这种情况下,就需要封装他们的调用方法了。

3.5 文件类型的注册和浏览

很多场合都会涉及到文件的管理,比如,浏览文件,打开一个文件等。这种情况下,需要实现文件类型和应用的关联。

按照windows的做法,以后缀名判断文件的类型即可。

这就需要建立一个文件类型和应用的关联。

也是可以通过静态、动态两种方式来添加的。

每个应用程序可以注册自己可以处理的数据类型。这种类型的描述有 
  1. 应用程序的名字
  2. 应用程序希望的参数格式
  3. 文件的图标,包括多种分辨率
  4. 获取预览的接口
  5. 嵌入式浏览的接口
我们以$f表示的文件的全路径名,如  "-o $f" 等,表示应用程序以这种方式启动

当我们浏览一个文件时,如果应用程序支持即时的预览,如,在预览时,从应用程序获取预览的图片;

如果可以一个文件是可以嵌入浏览的,则,可以直接进行嵌入浏览。比如音频和视频就可以在资源管理器中直接播放。


3.6 统一的风格

统一的风格包括两种:

  1. 界面的元素一致性,比如,所有按钮,其外观和行为都一样
  2. 统一的界面框架,如统一的背景、大小、标题栏等 

但是这不是唯一的。有的时候,也会做一些和统一相背的风格和界面。


3.7 国际化

国际化的支持,是必不可少的。

国际化的支持,主要涉及语言、时间日期格式,货币格式,地址格式等,和国际化相关的内容。

考虑到阿拉伯文等一些从右到左的文本,则需要考虑一些元素的定义,如,文本框默认就要设置为右对齐而不是左对齐。

另外,一些图片,可能带有文字或者国家特色,也是需要更换的。


这些这涉及到资源的管理了。在资源管理中,需要考虑到国际化的支持。


3.8 Timer和Alarm服务

Timer和Alarm是非常重要的服务。比如,显示一个提示框,N秒后自动关闭。或者是增加一个提醒功能等。


Timer服务可能会执行一次,或者多次,需要主动注册,只是当前有效;Alarm则是一旦设置,及时系统退出,也会一直存在。一些设备,如手机,会保存一定的电量,在关机时,也可以启动alarm。


很多GUI库提供了timer服务。但是很多设备也有硬件的Timer。硬件的Timer效果更好些;Alarm也是很多硬件都提供的。


对于我们来说,Alarm的添加、删除以及动作,都是框架需要解决的问题。


3.9 应用程序信息接口

应用程序应该记住上次用户的状态,以便下次进入时,可以恢复用户的状态。或者,用户会做一些设置,需要自动保存。

我们当然可以把这些丢给应用程序自己去保存。但是,这样做,会使得应用的开发和管理比较困难。而且,如果更换用户(比如一些需要多人操作的设备),

这时,让应用自己保存信息,就显得很麻烦了。

所以,需要提供一种配置信息的保存和读取机制,可以自动区分应用程序和当前的用户。应用程序需要做的,就是读写信息到里面。

这和windows的注册表比较类似。对于应用程序来说,全局只有一份。

3.10 自动记忆服务

自动记忆和自动补全功能,在PC上很常见,但是在嵌入式设备中,还不是很多见。这种功能很有用,尤其是嵌入式设设备上,大多数输入不便。

如果能够自动记忆,并放在文本框这种需要输入的界面元素中,自动记忆的功能将很有用。

3.11 复制粘贴服务

这没什么好说的。用的很多。


3.12 统一的输入法管理

输入法也是非常重要的一部分。它的管理,也是全局性的。而且,很多情况下,也需要外部代码的介入。



阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/doon/article/details/6881064
个人分类: UI
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭