移动应用开发的终极武器

不,我并没有在讲HTML5,也不是讲PhoneGap这类号称跨平台的FrameWork。我讲的是我的一些iDea和YC的一个即将发布的产品Parse。

我在做iOS应用的时候,前至手机端的一个像素,后至服务端的某条推送服务的守护进程,我统统都结结实实地打过交道。作为一个自命有追求的研发工作者,我总结出,在ios应用开发的很多个环节可以抽象出来进行重用,并且再进一步包装的话,可以做成面向开发者的第三方服务,如下面我提出的三个:

推送服务

在服务器端搭建和维护一个稳定靠谱的推送服务不简单。当我完成了我的产品的推送服务时,我马上就想到可以做一个叫“代客推送”的生意。但是有更聪明的人想到了,并把生意做了。

应用内聊天(in-app chat)

现在好像不管什么应用,都指望给自己的应用加上一个能让用户点对点的发消息功能,有消息功能后,又想要及时一点的聊天。嗯,这又是一个可以做的生意呀。如果有一个服务给你提供一份SDK,可以三行代码实现用户应用内实时聊天,外带推送,200个使用用户内免费,你会考虑吗?

用户及关系中心(SocialCenter)

这样说吧,你有一个应用A,允许用户绑定微博,twitter,facebook的帐号。然后有下面的场景:

  1. 用户在一台终端绑定三种帐号。
  2. 用户在另一台终端再次登录,无需重新绑定即可直接访问三种帐号的资源。

好了,作为开发者的你,又开发了应用B,与应用A一样有着上面一样的需求,你可以把应用A里实现的那套代码(包括前端和服务器)照抄一遍,也可以继续思考:

  1. 针对于绑定用户这个功能而言,应用A和应用B的服务端Host为同一个,会怎样呢?那就只需要维护一套代码咯,但这还不是全部。
  2. 对于用户来讲,更神奇的事情发生了,我在A应用绑定过三个帐号后,在B应用使用微博帐号登录,居然那三个帐号的绑定在B应用里也生效了,这说明什么?用户在所有的应用里有可能不断重复绑定社交网络的动作,其实可以简化为绑定一次!

其他的就不多讲了,它是一个类似about.me和gameCenter结合的东西,我认为基于它之上可以挖掘的东西太多了。

歇一歇

以上三个东西是我一直嚷着要做的第三方服务,原先我的想法是继续多做几个应用,经过几个应用的沉淀,它们自然就会作为副产品沉淀出来。其实这三个想法都有一个一致的理念:为开发者提供更方便的基础服务,降低开发成本(虽然第三个看起来理想更远大)。我深信这个方向是可以产生价值的。一直到今天,我看到了YC的一个未发布的产品Parse,我更加坚定了我的想法。

Parse

Parse是一个完整的 iOS,android 后端支持平台,它可以让开发者完成忘掉服务器端的事情(parse透明地为你提供服务端的支持),全情投入在客户端的开发上面。还有人把它类比成手机开发中的Rails。上面我提到的三点想法里面,Parse提供了其中两点:

  1. 推送服务
  2. 用户、社交网络连接(含twitter,facebook)

此外,Parse还提供了本地数据与服务端数据同步的服务,开发者只需要对本地的数据进行操作就行,多舒服啊。

有这样好的SDK和服务提供给你时,做一个iOS或andoird应用变得更加容易了。如今这样的第三方SDK和服务越来越多,原来在Web2.0里面出现的第三方服务,如评论,用户反馈托管(如userVoice),表单等己经开始全面移植到移动互联网的世界。可以想像,未来的移动应用也可以简单的MashUp出来。

现在你知道为什么我说的终极武器并不是哪一门子的技术了,丰富而强大的基础服务才是。

关于我的idea们

在没有成熟的类似的第三方服务出来之前,我会选择在以后的应用里面(包括“一起”)继续打磨这些基础套件,如果打磨得好用,我再考虑作为独立产品发布出来。如果有朋友现在就感兴趣和有时间,那请你们赶紧做吧,我一定会成为你的客户。

This entry was posted in 技术 and tagged , , . Bookmark the permalink.

9 Responses to 移动应用开发的终极武器

  1. davidx says:

    哪里有需求, 哪里就有市场

  2. Zoom.Quiet says:

    是也乎,是也乎,标准的面向程序猿的生意经,摧悲在:
    - AppStore 自个儿也可以提供这种平台服务时,这类服务有活路嘛?!
    – 当然,可以参照:沈思:木瓜移动将成为手机上的Facebook
    http://www.donews.com/original/201108/582456.shtm
    – 此处不留爷,自有爷去处
    – 只是,不折腾嘛?
    - 面向应用的服务,本身,也是很容易复制的:
    – 有 PaaS 等一堆更加基础的服务了
    – 看准一个应用的方便点,就可以扩展成一个服务
    – 那么,同类服务一多,又开始拼同样无趣的东西了,,,
    - 再者,这种云服务化的平台
    – 各种应用的切面在其中跑时,必然的产生各种衍生数据,和有价值的趋势分析
    – 以及本身数据安全性,,,
    所谓, Mashup 源的安全性和不作恶,怎么限製?

    总之,这事儿,在相对自由的国外互联网,很可以折腾一下,在中国,维稳至上的情况下,公安随时调查你的数据和关闭指定应用流时,,,谁敢用?

    好吧,俺是悲观至死派,,,

    • jeff says:

      哈哈哈,ZQ大妈想多了,但说的都很在理啊。
      - 我其实是服务开发者多了,组件的抽象和重用成了本能,可以提高效率的事情,本身就值得做!
      - 只恨身在天朝?所以,落地的时候肯定是有折扣的,例如可以提供一些与核心数据关系不大,但实现起来还挺费劲的服务(推送服务、应用内聊天其实都很值得做)。我也认为在中国不可能实现数据的第三方托管。

      • Zoom.Quiet says:

        当然的了,这是必须的,对工作效能的无谋求,这是程序猿的宿命哪!而且,这类基础服务,除API 之外,可以使用自个儿喜欢的各种语言实际,不一定非要死磕 Objec-C 很有趣的领域,,,
        jeff 有意的话,可以主持一个小的开源项目,推进哪,,,
        俺就很有兴趣掺合,,,

  3. adam.lu says:

    希望jeff写些关于推送要用到的技术和实现思路。

  4. www.chaojishop.com says:

    来顶博主了。

  5. 博主你的网站做的不错哦,知更鸟的这个主题我也用过,挺不错的。最近闲来无事,我写了一篇小说–打篮球的女孩。在起点上,有时间了帮我顶一下哦!!!!

  6. nunyaa.com says:

    偶然跑到这里,觉得博主文章挺值得读读的,收藏一下

  7. yobune.com says:

    写得真不错,小MM很喜欢哦,随便说一下留言是一种美德,你是知道的!多谢支持!

发布评论

您的电子邮箱不会被公开。 标记为 * 的区域必须填写

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>