构建 F8 2016 App 第一部分:开发计划

imagic1987 8年前
   <p>这是为了介绍 React Native 和它的开源生态的一个系列教程,我们将以构建 F8 2016 开发者大会官方应用的 iOS 和 Android 版为主题。</p>    <p>在第一部分,我们将介绍我们是如何计划的,在后面的部分,我们将分享示例代码,讨论多平台设计需要考虑的事情,分析应用的数据层,最后解释我们所选择的测试策略。</p>    <h2>使用 React Native</h2>    <p>在 2015 年的 F8 大会,我们使用 React Native 开发了官方应用的 iOS 版,但 Android 版使用的是原生代码;在更早的大会上,我们在两个平台使用的都是原生代码。去年大会之后,React Native 发布了 Android 版本,这给我们提供了机会来削减应用的逻辑和 UI 代码。部分 非死book 团队在使用 React Native 时发现<a href="/misc/goto?guid=4958967434383045900">达到了 85% 的代码共用</a>。</p>    <p>React Native 在原型设计方面也有优势,它可以在你和 UI 设计师讨论的时候快速构建视觉组件原型,这些我们将在<a href="/misc/goto?guid=4959671309643563090">第二部分</a>讨论。</p>    <p>所以,如果我们选择使用 React Native,还有什么需要考虑的?让我们先从内容开始。</p>    <h2>选择一个数据层</h2>    <p>2014 和 15 年的 F8 应用都使用了<a href="/misc/goto?guid=4958342259767865634">Parse</a>作为数据后端。因此,在我们计划开发 2016 年的应用时,使用 Parse 将允许我们重用现有的数据结构,以及能够快速开发开发。</p>    <p>选择 Parse 也有其它的原因 - 从大会准备到举办的期间,应用所展现的内容需要经常更新,并且内容更新应该像更新表格一样容易,而不需要工程师来协助。Parse 提供的 dashboard 能完美的满足这些需求。</p>    <p>由于以上原因,选择 Parse 作为后端顺理成章。不过,由于 <a href="/misc/goto?guid=4958984110832040139">Parse 宣布将停止服务</a>,我们转而使用开源的 <a href="/misc/goto?guid=4958984111096906908">Parse Server</a> 和<a href="/misc/goto?guid=4959671309811427738">Parse Dashboard</a> 来替代它。</p>    <p>由于 React Native 并不需要时刻与数据层保持紧密连接,比如 UI 和应用逻辑能使用模拟数据完成开发。这意味着我们可以仅以极少的代价替换整个数据层。比如在开发完 F8 应用后,我们能够非常容易的从 Parse 转移到开源的 Parse Server,我们将在<a href="/misc/goto?guid=4959671309643563090">第三部分</a>进一步讨论。</p>    <h2>React Native 应用的数据接入</h2>    <p>为了让 Parse 和 React Native 协同工作,我们已经有了 <a href="/misc/goto?guid=4959671309907303297">Parse + React Native package</a> 来提供必需的绑定工具,不过这里有一个问题 - 考虑到会场 wi-fi 和连通性并不总是表现良好,F8 应用需要支持离线工作。因为 Parse + React 并不提供离线数据同步功能,我们只能自己开发。</p>    <p>这里还有另一个决定因素 - 团队大小。比如,提供类似功能的 Relay 更适合大型团队开发大规模应用,但 F8 应用的开发者只有一个人,以及少数其它人提供设计支持。这将极大影响你在开发应用中使用的数据接入方法。</p>    <p>那么 <a href="/misc/goto?guid=4958969559348274332">GraphQL</a> 和 <a href="/misc/goto?guid=4958965462526757079">Relay</a> 呢?虽然它们与 React Native 工作良好,但<a href="/misc/goto?guid=4959671310041145094">目前为止</a>,Relay 不提供内建的离线使用,而 Parse 对 GraphQL 的支持并不完美。使用它们开发,我们需要构建 GraphQL 到 Parse 的 API,并且开发 Relay 的离线存储方法。</p>    <p>GraphQL 服务器的设置对于面临紧迫工期的个人来说也相对复杂。我需要开发应用并发布到应用商店,只能选择最简单并且最快的方式,除此之外我还能怎么做呢?</p>    <p>由于以上原因,<a href="/misc/goto?guid=4958974668870314948">Redux</a> 也是应用的一个最佳选择。Redux 提供了 <a href="/misc/goto?guid=4958973395995344945">Flux 架构</a>的一个简单实现,对数据的存储和缓存提供更多控制,并最终让应用能从 Parse 进行单向同步。</p>    <p>对应用的存储部分,Redux 提供了功能性与易用性之间的平衡。在应用发布之后,我们重新梳理了这一部分,并且使用 Relay 和 GraphQL 实现了一遍,我们将在 <a href="/misc/goto?guid=4959671310183418460">Relay 和 GraphQL 附加部分</a>讨论这些。</p>    <h2>我们的开发技术栈</h2>    <p>将 React Native 作为我们的应用框架,以及 Redux 作为数据层,我们需要一些其它的支持技术和工具:</p>    <ul>     <li>开源的 <a href="/misc/goto?guid=4958984111233327452">Parse Server</a> 提供数据存储 - 运行在 <a href="/misc/goto?guid=4958867323246690255">Node.js</a> 上。</li>     <li>我们使用了 <a href="/misc/goto?guid=4958999008700380509">Flow</a> 来检查 React Native JavaScript 代码中的类型错误。</li>     <li><a href="/misc/goto?guid=4958834376951638365">Jest framework</a> 用来对复杂的函数进行单元测试。</li>     <li>使用 <a href="/misc/goto?guid=4959671310379393191">React Native 非死book SDK</a> 来快速集成 非死book 接入功能。</li>     <li>使用 OSX 平台的 <a href="/misc/goto?guid=4958869360343929528">Nuclide</a> 编辑器,以及它<a href="/misc/goto?guid=4959671310482713543">内建的 React Native 支持</a>。</li>     <li>我们还使用 Git 做版本管理,将开发的过程都存储到了 <a href="/misc/goto?guid=4959670935995486083">Github</a> 上。</li>    </ul>    <p>我们还使用了一些小的附加工具包,当我们在教程中碰到时会重点提到。</p>    <p>在你阅读系列教程的下一章节之前,我们推荐你先学习 <a href="/misc/goto?guid=4958968993327282907">React.js 的官方教程</a> - 特别是它的<a href="/misc/goto?guid=4959671310619902070">模块化组件概念</a>以及 <a href="/misc/goto?guid=4958869464629810646">JSX 语法</a>。然后阅读 <a href="/misc/goto?guid=4959630544268226611">React Native 的引导教程</a>,它将展示将其用于移动应用开发的一些基础知识。</p>    <p>下一篇:<a href="http://www.open-open.com/lib/view/open1461511458980.html">构建 F8 2016 App 第二部分:设计跨平台App</a></p>    <p>来源:<a href="/misc/goto?guid=4959671310775114522">pockry</a></p>