成长自习室

当我们使用 git 时，常用的授权通常有两种方式 HTTPS 和 SSH。当选用 HTTPS 时，每次代码的增删改查都需要输入一串密码进行身份验证，影响代码提交效率，因此大部分情况下我们会使用 SSH 免密登录。那么，在使用 SSH 免密登录过程中，你有遇到过什么问题吗？

想象一个场景，我们正在开发一款支付系统，这个支付系统同时支持有Web版和原生的iOS APP版本。
这个支付系统有三个环境：

• dev: 调用支付的开发环境接口，并不会真的扣钱。
• qa: 调用支付的测试环境接口，假的测试账户中的余额会发生变化。
• production: 调用产品环境中的支付接口，账户余额和钱会真实发生变化。

对于 Web 版的系统，我可以在浏览器中打开三个窗口，然后依次输入不同环境下的域名： www.dev.pay-example.com，www.qa.pay-example.com，www.prod.pay-example.com 来分别进行测试。

对于 iOS APP 呢？我们想要的其实是类似的，打开一台手机，我们可以同时安装三个APP：PayExampleDev，PayExampleQA，PayExample 然后可以切换APP来使用它们。

那么怎样通过一个 iOS 工程打包出三个不同的 APP 呢？方法很多，本文我们就来介绍通过 Xcode Configuration 和 Scheme 的配置方式来实现。

在上篇文章中，我们提到了 怎样在 iOS 中集成 react-natiave-fcm，今天我们主要讨论 Android 中的配置和注意事项。

消息推送在 App 中很常用，那么在 React Native 中怎样来集成消息推送呢？Google 推出的 Firebase Cloud Messaging 是用来做消息推送的，不过在中国国内使用时需要安装 Google Service 。

阅读本文时，你需要知道以下几个概念：

1. Firebase Cloud Messaging：Firebase 的消息推送服务，是 GCM 的 升级版，是 Android 消息推送的新方案，并且其在背后集成了 Apple 的 APNs 服务, 因此开发者可以使用它提供的接口向 iOS 和 Android 设备推送消息。
2. APNs: Apple 的 APNs 服务是消息推送功能的核心，开发者可以使用它提供的一系列接口向 iOS App 推送消息。

react-native-fcm 是 Firebase Cloud Messaging 的 React Native 插件，将其集成到 React Native 项目中时，需要完成 iOS 和 Android 项目中的消息推送配置后，才可成功向对应的平台成功推送消息。本文属于 基于 react-native-fcm 的消息推送 系列文档的第一篇，主要介绍基于 react-native-fcm 的 iOS 消息推送配置。

虽然 React Native 目前已经提供了很多常用的组件，但是在实际项目中，我们总会发现需求往往是这些常用组件所不能够满足的。比如说：图像识别模块、指纹识别模块等。这种模块大部分已经有了比较成熟的SDK，我们此时需要做的就是将已有的轮子，封装到 React Native 中来使用。

经过一些尝试和探索后，我终于找到了一个比较容易上手的封装 React Native 插件方案，希望能得到更多的反馈来改善。

在 React Native 开发中，我们常常会有下面这样的需求：

1. 需要在 App 中显示图标
2. 图标需要兼容不同设备的分辨率（包括 Android 和 iOS 两个平台）

Redux 是 JavaScript 状态容器，提供可预测化的状态管理。它支持 React、Angular、Ember、jQuery 甚至纯 JavaScript。

知识准备

阅读本文时，你需要提前了解一下以下内容：

• redux
• react-redux
• redux-thunk

这三个库中都提供了 dispatch 方法。
本文以这三种不同的 dispatch 为突破口来了解 redux， react-redux 和 redux-thunk 的工作原理。

有这样一个应用场景：

在一个 Android 的 App 中，我们将一个文件下载到 App 中以后，通过点击一个分享按钮，将这个文件分享到本机已经安装了的其他 App 中。

这个场景涉及到下载和分享两个步骤。

岁月是把杀猪刀，每每到年末被它碾压的感觉异常强烈。

所以决定来立一个Flag，记下今年的主要一些大事。

项目中引用第三方包你一般会在什么时候更新呢？是一旦用了某个版本就再也不会更新？还是一有新版本就马上更新？还是定期检查release note，根据自己的需要更新？

在一个React Native项目中，考虑到React Native升级的很频繁，于是团队决定，我们会固定一个React Native版本，每过一个阶段之后，由团队中一个人去完成升级工作。等这个人本地的升级完成，测试通过后，将升级后的代码上传，其他人再基于最新升级后的代码做相关的Feature。

这个故事就发生在一次React Native的升级过程中。