StoveFireiOSMenu, 炉火餐饮系统 iPad 点餐端

分享于 

8分钟阅读

GitHub

  繁體
炉火餐饮系统之iPad点餐
  • 源代码名称:StoveFireiOSMenu
  • 源代码网址:http://www.github.com/joeshang/StoveFireiOSMenu
  • StoveFireiOSMenu源代码文档
  • StoveFireiOSMenu源代码下载
  • Git URL:
    git://www.github.com/joeshang/StoveFireiOSMenu.git
    Git Clone代码到本地:
    git clone http://www.github.com/joeshang/StoveFireiOSMenu
    Subversion代码到本地:
    $ svn co --depth empty http://www.github.com/joeshang/StoveFireiOSMenu
    Checked out revision 1.
    $ cd repo
    $ svn up trunk
    
    炉火餐饮系统 iPad 点餐端

    项目背景

    炉火餐饮系统是我于2014年8月至10月期间合作完成的一个外包项目,整个 iPad 点餐端是我负责完成的。当时接手这个项目时根本没有把它当成外包来做,是当成创业在做,经过调研,觉得市面上很多 iPad 点餐系统非常丑陋、难用,根本达不到主流 App 的审美,也不配在 iPad 这种工艺品硬件上运行。对于工程师而言,与其抱怨,不如打开 Xcode,来一次 Write the Code,Change the World,做出一款优秀的点餐系统来!所以当我看到效果图的时候,虽然觉得钱少不太好短时间做出来,还是决定实现它。刚开始的一个月进展缓慢,有些效果不知道怎么做出来,找到的第三方控件要么不满足要求,要么有 bug(难以修改),那段时间恰巧是校招的黄金期,看着同学面试拿 offer,我还在不分日夜的写代码,没有收入没有未来,焦虑,头发大把大把的掉。后来静下心来,看懂一些控件的实现原理,自己自定义控件来满足需求,把一些难点突破了之后,进度突飞猛进,9月底完成了整个 UI 部分。在之前需求沟通时,我观察到客户非常注重界面效果,为了减少需求理解误差,我给数据管理模块提供了测试数据,验证 UI 显示效果与流程,将 UI 体验版放到了蒲公英的公测平台上,让客户下载体验,提出反馈意见,效果很不错(这时候也理解了敏捷强调及时反馈的原因)。完成 UI 之后,就是同后端进行对接,在这个过程中,问题出现了,那就是如何联调测试?每次测试业务流程都需要人工联调,低效且不全面,也很难回归,很多 bug 没有暴露出来,直到去部署时才发现,非常被动。直到真正痛过,才意识到单元测试、自动化测试、TDD 不是理想化,而是能够解决痛点的良药(虽然一开始良药苦口),当时甚至觉得越是小团队人力不足,越需要自动化进行弥补。

    最后,这个项目虽然上线了,但是签的合同有问题,没有验收标准没有验收时间,客户在部署后还在不断要求改需求加需求(关键是本来项目钱很少,还不加钱啊),根本没法在做下去了,我们在程序里也没有加任何的限制性措施(还是图样图森破啊),最终不了了之,占整个项目金额一半多的尾款也没给我们。人生总有许多不如意的地方,谁想到开豪车住别墅开高档餐厅的客户会这个样子,我总想把代码写好,把东西弄出来,反而没注意到合同的漏洞,三个月辛苦,还耽误了校招,就换回来一个 Macbook Pro 还有这个 App。。。我觉得,既然这个 App 我用心做了,不如将它开源出来吧,也算是对自己努力的一种慰藉吧。

    莫忘初心,但行好事,去他妈的前程!

    项目特点

    • 支持主题管理。当时的想法不是只做一家餐厅,而是希望做成模板化,因此将一些 UI 资源抽象成主题,以后可以通过替换主题实现不同餐厅界面的定制需求。具体原理我写了一篇文章,主题更换的实现思路
    • 清晰的架构与设计。
    • 尽量避免重复,保持 DRY。根据 SRP,明确职责,拆成多个类,避免超级类。
    • 利用 KVO 实现数据与显示的解耦。利用状态机在不同数据情况下显示不同内容。
    • 整洁的代码风格。对于重度代码洁癖和处女座的我来说,多一个或少一个空格都让我难受,所以我尽力让自己的代码整洁干净,Git 提交历史清晰准确。工艺品之所以为工艺品,就是在细节上做到了极致,我认为代码也是一样,注重细节的代码其他地方也不会差。

    半年过去了,自己看了《Effective Objective-C 2.0》、《编写可读代码的艺术》之后觉得代码里有许多地方都需要重构,不过当时的我确实尽了自己最大的努力,还是有值得一看的地方的。觉得之前代码需要改进才说明自己有进步,Stay Hungry,Stay Foolish 不是一句空话。

    效果图如下:

    菜单界面

    订单界面

    会员界面

    如何使用

    iPad 点餐端需要连接局域网内的 Web Services 才能正常工作,这一块的代码不在我这里,因此无法开源。但在实现 iPad 点餐端的时候,由于客户是界面效果优先的思维,为了减少需求沟通过程中导致的理解偏差,我先实现了可以脱机运行的 UI 体验版,使用一些测试数据,供客户体验 App 的整个交互流程,提出修改意见,在修正后再接的后端。因此,在没有后端的情况下,也可以通过 UI 体验版来使用 iPad 点餐端。

    打开 UI 体验版的方法:将 SFCommonHeader.h 中的 SF_UI_TEST 宏打开重新运行即可。在进行会员登录时,用户名与密码随意输入字符都能进入会员界面(但不能为空)。

    一些说明

    界面相关

    • 为了一些界面效果,实现了自定义控件:SCRScrollMenuControllerCRTabBarCRModal
    • 由于界面不算复杂,因此 UI 的构建基本上使用的是 Interface Builder。
    • 由于项目需求的原因,只运行在 iPad 上,因此并没有使用 AutoLayout 与 SizeClass,也不支持横屏。

    网络相关

    • Web Services 是 .NET 实现的 SOAP 风格(看到 SFCommandHeader.hhttp://192.168.1.2/webservice.asmx 就知道啦),并不是 REST 风格的。由于 iOS 中 SOAP 的库不太好找,这里使用的是 HTTP Method 的方式,将数据打包成 JSON 格式(为了方便将 JSON 转成 Object),塞到 SOAP 返回的 XML 中,因此需要将数据解析两次,看起来怪怪的。
    • 由于是在项目后期接入的后端,有些赶工期,网络处理部分并没有好好设计,没有抽出网络模块,导致网络通信同业务逻辑之间并没有很好的解耦,如果想将 Web Services 从 SOAP 更换成 REST,并不能很方便的切换。关于网络相关的架构设计,可以参考田伟宇大神的iOS应用架构谈 网络层设计方案

    相关文章