forward compatibility and best cocoapods practice

[yirenjun]

支持iOS 6支持iOS 6支持iOS 6最近流行重要的事情说三遍

需要部署在iOS 6的target，应该对JavascriptCore进行weak linking，之后在runtime判断JavascriptCore是否可用（这里用的是![JSContext class]进行判断，在weak linking的前提下不会crash），当然事实上是可用的，因为会链接到私有的JavascriptCore，根据使用Webkit框架的经验，苹果的审核政策可以接受先前兼容

此外根据stackoverflow上的介绍，还可以通过指定链接标识来不明确链接到JavascriptCore
-Wl,-U,_JSGlobalContextCreate
-Wl,-U,_JSGlobalContextRelease
在App加载时能通过UIKit → WebKit → JavaScriptCore这条依赖路径完成JavascriptCore的链接

不过我觉得没卵用

[jiffes]

iOS6 support needed!

[bang590]

支持iOS6很好，不过JSPatchDemo项目用于调试和演示JSPatch，不应该用pod安装

[yirenjun]

这就是我说的cocoapods最佳实践 看看别人怎么做

[bang590]

我想你可能误解了这个“cocoapods最佳实践”，我没看到一个开源项目的demo是这样做的。

[leafduo]

首先，支持 iOS 6 和改变 demo 工程的继承方式这两件事应该在不同的 PR 里。

关于 CocoaPods 的最佳实践，我们也是这样做的。这样的好处是，demo 与其他使用到这个 pod 的工程使用同一种集成方式，可以更好地验证 CocoaPods 工作正常；也节省了拥有两种不同集成方式的配置开销。CocoaPods 也确实推荐这样做， 参考以下两个链接：

http://guides.cocoapods.org/making/using-pod-lib-create.html
https://github.com/CocoaPods/pod-template

[yirenjun]

@bang590 关于最佳实践 ... @leafduo 也对你这个观点给出了回应

我一直觉得开源项目最大的价值不在于代码开源 而在于心态开放

你没见过一个开源项目的Demo这样做 可能有两种情况 一种是这种实践真的不被大家认同 一种是你应该拓展你的眼界 但我想你要表达的应该是前一种意思 我曾是MIG的 一事无成 最近又变得喜欢倚老卖老 希望你不要太过在意 毕竟你是位能力强劲又潜力巨大的同事
技术人理想中应是惺惺相惜 现实中大多彼此相轻 这是国内的大环境 习惯就好

@leafduo 确实应该放到两个PR里面 我当时没这么做 处于发展初期的项目 我以为这两个都会被很轻松采纳的 推动JS替代WAX作为iOS上的Patch技术 很有价值 可能目前主要还是在邮箱那边用吧 如果有更多大的项目来背书 来一起推动 应该是加分的事情 我之前了解到手淘在考虑跟进 我这边的项目也在考虑跟进

[bang590]

我一直对所有PR保持着开放的心态，而接不接受一个PR我有自己的判断方式，如果对现有方式改变，我首先会想这对项目的好处和坏处是什么。

按我个人看法，demo项目改成pod，好处是@leafduo 说的“demo 与其他使用到这个 pod 的工程使用同一种集成方式，可以更好地验证 CocoaPods 工作正常”，这个我认同。但坏处有：

1.强制让使用JSPatch的人必须使用CocoaPods ，否则连demo都跑不起来，把跑起demo项目这件事的门槛提高了，对一个想了解JSPatch的人来说体验很糟糕。

2.对于日常开发JSPatch调试非常不便，开发体验很糟糕。

作为一个开源项目我认为不应该强制使用某一种包管理方式，CocoaPods 不是必须的，实际上因为JSPatch项目轻量，我更推荐非CocoaPods的方式使用。所以我的看法是这种方式坏处大于好处，不适合。如果不同意我的看法，大家可以讨论下，这是正常的技术交流哈，确实目前我技术视野还比较窄，不对的地方欢迎指正，我也很喜欢这样的讨论交流。

实际上现在主要的使用者的不是邮箱，而是微信 美团 蘑菇街 去哪儿 蚂蜂窝等，一直非常欢迎大家一起推动JSPatch哈。

[leafduo]

针对提出的两个坏处：

1. 通过把 Pods 目录签入到 Git 是可以不使用 CocoaPods 就把 demo 跑起来的。
2. 至于说开发调试的话，唯一的区别就是如果添加了一个头文件的话，需要 pod install 一下；如果只是修改的话，完全没有增加复杂度。

所以说，把 2 个事情提交不同的 PR 吧

[bang590]

@leafduo
1.确实可以，但这似乎跟那个好处相矛盾了。另外使 demo 项目显得臃肿，不使用 CocoaPods 的人会对此一头雾水，比不上原来的方式简单直观轻量，简单轻量是 JSPatch 较重要的特性。
2.这个我之前想错了，不过项目开发还是依赖了 CocoaPods (如你说加头文件要 pod install)

说到底就是不想影响不用CocoaPods 的人。

赞同提不同的PR

[yirenjun]

@bang590

看我的这个提交 provides out of the box capacity for JSPatchDemo ... some gays need it!
这个提交实际上就是解决了『对不使用Cocoapods的人造成体验Demo的门槛』的问题，开箱即用

[yirenjun]

@bang590 我想你说的微信...蚂蜂窝应该都还是在跟进阶段 去哪儿都还是iOS6+的 圈子那么小或者你多问问 不过随着JSPatch成熟应该有更多技术团队选择这个方案

另外我觉得JSPatch到稳定应该是还需要点时间的 不仅仅JSPatch本身 也包括常用的扩展

[yirenjun]

@leafduo 其实pods目录已经签入了
看看这个提交 provides out of the box capacity for JSPatchDemo ... some gays need it!
在Demo目录使用本地Pods 其实只是按照Cocoapods的思路建立了xcworkspace等结构 然后建立了一堆软链到引用的头文件

[bang590]

@yirenjun
pods 目录没有签入，.gitignore 里写明忽略了。
其他该说的都说了，没什么新的理由说明这样做更好。

关于支持 iOS6，我没机器测，这样的方式应该是可以编译过，但 iOS6 不会运行JSPatch？

[yirenjun]

@bang590 暂时没让运行 但是可以运行

[yirenjun]

@bang590 把Pods提交了 .gitignore我开始没仔细看 里面注释也说不建议把Pods加入到ignore列表

如果你坚持不要改为cocoapods推荐的这种实践 我再重新把iOS 6支持的给拎出来

[bang590]

@yirenjun
我还是不希望引入 cocoapods 这种做法哈，见谅。
对于 iOS6 的支持，会不会容易给人一种误解，因为写着支持 iOS6，就认为 iOS6 下也会运行 JSPatch 脚本，实际上是不运行的。让使用者在使用时如果要支持 iOS6，自己在上层调用 [JSPatch startEngine] 之前做判断，是 iOS6 以下就不运行，会不会更清晰？

[yirenjun]

@bang590 其实只是为了兼容iOS 6，但毕竟JSCore没有在iOS 6上成为一个公开的框架

大多场景是这样的 一些国内成熟的产品暂时还不愿意放弃掉iOS 6的用户 可能占比还在4%~6%区间 但对于这部分用户的体验已经不很关注了 能否为他们提供Patch修复并不很重要 但不能为了提供Patch能力就提高部署版本 完全不支持这部分用户升级新版本