移动解决方案快速开发技术

面向小型设计和开发团队的一个渐进实现方法

传统的内容管理系统和文件系统未能满足企业移动用户的数据访问和共享需求。所幸,通过一个利用可重用技术的高效开发流程,即使小的内部设计和开发团队都有希望快速实现一个多设备内容访问解决方案。了解 IBM CIO Lab Mobile Innovation 团队如何快速开发出一个内部解决方案,让用户可以跨其所有支持的平台进行简单、灵活的文件共享,从而提高用户的生产效率。

Tom Cook, 高级技术人员, IBM

Thomas Cook 是 IBM 的一名高级技术人员,负责领导设计和开发团队创建创新的移动解决方案。他在 IBM 的工作涵盖移动解决方案、嵌入式系统、游戏系统、虚拟世界和操作系统。



John Reddin, 软件工程师, IBM

John Reddin 是一名软件工程师,自 2009 年夏天以来就在 IBM 工作。他作为一名 Extreme Blue 实习生加入 IBM,随后在 IBM Connections 工作,目前在 CIO 移动创新实验室。John 在都柏林圣三一学院学习计算机科学。他的主要兴趣在于可扩展软件架构、移动开发和计算音乐(他之前发表过文章的一个领域)。



Emil Varga, 软件工程师, IBM

Emil Varga 自 2008 年以来是 IBM 都柏林的一名软件工程师,之后于 2012 年初加入 CIO Mobile Innovations Lab。他在塞尔维亚的贝尔格莱德大学完成了其计算机科学和工程的学士学位和硕士学位。他喜欢机器学习、Linux、Web 开发和函数式编程语言。



2012 年 6 月 08 日

IBM 的 CIO Lab Mobile Innovation 团队开发了内部解决方案来帮助 IBM 员工更加高效、安全地使用其移动设备。在 2010 年晚些时候,员工们难以跨其笔记本电脑、移动设备和平板电脑共享文件。从移动设备上对典型内容管理系统或共享文件系统的访问受限且比较麻烦。没有插件的辅助,在转移时某些文件不会渲染或运作。而且文件在台式机和移动设备之间不易移植。

我们团队需要提供给员工一个可移植的解决方案,以便通过支持的设备访问 IBM 内部内容。我们决定开发一个试验解决方案来充当访问其全部数据的窗口,并且提供对便携式数据的小缓存。便携式数据会被转化为可兼容的格式,以帮助用户更好地利用各个平台上的内容。我们调用了 MyMobileHub 项目。由于只有一个小团队和几个月的时间,我们需要随着跨 Android、BlackBerry 和 iOS 平台的启动来展示概念证明。几个月之后,我们会需要在本地进行功能试验。

本文中讨论的、我们在试验中使用的很多快速开发概念在移动开发领域是众所周知的。看一下我们如何将它们组合起来,开发一个多设备、端到端的内部解决方案,并且您可以了解可以多快为您的下一个移动试验或项目做同样的事情。

规划一个快速开发试验

创新试验通常是一个迭代过程:快速开发一个可用的解决方案,与一群关系密切的同事和早期采用者共享该解决方案。然后随用户群扩展功能,以评论和建议作为航标。这是探讨新解决方案的一个常用协议。

为在快速发展的移动领域有一个成功的试验,我们需要有一个全然不同的开发方法。我们探讨了大量可帮助我们的可重用技术。我们选择了将开源技术与 IBM 内部工具结合起来,这符合快速开发、跨平台支持和尖端功能等条件。

在服务器端,我们选择了 Play 框架,一个基于 Ruby on Rails 的 Model-View-Controller (MVC) 概念的 RESTful 无状态 Java 框架。对于客户端开发,我们选择了 PhoneGap、Dojo 和 Dojo Mobile,以便在所有客户端有一个一致的观感和用户体验。(参见 参考资料 中的相关链接。)

由于我们计划改变的小缓存文件需要被集中起来,我们决定使用一个简单的数据库,而非一个文件系统。我们选择了 Apache CouchDB,一个无模式的面向文档的 NoSQL 数据库,通过基于 MapReduce 的简单快速的视图支持文档存储。

CouchDB 和 Play 有效协同工作,能够让我们快速实现迁移。我们使用了 Apache ActiveMQ 来管理构成文档转换管道的各种消息和任务。最后,一个 Apache HTTP Server 前端提供给我们一些额外控制和负载平衡。同样地,在此试验中,我们探讨解决方案的可行性,并获取对用户需求和使用模式的理解。当准备好生产时,我们可能希望重用的重要部件、概念和设计被轻松迁移到其他平台。

为了跟上不断扩大的移动设备集的发展趋势,我们利用一个内部工具来帮助我们识别 WURFL 项目的移动设备规范(参见 参考资料 中的链接),这是一个智能手机功能和屏幕大小等信息随手可得的存储库。该工具帮助我们轻松确认如何最好地显示应用程序内容,以符合设备的功能。

我们从试验中获得的价值不仅仅是总体内部产品(代码)本身,还有对人们如何使用我们的试验品的理解。更重要的是,我们获得了为移动用户和技术娴熟的用户解决问题的经验。我们的早期采用者并不避讳告诉我们是否解决了某个特定的问题,匹配了其工作流,或满足了他们对易用性和生产效率的期望。如果我们没有履行我们的使命、让用户更高效和安全,我们就重新创建解决方案来从一个全新角度解决问题。


MyMobileHub 概要

我们的解决方案提供一种简单的方式来让用户共享文件。与其通过电子邮件发送给自身他们想在移动设备上打开的文件,他们可以使用 MyMobileHub 将文件从其桌面拖放到浏览器。我们通过浏览器将文件上传到我们的服务器上。用户可以从一个移动设备连接到同一台服务器,但是我们提供给他们不同的 UI,其中他们可以查看文件,不管其原始格式如何。我们还利用移动摄像机和语音功能来让用户轻松创建和上传多媒体内容。

笔记本和台式电脑视图

对于笔记本和台式电脑,我们仅支持具有拖放功能的浏览器。用户将书签、文档或其他文件拖到浏览器窗口,如图 1 所示。对于我们可以理解其格式的文档,我们提供预览并创建可在移动设备上轻松使用的 PDF 版本。我们计划转换其他文件类型,比如将音频文件转换为文本文件。

图 1. MyMobileHub 特性
MyMobileHub 屏幕截图

桌面浏览器提供一种上传和组织文件的便捷方式。为每个文件自动生成一幅预览图像。用户可以选择一个列表视图或网格视图来直观地管理其文件。动态的颜色编码标签有助于他们组织其文件,而不会有典型的文件系统层次结构带来的不便。文件和标签过滤器以及一个即时搜索特性便于快速便捷地找到文件。

移动 Web 应用程序

智能手机和平板电脑上的浏览器相当先进。使用 Dojo Mobile 和 JavaScript,可以通过浏览器提供一个丰富的应用程序。内部设备识别服务检查设备类型并帮助我们选择要下载到设备的适当可重用代码、HTML 和 CSS。取决于设备功能,我们提供显示效果最好的页面。在 iPad 等设备上,Web 应用程序页面非常类似于桌面浏览器的 Web 应用程序页面,因而提供一个无缝的用户体验。可以从图 2 中看出,用户体验中应用程序因素多于 Web 页面因素。用户可以请求下载文件,请求下载 PDF 版本以供查看和插入到书柜,或者创建一个到 Web 页面的书签。

图 2. MyMobileHub 移动 Web 应用程序
MyMobileHub 移动 Web 应用程序屏幕截图

移动本地应用程序

本地 MyMobileHub 应用程序看起来类似于在移动浏览器中运行的 Web 应用程序,不过多了一个功能,即可以上传从设备本身生成的内容。用户可以记录音频或视频、拍照、或从其图库选择一张图片。所有内容都可以直接从 MyMobileHub 上传。

图 3. MyMobileHub 本地应用程序
MyMobileHub 本地应用程序的三个屏幕截图

效率始于:方法论、方法和设计

在进行任何编码工作之前,我们研究了各种技术。工具选择是一个谨慎的过程,是我们步入正确道路的一个起点。我们将用户体验和用户界面设计师集中起来。我们将开发人员聚集起来(两者都有)。我们邀请了 Web 开发专家(住在巴西)。每一组都负责培训其他人有关各个工具集的效率的知识,比如图形设计、HTML5、CSS、UI 小部件和服务器功能。通过相互之间的交叉培训,我们共享了痛点和效率技巧。

我们还做了一些重要决定,不支持某些操作系统级别和浏览器级别。通过专注于提供支持 HTML5 的浏览器,我们能够简化我们的开发流程。识别相关的技术趋势、预测软硬件方面的增长,这是卓有成效的。例如,在我们决定专注于支持 HTML5 的浏览器之后的三个月左右,所有移动设备都支持了 HTML5。

单数据/多 CSS

我们在移动应用方面做出的首批重大设计决策之一是,尽可能多地将 UI 和格式化项目推送到 CSS 和 HTML5。这么做之后,我们不仅简化了代码,而且跨所有移动平台统一了代码。

我们需要支持 iPhone、iPod Touch、iPad、BlackBerry、Android 手机、Android 中等和标准尺寸平板电脑,以及 Mac、Linux 和 Windows 桌面。跨每个平台的每一行自定义代码都增加了可靠性暴露和复杂性。我们的单数据/多 CSS 模型能够让我们使用相同的 JavaScript Object Notation (JSON) 数据源来为这些平台创建完全不同的 UI,对于每个平台只有一小部分自定义 CSS。

为此,我们为每个平台编写了自定义 CSS 模块。以我们的 Web 应用程序为例,当一个设备从我们的服务器请求 HTML 时,我们检测它是什么类型的设备,然后动态地加载适当的自定义 CSS 模块。对于本地应用程序,我们已经知道可以加载应用程序的平台类型,因此我们可以将自定义项进一步限制到屏幕大小和 OS 版本等。相关的一个示例是在 iPhone 和 iPad 应用程序中,两者共享大约 99.9% 的相同代码,但是(归功于动态 CSS 的强大功能)它们有针对屏幕大小的适当观感。

清单 1 显示 iPhone 和 iPad 的 CSS 模块:

清单 1. iPhone 和 iPad 的 CSS 模块
.loginScreen {
    background-image: url(../images/splashBG.png);
    background-repeat: no-repeat;
    background-size: 320px;
}

.loginScreeniPad {
    background-image: url(../images/splashBGiPad.png);
    background-repeat: no-repeat;
    background-size: 768px;
}

使用 PhoneGap 让效率更上一层楼

我们的扩展团队包括开发人员,他们精通针对大多数移动平台开发自定义应用程序。一般来说,我们可能会请每个移动平台专家参与开发一个自定义应用程序。但是由于时限较短且我们构想的 UI 相对简单,我们采用了一种不同的方法。通过努力推送尽可能多的 Web 应用程序函数到 HTML5 和 CSS,我们能够使用 PhoneGap 将 HTML5 和 CSS 包装到本地应用程序中。

PhoneGap 等工具在概念上很简单。您可以从一个使用 JavaScript、HTML 和 CSS 技术编写的移动 Web 应用程序入手。然后 PhoneGap 将其打包为一个本地应用程序,其主要任务是启动一个内部浏览器来仅查看该 Web 应用程序(一个 WebView)。本地 API(比如设备的摄像机)现在可以通过 JavaScript 调用加以访问,该调用将 Web 应用程序链接到本地代码。用于访问摄像机的 JavaScript 代码在每个设备上都是一样的,强化了将单一代码库用于多个平台的目标。清单 2 中的代码段显示如何只使用一个简单的 JavaScript 函数在设备上捕获一幅图像:

清单 2. 使用一个简单的 JavaScript 函数捕获图像
mmh.phonegapActions.captureImage = function() {
    navigator.device.capture.captureImage(
		dojo.partial(mmh.phonegapActions._captureSuccess, "image"), 
            mmh.phonegapActions._captureError, {limit: 1});
};

使用一个像 PhoneGap 这样的工具有某些缺点。它当然不像使用本地代码编写的应用程序那么高效和运行快速。一些繁重的执行任务,比如复杂的图形动画,仍然会需要本地执行具有响应能力。调试和测试工具仍然处于萌芽阶段,不过这一情况随着 Ripple 和 WEINRE 等工具的出现而有所改善(参见 参考资料)。使用现成的本地应用程序,您不会对硬件层得到原本那么多的控制。(您可以通过编写自定义 PhoneGap 插件来克服这一缺点。许多插件可用于特定任务。)但是,对于我们的情况,大量重用的好处大于 PhoneGap 的缺点。

使用 PhoneGap 的另一个注意事项是,应用程序的设计应当以本地应用为中心。对于不同移动平台的了解有助于应用程序开发人员无需编写本地代码即会有本地应用的感觉。在我们当前的创新周期中,我们将设计好的 Web 应用程序迁移到本地应用程序的速度已经足够了。使用 PhoneGap,我们可以在两天内将 Android Web 应用程序转化为本地应用程序,支持音频/视频/图像记录、本地通知窗口和硬件菜单/返回/首页按钮。我们还能够为 BlackBerry 重用该代码。

高效级联变更

有时即使您与用户体验设计师和 UI 设计师一同出色地完成了一项工作,设计出了自认为最好的 UI,您的用户也会抱怨他们不明白如何执行一个简单的任务。(您怎会疏忽呢?)

因此您想出一个可以简化用户体验的变更,现在需要将这一变更级联到所有 Web 应用程序和本地应用程序。没有跨平台的高水平重用,您的开发人员必须到每个平台上多次进行变更。将这个乘以您必须重新运行的测试用例的数量,小的变更就转化为巨大的变更。同样地,依赖于 HTML5 和 CSS 格式化,您可以在较低级别做出大部分变更。使用单数据/多 CSS 模型的编码变更具有更小破坏性(影响)。测试了 Web 应用程序之后,您可以将变更传递到 PhoneGap 本地应用程序解决方案中,然后就完成了。

我们遇到的一个示例是,包含一个 Refresh 按钮来保证用户可以重新扫描他们认为不同步的数据。我们在 Android 上开发并测试了这一功能,然后在所有平台上高度自信地重用了相同的代码。小的 CSS 调整帮助获得跨设备的适当观感,这个功能就完成了。

使用这一重用方法,我们预计在最初 90% 的功能开发之后,需要大约 10% 的开发时间才能让一个新功能在所有平台上工作。不过,显然如果需要使用不同的 API、语言和框架为每个本地平台重新编写相同的功能,情况就不会是这样。

这一重用方法还应用于 bug 修复。如果在 iPhone Web 应用程序的 UI 中找到了 bug,很可能在 iPad、Android 和 BlackBerry 的应用程序中也存在相同的 bug,因为它们有 99% 的代码是相同的。修复了一个平台上的 bug,我们就修复了所有 Web 应用程序。此外,可以很容易地在本地版本上找到 bug 源。

对于所有图形,我们还有一组子图,但是对于一些 CSS 和 Dojo Mobile,无需额外工作我们就可以为设备提供适当的外观。

并非一个完美的流程

我们在继续开发和简化我们的流程,以便可以在所有平台上以较少的自定义获得更好的支持。一个相关的示例就是跨设备的本地导航。iOS 设备不包含硬件的 Back 或 Menu 按钮,而 BlackBerry 和 Android 设备(至少为 Android 4.0)有该按钮。另外,Android 和 BlackBerry 菜单按钮以不同的方式工作。为了克服这一差异,我们将 JavaScript 代码分离成小部件,可以在不中断或少中断其余代码的情况下插入或修改该代码来适应每个平台。重要的是,不仅要将代码与 CSS 分离开来,而且要模块化组件,以便可以轻松重用或替换代码。

通过遵循我们的单数据/多 CSS 策略,我们成功地最大限度减少了特例编码的数量。

Web 应用程序与本地应用程序

部署哪个更好,Web 应用程序还是本地应用程序?根据我们在 CIO Lab Mobile Innovation 领域的经验,答案是:两者都好。得益于智能手机和平板电脑的浏览器的最新改进,移动设备上的 Web 应用程序运行良好。本地应用程序目前确实提供对本地硬件功能的更多访问。

但是,决策不仅仅关乎哪个更好。我们发现试用我们的解决方案的用户在是否安装本地应用程序上犹豫不决。有一些只是没有准备好寄托于我们的解决方案。在安装本地应用程序之前他们想要对其进行试用。而且本地应用程序确实需要一些维护和更新。

通过同时支持 Web 应用程序和本地应用程序,我们可以为我们的创新维护一个零安装策略。而且用户循环使用的设备比我们想象的要多。当他们获得一个新设备时,在安装本地应用程序之前他们首先使用我们的 Web 应用程序对设备进行试用。功能、设计和部署时间之间总是需要有一个权衡。


结束语

使用我们描述的模型试用一个解决方案有助于像我们这样的团队探索其构想的核心价值。整个过程始于对可用于解决问题的最佳工具(开源和内部)进行深思熟虑的研究。然后您可以分析功能和设计之间的权衡。有时理解上市速度与功能完整性的价值可能是实现一次成功的试用所需要的。在通过用户反馈和采用突显出核心价值之后,将试验品转化为生产服务或产品的过程就可以开始了。

我们希望本文提供给您一些有助于您的下一个项目的技术,这将有助于您的团队(以及您的解决方案的用户)更加高效、更具有生产效率。我们的试验涉及到来自用户的大量需求变更,不过我们坚信我们的小团队能够跟上用户的变更请求。我们精简了设计并且开发了一个几周循环一次的流程,这都归功于我们一开始选择的高效方法论。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=移动开发
ArticleID=820320
ArticleTitle=移动解决方案快速开发技术
publish-date=06082012