fir-mac 开发笔记

练手 Cocoa 开发，开发并开源了一款 fir.im 的 Mac 客户端，此篇主要记录其开发历程，总结一下遇到的问题

原因

某一天忽然翻到本身 GitHub 下有一个空仓库，名字叫 fir-mac，提交时间在 2016 年 6 月 22 号，恍然大悟原来又是弃坑项目之一。
因为从事 iOS 开发后一直对 macOS 开发比较感兴趣，感受 Mac 应用有一种天生的美感，更是在 OS X 10.10 Yosemite 以后的扁平化、毛玻璃、各类窗口细节的优化感到和往日使用 Windows 的差别；那既然都已入苹果的坑，何不顺势玩玩 Cocoa 桌面开发呢， 业余时间先后写了 MyMacMusicPlayer 和 CubicBezier，也算小入了一点点 Cocoa 的门，想继续找项目在实战中磨练本身，而后由于有段时间用 fir.im 比较多，隧萌生了为其作一个 Mac 客户端的想法。

准备

开发以前首先得想一想会遇到最大的问题是什么？那应该是 fir 的接口，官方有没有开放接口？接口有没有限制？这是我做为一个第三方开发人员没法控制的事情，所辛 fir 在很早的时候就开放了他们的 API 及其文档，而且借口都比较齐全，证实他们对此是保持开放态度，那么接口的障碍没有了还有其余问题吗？
这时我就预估一下了应用的总体功能模块，以及大体实现方法，把项目难点提早筛出来看看，fir-mac 做为一个基于 Mac 系统的 GUI 客户端，首先是 UI 的搭建，最初想法，用一个列表（NSTableView）呈现帐户下全部的应用，而后点击应用能够展开其详细信息，感受应该能够实现，固然 UI 动画、优化什么的暂且先不提，毕竟先得把功能作出来才是第一步。

功能架构

功能上主要参考 fir web 端，包括上传应用、查看应用列表、查看应用详情，差很少就这样，简简单单实实在在。

sketch

后来有朋友在微博上评论说想要扫二维码下载的功能，很快也增长进去了。
若是你是本软件的使用者，有什么功能上的意见或想法欢迎与我联系哦。

UI设计

UI 最终成品基本上也继承与最初的想法而来，简单的 List，弹开应用详情，采用 Vertical Split View Controller 分栏设计，把左右两边分开并各自独立 NSViewController，从而使业务逻辑分离开来，在 Storyboard 上看起来是这个样子：

TableView

右边的块区域用了 NSBox 做收纳子元素和框样式，隐藏掉了 Title，想一想在 iOS 上搞这个还得弄个 UIView 设设圆角什么的。（有时候总会想到 CocoaTouch 里的东西去）
Cocoa 里原生提供了三种列表组建，分别是 TableView、Outline View、Source List，而 Outline View、Source List 都是基于 NSOutlineView 的定制，而 NSOutlineView 则 NSTableView 的定制，因此归其总都是 NSTableView 一个东西。

TableView

fir-mac 左边侧边栏的列表则用的 TableView，自定义其 Cell 来展现的：

CustomCell

最后的实际运行效果以下：

screenshot

能够看到其实和 Storyboard 类似度很高，开发此类小应用使用 Storyboard 构建 UI 效率很是高，而且由于窗口设计成固定大小，要么缩小要么关闭，不能缩放，因此也不用去拉 AutoLayout，真的省心。

困难1：接口的调试

从最开始本觉得很简单的 form-upload 操做，废了两晚上时间才搞定，由于 fir 的应用包是存在静态文件服务器上的，并且后端采用了不一样的云存储商，因此上传文件须要两个步骤，第一步先获取凭证，第二步再用拿到的凭证进行表单上传，由于应用二进制和应用图标是分开上传，因此一次提交应用的操做其实会发三个请求，[拿 Token] -> 上传图标 -> 上传应用。
有点不明白的是应用图标自己也是从其应用文件中提取出来的，为何不把这一步拿到服务端作呢？为了节省服务器资源吗？还有其应用信息，感受放到服务端作会更可靠，由于 fir 不止一个客户端工具去作上传，好比 Website、Command Line Tool，各类 IDE 插件，每一个端都须要去编写这套包解析和两次上传请求，首先维护成本增高，解析提交的数据还不必定是可靠内容，形成脏数据提交到服务端。
好吧先不纠结这个接口设计了，想说的是为啥在一个上传文件的功能上绕了弯路，最后找到问题是由于一个参数的参数名写错了，而且服务端没有错误反馈，仍然返回的请求成功，这我就懵了，而后抓了一下 web 所请求的参数值，拿过来用错误的参数名提交竟然也成功了。这就是为啥蒙圈在这这么久的缘由。

困难2：包解析

本觉得 fir 的接口如上文所说是由服务端解析应用包，提取出应用信息好比应用名、版本号等等，结果发现实际上是本地解析拿到这些信息而后再提交给接口，拿 iOS 的包来讲，后缀为 .ipa，在 macOS 本地的流程大体以下：

1. 用 mktemp 命令建立临时目录
2. 用 unzip 解压 .ipa 到临时目录
3. 逐级目录查找到 Payload 文件夹
4. 读取 Info.plist 文件
5. 根据 CFBundleIdentifier、CFBundleShortVersionString… 提取出应用信息和 ICON 图标
6. 删除以前生成的临时目录

mktemp 是一个 linux 命令会在系统层级建立一个临时目录，路径是随机名大体以下 /var/folders/r3/x98gzjpn7rxct9y4rtnjsv5m0000gn/T/，不会重复保证必定安全性

unzip 是 linux 下解压 zip 文件的命令，经过参数 -d 来指定解压目的地为以前生成的临时目录

读取 Info.plist 文件本打算用 defaults 命令来完成，后来发现实在不如读取进 Dict 操做方便

以上即是用户选择一个 .ipa 文件提交上传前所需作的工做，因为 Android 包 .apk 数据结构又不同，因此支持 Android 应用上传须要另外编写一套解析逻辑，故目前 .apk 上传还未支持。（话说写这个真累，项目开源欢迎有志之士共享一份力量！）

引用

因为应用主要创建在与 fir.im 接口的 HTTP 通讯上，因此引入了 Alamofire 来作全部的网络请求，包括数据拉取和文件上传；而后由于接口返回全部数据格式均为 JSON，为了人性化编程又引入了 SwiftyJSON；项目列表还存在网络图加载，为了省事也直接用了 Kingfisher；由于有了这些项目的积淀，咱们才能把更多的注意力放在其余事情上，避免不少重复而基础的工做，感谢开源！

开源协议

关于选择开源协议，一直都没有太深入的理解，只知道 MIT 最开放自由，那就 MIT 咯，后来看到微博上你们评论说 MIT 难道不怕又被翻去上架卖钱吗？以前就有 PPRows 的事情，PPRows 的做者也来跟我说让我换掉开源协议。
翻看了一下，像开发组件大部分都采用 MIT，宽松，可是不少完整项目都采用了 GPL-3.0，好比 PHP CMS 系统 http://www.javashuo.com/tag/drupal ，播放器 iina、SQLite 数据库浏览器 sqlitebrowser 等等，他们采用 GPL-3.0 更是为了限制商业使用。做为一个开源做者的心愿首先确定是但愿本身的项目能发展起来，项目被他人商业化估计不少做者都是不肯看到的事，开源界关于协议版权的闹的事情已经不少了，但愿那些坐享其成经过开源项目结合流量与市场榨取用户的人，能把更多注意力放在作事情自己，而不是一点蝇头小利和旁门左道。

一不当心吐槽了一番，本文差很少就这样结束了，若是你尚未 star 这个项目，赶忙来吧：github.com/isaced/fir-…