关于移动开发的一些讨论(在有些场合,移动就是噱头,胡乱鼓吹是不负责任的)

一些是和公司一个同事关于移动的认识上的一些邮件讨论。一堆话的方式

L:

经过长期跟进和信息收集,我在windows移动端有了一些建议思路,希望公司让我来启动这方面的研发。公司里面对于windows研发你是最资深的,所以我们俩先交换一下意见,请从技术角度和微软发展、业界发展的角度看一下这个思路可行吗?谢谢!详细情况,请见附件。

(附件:移动开发建议书)

1.目标及产物

采用Windows本地化程序开发(基于.Net技术、windowsPhone技术)实现一套客户端框架,以承载未来的移动ERP、移动OA、移动HR等一系列具备鲜明特色的企业应用。

只是实现一套客户端框架,后台服务方式与目前不变,保持相同。比如,可以在平板上制单,可以填入库库,可以制凭证。等等。

2.背景及原理

未来是移动的未来,但是没有后台系统的依拖就移动不起来。我们现在基本掌握了后台系统框架。我们有ESP、SmartWEB、Cloud技术为后台提供丰富而强大的支撑。现在,至少在技术层面,我们可以把目光转到设备端。

目前,在设备端一片汪洋,无所适从。企业应用如何移动起来,没有定论,也没有人实践。IOS、Andriod、Windows三者究竟何从何从?未来的应用形式将是什么样子?

未来,设备+云的形式板上钉钉。设备可以是PC,可以是平板电脑,可以是手机,也可以是任何一种智能设备,如智能手表,智能家居等等。形式太多,我们只谈企业应用。

企业应用中,苹果已经与IBM合作,试图在企业端让他移动起来,但两家大哥大的合作效果如何?我估计效果是乐观的,会催生出这个市场,让用户接受。相信Ibm 要做的是真正的企业应用,而不是现在的移动审批这种简单事情。

微软将在未来两年内统一手机、平板、电脑的操作体验,至少会在开发层面上,统一把三套系统的API为一套。在未来,甚至在眼下,windowsPhone的开发与Windows桌面程序的开发已经几乎一致。所以,在微软的世界里,可以不太分桌面程序和移动程序。而真正的企业应用,会在“平板电脑”这类设备上发力。

处理能力和功耗随着Intel新型移动芯片的发布,微软基于windows的设备会越做越轻薄,越做待机时间越长,完全可以满足一整天的工作。而这些基于Intel芯片 的设备,会有一半是完整的pc架构的设备。完整pc架构意味着什么?可以跑win8,可以运行如此多的应用程序,以前在pc上能做的事,现在,在平板上都可以做了。

所以,到底企业移动在何时爆发,我认为得看芯片商的努力和OS厂商的努力。面向未来两年的发展来看,Intel处理能力和功耗的解决是必然的。

我跟踪这类应用两年有余,我相信,微软终会在企业移动应用有所建树。这是它的基因和技术壁垒所决定的。 就算苹果+Ibm取得了成功,但不可能一枝独大,况且业界也有一半的声音认为IOS的基因和封闭也不适合承载企业应用。

微软目前看上去有点问题,但正因为是这样,才需要切入取得时间上的优势。

3 . 推进及落地

l  所需要的人员:

.Net程序员两名(C#语言),这种人才要比IOS开发的人好找多了。现在我认为.net在移动端有机会,在服务端肯定是没机会(被java全部占领了)。

l  所需要的设备:

Windows 平板电脑。

l  所需要的开发环境:

widnows8 + .Net开发环境。现在我们配的笔记本就可以。

l  如何落地:

前面说过,在微软的平台里,将来都不怎么分移动和桌面。移动应用会涉及到UI、通信、硬件接口(如各类USB定制设备)。

提到USB定制设备,我认为这是windows平板的绝对优势。平板不是光用于审批单子的,它可以拿着随便走动,在码头、厂房、仓库、机场、超市、油区等等几乎全部的环境。而在这些环境中,我希望我们运行在平板里的windows程序,可以通过各类usb定制设备去感知、采集、输入这些场景需要的数字信息。这个,必须有一个USB接口。如何用好平板,必须从硬件上多考虑,单纯的软件还是在电脑里转悠,是不行的。

另外,还可以保证开发一套这种客户端,可以同时适应公司目前的多种后台架构。统一设备端与后台服务的调用规范我提过多次,是可以实现的。

4 . 总结

公司未来几年会面临发展和变化,有机遇有挑战。作为股东,我非常希望公司有新的亮点出现,有新的产品出现。时间不等人,我们需要与时间赛跑,要避免不合理的决策造成时间上的错失,一定要在合适的时间,让合适的人去做合适的事。本文所说的Windows的这个领域的开发在公司目前尚是个零。但我已经跟踪了两年,除非微软windows系统在移动端就此死掉,否则一定会成功。

----------------------------

ME:你好!

1,  我不是很赞同将来移动会有很大作为这个观点,就我们服务的客户来讲,移动应用场景还是比较少。做了也只能起到宣传的效果。

2,  微软在移动端会有很大的前景,这个可以有。

放下上面的两点意见不说,提几点意见,共探讨。

1,  是采用本地话还是网页开发

我倾向于网页开发。理由有2:一是网页可以兼容所有移动端设备。二是,随着网页技术的发展,网页设计的难度越来越少,展现方式和效果也越来越绚丽和丰富。三,如果做本地话的话,不同的平台需要不同的技术和人员,对普联来讲是个浪费,尤其是在目前人力比较紧张的情况下。

纯网页开发的问题,1是平台兼容性和浏览器兼容性,2是访问本地资源的安全性问题,比如访问本地设备,文件等等。兼容性就是个工作量,而访问本地设备,可能需要开发不同平台的插件。这个需要比较处理这些问题的成本与目标移动设备本地化开发投入的成本大小。如果前者的成本大于后者,那就考虑本地化开发。

一个折衷的方案是开发一个壳子,对内嵌入网页,对外访问本地资源。

2,本地化客户端框架开发。如果使用本地化开发,“实现客户端框架”,很有必要。但不建议做界面设计器,只做结构方面的框架,提供开发模式和标准、界面和非界面组件就ok了。界面设计器我们没有这个功力,做得不好,会大大影响开发效率。

我对移动开发这块没有过多了解,仅供参考,所以以上意见也许对你没有很大的帮助;再者,在公司总体技术路线上,你比我有全局观。其实公司不是做什么的问题,而是怎么做的问题。

===============================

L:为什么看法相差这么大呢,难道是我太乐观了吗? 我觉得以下几点值得考虑:

1、  如果有一个移动的pc,比如surface pro这样的设备作支撑的话,真正移动应用可以开展,不仅是审批类,多种场 景都可以用,这将是一个与现在不同的世界。

2、  在平板上、手机上,我认为原生的应用体验更好。而且我的想法是必须要在设备端控制各类外接设备,实现一些底层功能,这些是web所不能办到的。释放设备的能量,需要本地化程序。Web的方式作着忽悠一下可以,作为战略性发展的话,应该以原生为主。

3、  虽然面临多个平台,但我非常关注的是windows平台,ios或andriod可能承载不了这种重任。

4、  肯定不会做设计器,客户端只负责展示定义好的组件级的封装。我反对esp那种什么都是设计器的作法,效果适得其反。不给程序员留有空间,应用如何做好?

5、关于人力,我说的2个人确实也是可以的,后台都有了,中间层的数据交换都有了,我们只是把smartWeb的实现换成了.net本机实现,用js都可以实现的,用.net肯定都能实现,而且要加上读取硬件设备的一层功能。架构不会重新设计,服务不会重新开发。这在当初设计smartWeb总体框架的时候就想好了。

我感觉到企业移动应用就要到来,这不是简单的审批一个单子这种,而是各种各样的场景。很多都需要Surface  pro外接 usb定制设备才能实现。业界能出现Interl架构的Surfacpro是一个福音,希望更多的厂商能够跟进,推出interl+windows的平板。很多人谈移动必ipad,andriod,我看到的不是它们,而是windows。

希望能够互相继续探讨。

=============================

ME:有点忙,回复一句。

1,如果你认为surface是移动设备的话,这个设备除了稍微便携一点之外,和pc有什么区别?Microsoft对surface的定义就是一个超极本,偶尔可以用作平板。在surface上开发系统,和在pc上没有任何差异,何来移动开发之说呢。

2,如果考虑更便携(屏幕更小)的windows设备,谁会用它来录单子,做更复杂的交互呢,还是个消费平台,而不是生产力平台?

我一直认为在生产领域,移动应用更多的是噱头,就像目前中原给客户开发的移动会议系统而言,每个与会者抱着ipad看文件,投票,这不是奇葩吗?而消费领域则不同,受众不不同,需求不同,没有可比性。

3,设计器不做很明智,和微软的ide来比,任何公司的所谓ide都是渣。

个人意见,共探讨。

========================

ME:你好!

系统上线,第三天,终于稳定下来,继续。

1,  其实,移动应用有没有前景,具体讲普联在移动领域能有什么作为,关键是看我们服务的客户,我们的项目有没有这个需求。这个简单,你可以把公司所有的产品,项目,客户过一遍,看看我们做的系统的性质,就能得出结论。我的了解,我们服务的客户,企业客户,开发的系统也是企业信息化管理系统,而且还都是经营管理类,而没有延伸到生产一线。这类系统的目标群体就是办公室一族,办公地点一层不变,他们几乎没有移动办公的需要(顶多在办公室处理不完的事务,回家加班处理,比如做凭证),他们的工作内容也很单一,都是重复的事务性工作。这种事务性的工作,需要的是大屏幕,快捷的录入,高效的人机交互;更高一层,可能就是领导层了,他们关心的是报表,图形,业务审批,只有他们才有一点移动的需求,领导忙嘛,经常在外边,有摆酷的需要。这也是我们正在做的。如果仅仅是这个话,目标群体就少很多,也没有多花的需求。

不过我们现在做的公共服务收费的这个项目将来可能有移动的需求:手机缴费。但是这个已经很成熟了,而且也不是我们的主业。

2,  你可以说,用户没有需求,我们引导他们。企业的信息化的过程,我理解是,战略咨询与规划—产生业务需求—技术开发,这是从上到下一个链条,我们的位置初一业务需求下端和技术开发,最多覆盖一个半的过程。我们做的每个以系统,几乎每一个都是客户提出的需求,从技术环境,开发语言,按钮的位置,菜单的命名等等。我们缺的是第一步,战略咨询与规划,也就是需求的源头,你怎么往移动上引他们,怎么能用技术的东西撬动上游的需求呢。

一句话,在我们的业务领域中,我想不出移动开发有什么作为,当然也可能是我们想到,么有经历到。在公司做个内部调查是个好方法。

其实普联可以做的地方很多,除了这个。

一家之言,仅供参考。

==========================

L:谢谢百忙之中给予的思考!

正如你说,移动这个事,目前我们做的基本就是一种点缀,引领的代价又太大。所以从这个角度来看,确实没什么值得去做的。

但冥冥之中,我感觉真正移动商务时代就要来临,而这个时代很可能要以平板应用为主,其实也正是微软的奋斗目标。所以,我只提到微软的平板与期解决方案,但并不是急于去做,也是观望。

微软给出的是介于平板-桌面的解决方案,或者说是能够移动的桌面系统。我觉得这是未来的一个重要方向。

由于我们公司做的都是企业管理信息系统,基本是给坐在办公室的机关的人用的。从这一点上看,移动总归就是一种点缀,顶多是移动审批,这个观点,两年前我也是这样表达的,也给X总说过,他还老大不高兴。现在我也这样认为,MIS这类系统并非是移动的必需。

我们能否跳出我们服务的客户来考虑,比如供应链系统、ERP系统,我们能否敢于喊出“移动ERP”或”移动XXX”的目标呢? 有没有新的领域我们可以去做? 比如:

1:比如移动HR,里面的招聘面 试功能,这样,我们的专家们不必跑现场,而是由HR的小秘去现场就行了,就可以远程通过视频来面试。

2:移动供应链,我觉得这是离我们最近的一个业务了。收、发、运输,移动起来会更爽。

 就我个人感觉而言,其实是在等待微软在这个领域有所作为,如果微软做不好,可能别人也做不好。我还是非常看重微软的能力。

关于移动开发的一些讨论(在有些场合,移动就是噱头,胡乱鼓吹是不负责任的)

时间: 2024-11-08 09:03:12

关于移动开发的一些讨论(在有些场合,移动就是噱头,胡乱鼓吹是不负责任的)的相关文章

即时通讯软件开发 几种网络编程方式

即时通讯软件开发 几种网络编程方式: ISAPI.CGI.WinInet.Winsock 它们之间的区别: 1)ISAPI主要是开发基于浏览器客户端与服务器端程序.效率比CGI方式高,而且也扩展了CGI没有的一些功能.(基于TCP/IP模型中的应用层) 2) CGI主要是开发基于浏览器客户端与服务器端程序.(基于TCP/IP模型中的应用层) 3) WinInet主要是开发客户端程序.(基于TCP/IP模型中的应用层) 4) Winsock主要是基于socket来开发客户端与服务器端程序.(基于T

主机管理+堡垒机系统开发

本节内容 需求讨论 构架设计 表结构设计 程序开发 1.需求讨论 实现对用户的权限管理,能访问哪些机器,在被访问的机器上有哪些权限 实现可以通过web页面对指定主机列表 进行 批量发布命令.文件 实现对用户操作进行纪录 2.架构设计 3. 表结构设计 参考 http://www.cnblogs.com/alex3714/articles/5286889.html 前景介绍 到目前为止,很多公司对堡垒机依然不太感冒,其实是没有充分认识到堡垒机在IT管理中的重要作用的,很多人觉得,堡垒机就是跳板机,

《阿里巴巴Java开发手册(正式版》读记

前几天,阿里巴巴发布了<阿里巴巴Java开发手册(正式版>,第一时间下载阅读了一番. 不同于一般大厂内部的代码规范,阿里巴巴的这本Java开发手册,可谓包罗万象,几乎日常Java开发中方方面面都有所涉及. 在知乎上,也有关于这本开发手册的讨论十分热烈的帖子. 由于里面涉及的内容比较多,下面重点罗列下一些我读过之后十分赞同与持保留意见的条目: (一)编码规范 (一)命名规约 8. [强制]POJO 类中布尔类型的变量,都不要加 is,否则部分框架解析会引起序列化错误. 反例:定义为基本数据类型b

移动端开发流程分享

1.由于产品及UI能力限制,不能达到理想状态,从以往项目开发中总结发现,在开发及测试周期中发现需求缺陷问题,需要花费大量的沟通成本,导致项目周期有所影响并严重影响开发效率和开发质量,解决方案:再产品需求.原型设计及UI阶段,开发需要严格把控质量,帮助产品提升交付件的质量 2.由于接口开发人员未讨论确定接口具体细节,接口需求方和接口开发者只通过文档修改,接口开发不按照规范执行,随意性太大,不能保证开发质量按时交付,导致接口需求方工期受到严重影响,从而移动端交付件质量得不到保证.为了解决接口问题:制

SeaJS基本开发原则

SeaJS基本开发原则在讨论SeaJS的具体使用前,先介绍一下SeaJS的模块化理念和开发原则.使用SeaJS开发JavaScript的基本原则就是:一切皆为模块.引入SeaJS后,编写JavaScript代码就变成了编写一个又一个模块,SeaJS中模块的概念有点类似于面向对象中的类--模块可以拥有数据和方法,数据和方法可以定义为公共或私有,公共数据和方法可以供别的模块调用.另外,每个模块应该都定义在一个单独js文件中,即一个对应一个模块.下面介绍模块的编写和调用.模块的定义及编写模块定义函数d

BugPhobia开发篇章:Beta阶段第VI次Scrum Meeting

0x01 :Scrum Meeting基本摘要 Beta阶段第六次Scrum Meeting 敏捷开发起始时间 2015/12/18 00:00 A.M. 敏捷开发终止时间 2015/12/18 23:00 P.M. 会议基本内容摘要 ü  在第六次Scrum Meeting的开发阶段,BugPhobia团队首次开始前端和后端的对接工作,此部分工作将影响后续工作的安排和进度:而同时,Dream团队依据此前的协商已经将部分的数据插入Solr,团队尚未此做出验证,但若依据正常的周末的工作量,本周的工

柯南君 教你看敏捷开发のScrum是如何工作的?

现在敏捷开发是越来越火,人人都在谈敏捷,人人都在学习Scrum和XP,柯南君的朋友"远哥"是一位项目leader,柯南君与远哥促膝长谈,远哥也毫不避讳,知无不言言无不尽,把自己对Scrum的理解和自己工作中的经验积累与柯南君分享,在这里柯南君代替远哥与大家分享一些经验. 一. 什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方法. 怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用

(转)web开发流程

a.项目经理与公司决策层的沟通,以确定这个需求有没有足够的人手和可行性去实现,以及与现有产品的依存关系. b.公司决策层与市场/策划部门的交流,这个过程将进行的相当充分,并且是反复.长期的,它致力于从用户的角度对需求进行细化和分解. c.市场部门需要针对细节问题与项目经理交流,以确定这个需求有没有可行性去实现. d,e,j.这是整个产品的架构设计过程,分为ui架构设计和程序架构设计两部分.首先架构师需要与项目经理达成思想上的一致,随后进行设计.这个设 计必须是便于分工.维护和扩展的,而且要能够承

Web开发必知的八种隔离级别

ACID性质是数据库理论中的奠基石,它定义了一个理论上可靠数据库所必须具备的四个性质:原子性,一致性,隔离性和持久性.虽然这四个性质都很重要,但是隔离性最为灵活.大部分数据库都提供了一些可供选择的隔离级别,且现在许多库都增加了附加层来创建颗粒度更细的隔离.隔离级别应用范围如此之广主要是因为放宽隔离约束往往会使得可扩展性和性能提高几个数量级. 串行一致性是可用的最古老最高的隔离级别之一,它之所以倍受青睐是因为其提供的简单编程模型,即每次仅能有一个事务对给定的资源进行操作,这就避免了很多潜在的资源问