0903 - Firebase Analytics PK Google Analytics

发表于 2017-09-03 | 分类于每天写一点

之前一直是使用 Google Analytics，无奈 Google 已经禁止移动版的 Google Analytics，全面让位于 Firebase Analytics；于是，在 iPaste for iOS 中，只能选择后者了。

万万没想到，作为继任者的 Firebase Analytics，在 Event 方面远不如其父辈：

数据更新慢，目测要 4+ 个小时。在这开始时很要命，因为第一次接触 Firebase，总要多试试才能摸清楚。可试一把就要 4+ 个小时，怒火中烧~
不支持没有实时事件。虽说有开发者模式，但明显差很多。
不支持 Category/Event/Label 分类，这个应该是最不方便的。
- 最终，我是使用 AnalyticsEventSelectContent 中的 AnalyticsParameterContentType 和 AnalyticsParameterItemID，够强实现了二级分类的 Event.
不支持页面跳转流。
报表简陋。
- 比如不支持自定义 Dashboard.
- 即使是内置的 Parameter，都无法完全显示在报表中；而自定义的 Parameter，则想当别想了。目测导入 BigQuery 是可以看到的，但目测麻烦、且要钱。
会带来网络请求。这是废话，关键的是，我想延迟网络请求直到用户手动操作，这样 iOS 弹出网络授权时，用户更不可能拒绝。稍后再想想怎么优化。

当然，还有有些好处的：

可以自定义用户属性。
- 比如，可以用于区分开发环境和生产环境、是否曾参加 TestFlight 测试。
生成漏斗报表更方便。比如付费转化率。
Firebase 内置 Crash Report，这个有用。
如果集成了 Ad 模块，可以识别出更多用户画像，比如年龄段、爱好、等等。不过，会让 AppStore 审核更严格。

才刚刚接触 Firebase，后续还有很多要学习研究的。

0902 - Preferences & Permission

发表于 2017-09-02 | 分类于每天写一点

在 iPaste 的外围功能中，今天主要搞定了 Preferences & Permission.

Preferences 方面，由于目前主要是静态的功能，于是采用了 UITableViewController，基于 UITableView 使用 Static Cells 模式，手动添加一个个选项。其它一些细节：

使用 SFSafariViewController 在应用内打开网页，不至于跳出应用。
使用 MFMailComposeViewController 发送反馈邮件。
当系统未配置邮箱时，打开网页进行反馈。

Permission 方面，目前 iPaste 仅使用了网络权限。主要要注意的点：

在应用启动时，避免一切网络请求。仅当用户有手动操作时，才请求网络。主要的好处是：不至于首次打开应用，就被提示要授权网络连接。
封装检测当前应用是否可以访问的方法。对于重要的网络请求，先检测网络是否通畅。
实际测试有些麻烦。因为 iOS 仅在用户首次运行时才弹出授权申请，要重置就要重置所有应用的权限，卸载程序都不行。感觉真的很不友好。

另外，我一直觉得应用应该尽量减少配置项，今天碰到法理依据了：

0901 - 虽已马不停蹄，无奈时光飞逝

发表于 2017-09-01 | 分类于每天写一点

以下为 8 月计划：

发布 iPaste for macOS 2.0
发布 iPaste for iOS 1.0
二者数据可以相互同步

转眼已是 9 月。

回顾 8 月，虽然一直在忙碌，无奈自己太过浅薄，要学的东西太多，以至于并未完成原先看起来并不复杂的计划，一声嗟叹。

无奈，将 8 月计划照搬至 9 月：

（争取）发布 iPaste for macOS 2.0
（争取）发布 iPaste for iOS 1.0
已有产品适配 macOS 10.13

但愿时光停止。

0831 - 每晚放松一刻

发表于 2017-08-31 | 分类于每天写一点

最近养成了个习惯：每晚下楼，边走边听小说。

借小说中描述的世界，放空大脑，缓解一天的疲惫，效果还不错。顺便还能稍微锻炼下身体，吹吹凉风，舒服。

大脑这家伙，是挺奇怪的，你专门休息，它丫还是会在潜意识里思考东西，有好有坏吧。好的是，可以不经意想想出问题的答案。坏的是，你真的想休息时，它丫还在干活。没办法，只有给它点别的信息处理，它才会不得已放下先前思考的东西。

最近在听的是《间客》，是之前听过的《庆余年》作者猫腻所著，其实还是能听出很多共通的东西，毕竟同一个的框架、模式、套路，总有相似的痕迹。昨天听的打斗的场景有意思的，今天的部分一般般了。

0830 - 迂回于 Swift 包管理

发表于 2017-08-30 | 分类于每天写一点

今天又折腾了下 Swift 包管理。

目前是用 CocoaPods，其实也没太大问题，但总觉得 对代码的侵入太强。这不，iPaste for iOS 起了个新项目，想换个清爽点的，于是就又折腾了下。

除了 Pod，主要有 2 个选择：Carthage 和 Swift Package Manager. 后者现在还太嫩，仅适合 Swift 项目，很多第三方并不支持，遂放弃。

那就来到了 Carthage；其实 Carthage 并不复杂，实质是下载第三方库的源码、本地编译为 Frameworks. 剩下的事情，就要开发者自己手动操作了。其实手动也没什么，就是把 Frameworks 作为 Linked Frameworks 加入项目中，并在编译时复制入 .app.

为什么不用 Embeded 方式呢？因为毕竟第三方库是会变的，如果用 Embeded 相当于写死了版本，后续升级时有些麻烦。当然，也是可行的。

这里就可以看出 Pod 和 Carthage 的二点不同：

Pod 实质是使用源代码集成
- 好处：在写代码时可以方便跳转至第三方库的源码中
- 坏处：编译速度慢，尤其是全新编译或打包时
Carthage 实质是使用 Framework 集成
- 好处与坏处，正好与 Pod 相反
- 不过，在集成 dYMS 后，也可以在调试期间跳入第三方库的源码中，但依然不能在写代码时跳转

Carthage 这里有个坑：Swift 编译器版本。

如果你电脑上仅有一个 Xcode，没什么问题。而如果你同时安装了 Xcode Beta、又恰巧要为 Xcode Beta 的项目添加依赖，就有问题了。
Carthage 默认是用 xcrun swift --version 所得到的 Swift 版本进行编译的。而默认情况下，这个肯定是 Xcode 而非 Xcode Beta 的运行环境。再来个而，Swift 3.2 的项目，是无法引用 Swift 3.1 编译器编译出来的 Frameworks 的。
解决方案也很直接，使用 Xcode Beta 中的编译器即可。只是，貌似 Carthage 并没有相关的参数方便地切换（比如，我试了 TOOLCHAINS=com.apple.dt.toolchain.Swift_3_2 carthage update --platform iOS 来指定 Swift 编译器版本，不过貌似并没有干活），最后比较土的先将 Swift 默认编译器改为 Xcode Beta 版本，编译后再改回来。

1
2
3

sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer

carthage update --platform iOS

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

Carthage 这么简洁美好，万万没想到，最后还是倒入了 Pod 的怀抱。

因为 Firebase 只支持 Pod 方式集成？！

根本原因是，Firebase 并没有完全开源，部分代码只能用静态库的方式发布。而 Carthage 目前对静态库的支持并不好（虽然网上也有人成功了，但毕竟不是官方支持，有些麻烦，放弃了）

早说嘛，我就不折腾 Carthage 了，何必呢？

另外，还折腾了 iOS 与 macOS 项目间共享代码。因为我不想将二者放在一个工程里，怕同时调试时麻烦，就分为 2 个项目了。现在看来，主要有如下方式集成：