商品类型

1. 消耗型
2. 非消耗性
3. 自动订阅
4. 非自动订阅

类似“会员”功能, 有明显有效期特征的, 必须使用 非自动订阅 / 自动订阅, 否则审核会被拒

Receipt (回执)

receipt 是用户购买成功后的回执单, 其自身是一段被加密的数据. iTunesConnect后台可以生成 SharedSecret (共享密钥), 通过 SharedSecret + receipt 对 Apple 服务器发起验证, 可以取到明文.

当且仅当 用户付款成功, 才会获取到 receipt .

Image for post
Image for post
购买流程

处理漏单

漏单是指 用户在付费成功后, 但 未校验/上传 成功.

IAP在每一次付款成功后, 都会生成一个 `SKPaymentTransaction`, 需要开发者在完成购买的业务流程后, 手动调用 `[SKPaymentQueue finishTransaction]` 将 transaction 标记为成功.

漏单即是 存在未被 finish 的 SKPaymentTransaction.

通常在 `application:didFinishLaunchingWithOptions:`时, 检查当前是否存在漏单, 并对漏单进行处理.

防伪造

Validating Receipts With the App Store

客户端校验通常用于 无服务端/轻服务端 的App. 在购买成功, 收到 receipt 之后, 由客户端向Apple发送请求, 校验receipt. 在校验成功后, finish transaction.

在涉及服务端校验购买结果时, 通常在购买成功后上传receipt到服务端, 服务端对收到的 receipt 发到Apple的服务器进行校验. 所以流程上, 购买成功后, 拿到receipt, 需要上传到业务服务端, 在上传成功后 finish transaction.

关于服务端对收到 receipt 的校验, 因为涉及到对Apple服务发送请求. 所以通常有两种处理方案:

1. 将 校验receipt 的工作加入消息队列, 异步进行处理.
2. 同步处理receipt的校验, 在遇到Apple服务请求超时等网络原因的情况下, 返回重试. 客户端在接收到重试状态时, 不去 finish transaction, 而是走漏单流程, 在用户下一次打开app时, 当漏单处理, 重新上传receipt到服务端去校验.

即客户端在收到receipt之后, 先进行客户端校验, 通过后再进行服务端校验.

考虑一下双重校验的必要性, 一般服务端校验, 就已经足够, 额外的客户端校验会使购买流程以及用户等待的时间变长.

发布前检查

检查 “功能” 中的 “App 内购买项目”, 查看各个商品的状态是否是等待审核.


引言

对于独立开发者来说, 测试资源一直是非常头疼的问题. 对于传统手点的方式, 需要花费非常多的时间在测试上.

GUI应用, 单测能做到的事情很少, 集成测试的地位非常重要.

Image for post
Image for post

大部分人在编写UI测试代码的时候, 会大量判断视图的位置和排版.

不幸的是, 和逻辑不同, UI总是改变.

我相信这是大部分人没有坚持下去的原因.

如果通过编程的形式去编写UI测试, 后续会带来大量的维护成本, 我们会花大量时间在修改原有的用例上.

我在日常的独立开发中, 摸索出一套方案. 并在 滴墨书摘 当中使用.

其实我们可以从另一个方面入手. 可以通过对每一步关键操作进行截图, 并在测试结束后对外输出一组截图. 通过截图去判断结果是否正确.

这样又会带来另外的问题. 例如, 截图怎么去判断是否正确? 如果完全基于肉眼去校验, 一来 …


iOS 下, 通过 .strings 文件来做 本地化/国际化.

以往, 我们增删一个本地化文本, 需要在源文件和各个 .strings 中手动修改.

其实, 可以从源文件中自动生成各个 .strings 文件. 甚至对于 简体(zh-Hans) 到 繁体(zh-Hant) 的翻译也可以通过自动化的方案解决.

genstrings

genstrings 是 Apple 在 OS X 10.9 添加的 .strings 文件生成工具. 它可以通过源文件(.c, .m, .swift) 生成 strings 文件.

例如: 遍历当前目录(以及子目录), 将所有 .m 生成 .strings 文件.

$ find . -name *.m | xargs genstrings -o en.lproj

上面的命令会生成(覆盖) …


问题

在我兴致勃勃写了一个 cli 工具(也就是 TyStrings )的时候, 希望在 README 中添加一个 gif 来展示它酷炫的效果.

通常, 我们会这么做:

Image for post
Image for post

这相当麻烦. 人为的演示很容易出错, 总要反反复复录制, 后期编辑也非常麻烦.

如果后续维护时, 添加了新的命令, 抑或是仅仅修改了输出, 那么就又要录一次.

这显然很槽糕.

自动化CLI演示的解决方案

我列出了我的自动化需求:

1. 通过脚本执行, 从 录制 到 导出 gif.

2. 脚本演示CLI, 无需人工干预.

我寻找了很久, 可以并没有找到对口的解决方案.

摸索了很久, 最后结合 ttygif + AppleScript + iTerm 2 来做这件事.

ttygif

ttyrec 是录制 tty 的命令行工具

sugyan/ttygif 基于 ttyrec, 但它将 ttyrec 的输 …


简介

ImageMagick 是一个跨平台图像处理软件, 可以在命令行中完成绝大多数图像处理。

优势

ImageMagick 通过命令行调用, 在批量处理图片时有很大优势.

虽然 PhotoShop, 也默认提供了部分脚本, 但是其功能过于简单, 而且执行起来非常慢(感觉就像是在执行一个Action)

Install

可以访问 [ImageMagick](http://www.imagemagick.org/) 的官网, 获取安装包

[http://www.imagemagick.org/](http://www.imagemagick.org/)

ImageMagick 没有提供 deb 安装包

在 Ubuntu 下, 可以使用 apt-get 来获取 imagemagick

sudo apt-get install ima …

Yiyan Tian

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store