NAVITIME自治体アプリ高速リリースの舞台裏 - インバウンド事業でのReact Nativeの導入について -

3/27（水）に開催されたDevLOVE様主催のイベント『ナビタイムの現場 第2経路 -ナビタイムを支える技術-』にて発表した資料です。

Transcript

1. NAVITIME自治体アプリ高速リリースの舞台裏 - インバウンド事業でのReact Nativeの導入について - 株式会社ナビタイムジャパン インバウンド事業部 櫻井 友了 2019/3/27
2. ©NAVITIME JAPAN Agenda 2 今日お話すること ・インバウンド事業部についてご紹介 ・ReactNativeについて ・導入の目的と背景 ・実装方法を簡潔にご紹介 ・AppCenterについて ・導入の効果について ・導入してみてよかった点、辛かった点 ・今後こうしていきたい ・最後に
3. ©NAVITIME JAPAN Agenda 3 Notice 今回は、ReactNative絶対論ではなく、その時々のビジネス、 チームあるいは組織の状況に応じて、最適な技術選択の 指針の一つとして捉えて頂ければ幸いです。
4. ©NAVITIME JAPAN 4 ですので、ネイティブで作ったほう がいいものはネイティブで作ること をおすすめします。
5. ©NAVITIME JAPAN 自己紹介 5 櫻井 友了(サクライ トモアキ) 2012年、株式会社ナビタイムジャパンに新卒として入社。 データ開発・運用チームに配属となり、Oracle、MySQL DB設計やPythonでWebサ イトクローラーを開発するなど、主にバックエンドを3年間担当。 その後異動し、複数のプロジェクトでWeb開発担当となる。NAVITIME Travelサイ トの開発ではReact.jsを導入、インバウンド事業部へ移った後は社内で初めて ReactNativeを導入した他、PWAやNext.jsの導入など、Web界隈を中心に先進的な Web技術導入を行う。 ベースと猫が好き。 スピーカー
6. ©NAVITIME JAPAN 6 NAVITIME JAPAN について
7. ©NAVITIME JAPAN 事業領域について 7
8. ©NAVITIME JAPAN 事業領域について 8
9. ©NAVITIME JAPAN 事業領域について 9 私が所属する事業
10. ©NAVITIME JAPAN 10 NAVITIME インバウンド事業部について
11. ©NAVITIME JAPAN 11 主に地方自治体や企業と手を組んでサービスを提供
12. ©NAVITIME JAPAN 12 ナビタイムジャパン
13. https://noctive.jp 2/18リリース 日本の夜を活性化する取り組みとして、全国のナイトライフ情報を発信 するサイト「NOCTIVE」をリリース。
14. ©NAVITIME JAPAN インバウンド事業部について 14 ・6ネイティブアプリ、2Webアプリを運用中。 運用プロダクト
15. ©NAVITIME JAPAN 15 React Nativeについて
16. ©NAVITIME JAPAN ReactNativeとは 16 React Nativeは、Facebook社が中心になって開発が進められている オープンソースのクロスプラットフォーム開発ツール。 ▪ JSエンジンからネイティブコードを実行して、ネイティブUIを構築する ▪ Webエンジニアでもネイティブアプリ開発ができる。 ▪ iOSとAndroidでViewコードを共通化。 ▪ 急な仕様変更でも、サーバーに置いてあるJSを差し替えて、ネイティブ側で 読み込むだけでコンテンツの変更/修正ができる。(AppCenterの章でお話しま す。)
17. ©NAVITIME JAPAN ReactNativeとは 17 ・DOMのような構造で要素を定義できる。 ・スタイルもcssのような書き方で定義できる。 ・フロントエンドエンジニアにとって理解し易い記述。 サンプルを紹介 DOMの構造を定義 styleを定義
18. ©NAVITIME JAPAN ReactNativeとは 18 サンプルを紹介 <View> ≒ <div> <Text> ≒ <span> というイメージ。
19. ©NAVITIME JAPAN ReactNativeとは 19 ・Build native mobile apps using JavaScript and React JavascriptとReactを使って、ネイティブモバイルアプリを作ります。 ・A React Native app is a real mobile app ReactNativeアプリはリアルなモバイルアプリです。 ・Don't waste time recompiling リコンパイルにかかる時間を無駄にしません。 ・Use native code when you need to 必要であればネイティブコードを使ってください。 https://facebook.github.io/react-native/ (より抜粋)
20. ©NAVITIME JAPAN ReactNativeとは 20 https://facebook.github.io/react-native/showcase.html https://instagram-engineering.com/react-native-at-instagram-dd828a9a90c7 導入企業
21. ©NAVITIME JAPAN Agenda 21 ReactNativeの立ち位置…? Webなの…? ネイティブなの…? 第３勢力なの…? 今後取って変わるもの…? 主力スキルなの…? 特殊スキルなの…?
22. ©NAVITIME JAPAN ReactNativeとは 22 ・React Nativeは魔法戦士のようなイメージ。 ・魔法で戦いつつ、場合によっては剣で戦う。 ・魔法が主力武器で剣がサブ武器であれば、魔法がiOS, Android, Webなどで、剣 がReactNative。 イメージ
23. ©NAVITIME JAPAN ReactNativeとは 23 ▪ オープンソースのクロスプラットフォーム開発ツール。 ▪ DOMのような構造で要素を定義できる。 ▪ 武器の使い分け大事。 まとめ
24. ©NAVITIME JAPAN 24 導入の目的と背景
25. ©NAVITIME JAPAN 導入の目的 25 ① UI Viewの共通化を図り、開発工数を削減する。 ② AppStoreのリジェクトを回避する。 ③ 開発リソースを平準化をする。 主に、以下の3点
26. ©NAVITIME JAPAN 導入の目的 26 ① UI Viewの共通化を図り、開発工数を削減する。 ② AppStoreのリジェクトを回避する。 ③ 開発リソースを平準化をする。 主に、以下の3点
27. ©NAVITIME JAPAN 27 ・6ネイティブアプリ、2Webアプリを運用中。 ・アプリ・webに限らずリソース数の割に開発すべきプロダクトがたくさんある。 導入の背景
28. ©NAVITIME JAPAN 滋賀 北海道 白馬 導入の背景 28
29. ©NAVITIME JAPAN 白馬 滋賀 北海道 適当な画面ほしい 導入の背景 29 同じような見た目のアプリがたくさんできる。 Viewのコンポーネントを共通化し、開発工数を削減したい!
30. ©NAVITIME JAPAN 導入の目的 30 ① UI Viewの共通化を図り、開発工数を削減する。 ② AppStoreのリジェクトを回避する。 ③ 開発リソースを平準化をする。
31. ©NAVITIME JAPAN 導入の背景 31 提出します! だめや たのむ！ 受注案件だと納期の遅延に繋がるので回避したい。 AppStoreリジェクト回避 だめや Apple Storeリジェクト問題
32. ©NAVITIME JAPAN 導入の背景 32 官公庁の案件にはリジェクトは大きなリスク - 実証実験期間の厳守 - 年度末の納品 → このようなリスクを避けたい。 サーバーから実行コードを配信することで審査を回避する (MS AppCenterの機能。後ほど説明します。) AppStoreリジェクト回避
33. ©NAVITIME JAPAN 導入の目的 33 ① UI Viewの共通化を図り、開発工数を削減する。 ② AppStoreのリジェクトを回避する。 ③ 開発リソースを平準化をする。
34. ©NAVITIME JAPAN 導入の背景 34 開発リソースの平準化 限られたリソースの中で多くのアプリを大量に、短納期で各プラットフォームご とに作るにはそれなりのスキルや体力が必要になり、各プラットフォームで専門 のエンジニアを配置する必要がある。
35. ©NAVITIME JAPAN 導入の背景 35 開発リソースの平準化 コストやリソース、ビジネス環境を考慮したときに、一度の実装で複数のプラッ トフォームに爆速でアプリを提供したいという思い。 learn once, write anywhere 一度学べば、どこでも書ける。
36. ©NAVITIME JAPAN 導入の背景 36 それぞれのプラットフォームで分断されていたエンジニアをReactNativeで統合する。 Webエンジニア アプリエンジニア 開発リソースの平準化
37. ©NAVITIME JAPAN 37 ネイティブ + ReactNative ハイブリッドアプリという選択肢
38. ©NAVITIME JAPAN ハイブリッドアプリ 38 BIWAICHI Cycling Navi ReactNativeアプリ第一弾。(2018/4 リリース) ReactNativeでアプリを作る初の試み。
39. ©NAVITIME JAPAN ハイブリッドアプリ 39 開発メンバー ネイティブエンジニア いっぱい React Nativeエンジニア(Webエンジニア) 1人(私) ＿人人人＿ ＞ 1人 ＜ ￣Y^Y^Y^￣
40. ©NAVITIME JAPAN ハイブリッドアプリ 40 エリアガイド サイクリングコースガイド ナビ中周辺検索 おすすめ情報のpush通知 走行中の写真を自動撮影 走ったルート保存、シェア
41. ©NAVITIME JAPAN 41 これらを最初から全てReactNative化するか？ NO。
42. ©NAVITIME JAPAN 42 なにも実績が無い状態でいきなり全てを ReactNative化するには不安がある、、 なので、主に文字が主体となる画面など、まず は簡単な画面からReactNativeしていく方針とな る。 ハイブリッドアプリ
43. ©NAVITIME JAPAN ハイブリッドアプリ 43 ・モノによっては、やろうと思えばオールReact(JS)で開発すること は全然できます。 ・しかし、弊社の地図はまだReactNativeで動くようになっていなか ったため、地図画面はネイティブにしようという方針となり、 結果、必然的にネイティブ＋ReactNativeというハイブリッドアプリ となりました。 ネイティブで動く 地図画面
44. ©NAVITIME JAPAN 導入の背景と目的 44 まとめ ① UI Viewの共通化を図り、開発工数を削減する。 ② AppStoreのリジェクトを回避する。 ③ 開発リソースを平準化をする。
45. ©NAVITIME JAPAN 45 実装方法の紹介
46. ©NAVITIME JAPAN 実装方法(初期設定) 46 用意するもの • Node スケーラブルなネットワークアプリケーションを構築するために設計された 非同期型のイベント駆動の JavaScript 環境 • Watchman ファイル監視システム。ファイルの変更を検知し、再ビルドなどを 発火させることが可能になります。 • React Native comand line interface • Xcode • Android Studio + JDK • VSCode
47. ©NAVITIME JAPAN 実装方法(初期設定) 47 導入手順 1. Node, Watchman のインストール 2. React Native comand line interface のインストール 3. Xcode, Android Studio + JDK のインストール 4. アプリを新規作成 brew install node brew install watchman npm install -g react-native-cli react-native init AwesomeProject
48. ©NAVITIME JAPAN 実装方法(初期設定) 48 android ios ネイティブのプロジェクトはandroid,iosディレクトリに 配置される。中身はこれまでのプロジェクトと同じ構成で 分かりやすい。 JavascriptまたはTypescript js,tsなどReactNative側のファイルはsrcディレクトリ内に配 置。src下の構成はメンバー間で方針を決める。
49. ©NAVITIME JAPAN JS側からネイティブの処理を実行する場合は、Native Moduleを利用する。 実装方法(イベント呼び出し) 49 RCTBridgeModule objective-c/swift Java
50. ©NAVITIME JAPAN 実装方法(イベント呼び出し) 50 import { NativeModules } from 'react-native' const { DeviceAction } = NativeModules export class Device { public static phoneCall = (tel: string) => { DeviceAction.phoneCall(tel) } } モジュール名 ：”DeviceAction” 関数名 ：”phoneCall” 引数 ： 電話番号(テキスト) イベントの呼び出し MIT License Copyright (c) Facebook, Inc. and its affiliates.
51. ©NAVITIME JAPAN 実装方法(イベント呼び出し) 51 public class DeviceActionModule extends ReactContextBaseJavaModule { public DeviceActionModule(ReactApplicationContext reactContext) { super(reactContext); } @Override public String getName() { return "DeviceAction"; } @ReactMethod public void phoneCall(String number) { Intent intent = new Intent(Intent.ACTION_DIAL); intent.setData(Uri.parse("tel:" + number)); if (intent.resolveActivity(getReactApplicationContext().getPackageManager()) != null) { getCurrentActivity().startActivity(intent); } } } Android モジュール名、関数名がJS側と 一致している必要がある
52. ©NAVITIME JAPAN 実装方法(イベント呼び出し) 52 @objc(DeviceAction) final class DeviceAction: NSObject { @objc(phoneCall:) func phoneCall(_ number: NSString) -> Void { DispatchQueue.main.async { guard let phoneNum = URL(string: "tel://" + String(number)) else { return } UIApplication.shared.open(phoneNum) } } @objc static func requiresMainQueueSetup() -> Bool { return true } } iOS モジュール名、関数名がJS側と 一致している必要がある
53. ©NAVITIME JAPAN 53 開発を進める上で 苦労したこと
54. ©NAVITIME JAPAN 54 Webエンジニアだけだとつらい
55. ©NAVITIME JAPAN 開発の苦労 55 結果・・・ Webエンジニアだけだと辛い • 最初ReactNativeのエンジニア(もう一度言いますが、Webのエンジニア)私1人。(ネイテ ィブエンジニアいっぱいいる) • 滋賀ビワイチサイクリングアプリは、事業の開発方針が決まり、ReactNative導入の初期 段階で、本当にネイティブ＋RNアプリがうまくいくか実験的な意味もあり、ドキュメ ントを参照しながら実装を進める日々…
56. ©NAVITIME JAPAN 56 いい感じ!! 開発の苦労 ネイティブの画面 ReactNativeの画面 ポップアップ ネイティブから ReactNativeの画面に遷移 表示はできた
57. ©NAVITIME JAPAN 57 そんな簡単に終わるはずはなく
58. ©NAVITIME JAPAN 58 ネイティブ画面 お気に入り登録問題 • アプリの機能として、記事とスポットをお気に入り登録できる機能。 • 単純にお気に入りに登録するだけではなく、そのデータを元にして、ネイティブの画面でルート検索 をしたり、地図にプロットさせる必要があった。 • ということはお気に入り登録した情報はネイティブ側で管理させたほうが◯。 開発の苦労 - データ管理 - ReactNative画面 ネイティブに情報を送って保存させる
59. ©NAVITIME JAPAN 59 Bridgeの実装 Java? Objective-C? Swift? 開発の苦労 - データ管理 -
60. ©NAVITIME JAPAN 60 ・WebエンジニアがAndroid(Java)とiOS(swift)のネイティブコードを実装し始める が、そもそもJavaはまだしも、swiftは触ったこがないため1人ではうまくいかず・・・ Bridgeの実装 この部分 開発の苦労 - データ管理 -
61. ©NAVITIME JAPAN 61 ・データを受け取って保存のフローをネイティブエンジニアに実装を手伝ってもらう。 ・JSで書けると言ってもネイティブ側のコードを触らざるを得ない状況もある。 ・ハイブリッドアプリ→ ネイティブエンジニアとWebエンジニアの協力が必要。 ネイティブエンジニア Webエンジニア エンジニア同士の協力 開発の苦労 - データ管理 -
62. ©NAVITIME JAPAN 62 Navigation問題
63. ©NAVITIME JAPAN 63 ・ReactNativeでNavigationを行うサードパーティ製ライブラリがいくつかある。 ・react-navigation ☆15,080 (FB公式ページに載っている) ・react-native-navigation ☆9,922 ・native-navigation ☆3,098(Airbnb製) $ yarn install ライブラリ名 全ての画面をReactNativeで作る場合はいいかもしれないが、、 Navigationの問題 開発の苦労 - Navigation -
64. ©NAVITIME JAPAN 64 RN側とネイティブ側で別々のナビゲーションスタックは使えない。 ・1画面内に複数のナビゲーションスタックがあ る場合、戻りたい画面に戻れなくなる。 →ReactNative側のナビゲーションスタックがネイ ティブ側の画面遷移によって消滅するため Navigationの問題 開発の苦労 - Navigation -
65. ©NAVITIME JAPAN 65 画面の管理はネイティブのナビゲーションスタックに統一して対応。 • 従来の画面遷移が可能になった • ネイティブアプリと同じアニメーションで画 面遷移が可能になった • ReactNative側でナビゲーションバーの考慮を しなくて済むようになった →ノッチの考慮などをネイティブ側だけで解決 Navigationの実装 開発の苦労 - Navigation -
66. ©NAVITIME JAPAN 66 • 状態管理やコールバック処理が多く NativeModuleでブリッジするには規模が大きい →開発期間優先のため、現状は地図画面はネイティブでの実装・・・😭 TOP (React Native) リスト (React Native) 地図 (Native) 詳細 (React Native) 地図の実装 開発の苦労 - 地図 -
67. ©NAVITIME JAPAN 67 ・Webエンジニアで慣れてるといっても、正直1人だときつい…。 ・ネイティブの人にも手伝って欲しい…。 RNエンジニア1人問題 開発の苦労 - 開発リソース -
68. ©NAVITIME JAPAN 68 ・Webエンジニアで慣れてるといっても、正直1人だときつい…。 ・ネイティブの人にも手伝って欲しい…。 勉強会やるしかない! RNエンジニア1人問題 開発の苦労 - 開発リソース -
69. ©NAVITIME JAPAN 69 ・チーム内勉強会 & モブプロ会開催。 ・画面の構造の勉強 ・コンポーネントの作り方 ・レイアウトの書き方 ・2h ✕ 3回くらい ・まずは実装をやってみて分からないところは適宜聞く。 RNエンジニア1人問題 開発の苦労 - 開発リソース -
70. ©NAVITIME JAPAN 70 結果アプリを開発できるエンジニアが増えました。 各プラットフォームで一人ずつ専門のエンジニア アプリ開発エンジニアが4人に増える!! + プラットフォームの枠を超えた開発! RNエンジニア1人問題 開発の苦労 - 開発リソース -
71. ©NAVITIME JAPAN 71 良い点 ・スキル、知識を共有できる ・進捗が分かる ・タスクを分割できる、困ったら聞ける心理的安心感 RNエンジニア1人問題 開発の苦労 - 開発リソース -
72. ©NAVITIME JAPAN 72 エラー画面がつらい問題 開発の苦労 - エラー画面 - ・エラー画面の主張が激しい & 見にくいので気持ちが萎える。 ・赤いエラー画面がつらい。
73. ©NAVITIME JAPAN 73 開発の苦労 - エラー画面 -
74. ©NAVITIME JAPAN 74 エラー画面がつらい問題 開発の苦労 - エラー画面 - ・自分がなにか悪いことをしたのかという錯覚さえ覚える。 ・でもここはどうしようもないのでとりあえずスルーする。 ・つらい
75. ©NAVITIME JAPAN 75 開発の苦労 - エラー画面 - 連発するとよりつらい
76. ©NAVITIME JAPAN 76 AppCenterについて
77. ©NAVITIME JAPAN AppCenterについて 77 ・Azure上でアプリのビルド、テスターへの配布、コンテンツ配信できるMicrosoft社のサ ービス。 ・アプリからRNの画面が呼ばれると、ここから画面コンポーネントを配信する。 ・例えば、新しいコンテンツを追加したとか、デザインを修正した場合も、AppCenter上 に再ビルドすると、アプリの内部でその差分を検知して新しいコンテンツに更新する。
78. ©NAVITIME JAPAN AppCenterについて 78 Microsoft Azure AppCenterを導入 クラウド上でコンテンツをビルド/リリースして配布できるMicrosoft Azureのサービス(図1) ・官公庁アプリのリジェクトリスクを回避したい。 → 実証実験期間の厳守、年度末の納品 ・AppCenterのCodePush機能 → 実行コードをここから配信することで審査を回避。 (審査ガイドライン 2017年12月号 「4.7 HTML5 Games, Bots, etc」参照) ・当該画面のJSファイルを差し替えることで、 リアルタイムにコンテンツの更新が可能。(図2) ⇒ ストアを通さない。 ⇒ リジェクトを回避可 課題 解決法 図1. コンソール画面
79. ©NAVITIME JAPAN AppCenterについて 79 ・React Native Projectをビルドして、App Centerに配置。(①) ・アプリからReact Native のページが呼ばれたらJSを読み込む。(②) ・読み込んだファイルはアプリ内部でキャッシュ(差分があれば差し替え) (③) なのでオフラインでもページの表示は可能。 ・コンテンツに更新があれば再ビルドして、JSを差し替えればコンテンツの更新が可能。 (④) build ネイティブアプリ ① ② ③ ④
80. ©NAVITIME JAPAN AppCenterについて 80 https://github.com/Microsoft/react-native-code-push (より抜粋) 必要なライブラリはgithubで公開されているので必要に応じてnpm installする。 $ yarn add react-native-code-push (参考)
81. ©NAVITIME JAPAN 81 導入効果
82. ©NAVITIME JAPAN 導入の目的 82 ① UI Viewの共通化を図り、開発工数を削減する。 ② AppStoreのリジェクトを回避する。 ③ 開発リソースを平準化をする。 再掲
83. ©NAVITIME JAPAN UI View共通化の効果 83 パーツA パーツA’ パーツA’’ 少量の修正だけで流用できた！（ここまでは普通・・・） Viewの共通化
84. ©NAVITIME JAPAN UI View共通化の効果 84 パーツA パーツA’ パーツA’’ 少量の修正を加えて流用できる 🔻 一度の修正で２つのプラットフォーム分Viewが作れる Viewの共通化
85. ©NAVITIME JAPAN リジェクト回避効果 85 iOSアプリは様々な理由でリジェクトされる →問題解決までアプリを公開できないリスクが有る 契約やプロモーションの都合で公開予定日までに必ず公 開する必要があるケースも多々ある →リリースが遅れてしまうと謝罪案件、契約不履行、 信用損失などに繋がる 白馬アプリではReactNativeを導入したことで リジェクトの対応を迅速に行うことができた。 リジェクト回避
86. ©NAVITIME JAPAN リジェクト回避効果 86 リジェクト理由 アプリ内で表示する白馬村のWEBページにエラーが 発生していたため →改修には白馬村とWEB制作会社が対応する必要があった →公開予定日が近かったため、該当機能を口閉じし再申請 リジェクト回避
87. ©NAVITIME JAPAN リジェクト回避効果 87 アプリリジェクト 該当機能口閉じ + 再申請 WEBページ修正依頼 審査通過 WEBページ修正（自治体側） 該当機能の口開け版 JSファイルを用意 WEBページの改修確認＋AppCenterのJSファイル更新 アプリ公開 口閉じ版 口開け版 公開までの流れ
88. ©NAVITIME JAPAN 開発リソースへの効果 88 結果アプリを開発できるエンジニアが増えました。 各プラットフォームで一人ずつ専門のエンジニア アプリ開発エンジニアが4人に増える!! + プラットフォームの枠を超えた開発! 開発リソース
89. ©NAVITIME JAPAN 89 実装期間 iOS検証期間 Android検証期間 公開 ・・・ ・・・ Android検証完了 iOS審査提出 iOS公開 Android公開 集中！ツライ！ まだバグないから のんびり〜 従来の パターン 開発期間の各フェーズでリソースを効率化 それぞれ 専任 開発リソース 開発リソースへの効果
90. ©NAVITIME JAPAN 90 実装期間 iOS検証期間 Android検証期間 公開 ・・・ ・・・ Android検証完了 iOS審査提出 iOS公開 Android公開 あれ?暇だな… 集中！ツライ！ バグめっちゃ 挙がるやんけ… 集中！ツライ！ まだバグないから のんびり〜 従来の パターン それぞれ 専任 開発リソース 開発リソースへの効果 開発期間の各フェーズでリソースを効率化
91. ©NAVITIME JAPAN 91 実装期間 iOS検証期間 Android検証期間 公開 ・・・ ・・・ ・・・ Android検証完了 iOS審査提出 JS更新 iOS公開 Android公開 iOSに集中！ JSに集中！ Viewをやるぜ! RN 導入後 時々ヘルプ! new comer Androidエンジニア も開発に参戦 適宜対応 new comer 開発リソース 開発リソースへの効果 開発期間の各フェーズでリソースを効率化
92. ©NAVITIME JAPAN 92 実装期間 iOS検証期間 Android検証期間 公開 ・・・ ・・・ ・・・ Android検証完了 iOS審査提出 JS更新 iOS公開 Android公開 Androidに集中！ RN 導入後 またまた時々ヘルプ! JSに集中！ iOSエンジニアも 開発に参戦 開発リソース 開発リソースへの効果 開発期間の各フェーズでリソースを効率化
93. ©NAVITIME JAPAN その他のGood Point 93 • シンプルなUIの場合Android/iOSでほぼOS差分なく実装できる • iOSの場合UIの修正がビルド無しで更新できる • UIコンポーネントのコードだけデザイナーが作るなどの分業が可能 • エンジニアのリソースを柔軟に使えチームの強みになる → JSでできるのでWEBエンジニアがアプリ開発にジョインできる → アプリエンジニアもWEB開発への参加ハードルが下がる(React Nativeか らReact)
94. ©NAVITIME JAPAN それでもつらかった点… 94 •ドキュメントが英語(修行) •アプリビルドがかなり遅くなる(iOSのクリーンビルドは10分弱..） •ネイティブの機能を使う場合のブリッジの実装は、ネイティブの理解がないと無理 •JS学習コスト高い。一人でもわかるエンジニアがいないと無理 •地図コンポーネント系はまだ使えてない •ぶっちゃけReactNativeのサポートがいつまで続くか不安 •サードパティ製のコンポーネントに当たり外れがある。無限にあるのでどれがいいか わからない。
95. ©NAVITIME JAPAN それでもつらかった点…その他 95 https://medium.com/airbnb-engineering/react-native-at-airbnb-the-technology-dafd0b43838 (より抜粋) AirbnbがReactNativeでの開発をやめた、、 訳) ReactNativeの未熟さ ReactNativeはAndroidやiOSより未熟である。新しく、とても野心的で、急速に発展しています。一方で、ReactNativeは多 くの状況下で動きますが、その未熟さが現れ、ネイティブでの些細なことが非常に難しくなる例がある。不運にもこれら の実例を予見することは難しく、対処することに数時間から多くの日にちがかかってしまう。
96. ©NAVITIME JAPAN 96 今後こうしていきたい
97. ©NAVITIME JAPAN 今後 97 • ViewコンポーネントのGit管理 • node_modulesのライブラリ化 Reactの特徴として、Componentの再利用が可能ということが挙げられる。 そこで、Componentを一括で管理する仕組みを用意してあげて、そのComponentを色々なプロダクト で使えるようなプラットフォームにしていく。
98. ©NAVITIME JAPAN 今後 98 • Viewコンポーネント作成の分業化 React Componentはエンジニア以外の、例えばデザイナーの人でも作ることは可能。 デザイナー：コンポーネント作成→Commit ↓ エンジニア：そのコンポーネントをpullして利用。
99. ©NAVITIME JAPAN 99 まとめ
100. ©NAVITIME JAPAN こういうときに活かせる 100 • シンプルなUIのアプリの場合 シンプルなUIの場合OS差分が少なく実装が楽。 • デザインなどのアプリ更新が頻繁なアプリの場合 ReactNative部分はサーバ配信で更新できるため、アプリ審査なく市場アプリが更 新できる。(ただし、ネイティブ部分の改修には審査が必要） • 開発メンバーが少数の場合 OSに関係なくアプリの開発ができるため、ネイティブ部分の開発以外で柔軟に リソースの調整が可能。
101. ©NAVITIME JAPAN こういう時はイマイチかも 101 •ネイティブエンジニア、Webエンジニアどちらか片方しかいない場合 必ずどちらの知識も必要になる。特に最初は頼れるエンジニアが周りにいないときつい。 •UIの作り込みが必要な場合 複雑なUIはOS間で差が出ることが多く実装大変。シンプルなUIがベター。 •長期のサポートが必要なプロダクト ReactNative自体いつまでサポートが続くか心配。B to B向けや、息が長いプロダクトには向かな い可能性。 •コアコンピタンスを使ったアプリ 独自の技術を持ったアプリを開発する場合、それもReactNativeで動くように対応する必要があ る。
102. ©NAVITIME JAPAN 最後に 102 使いどころ次第では便利に使えます！ 活かせそうなプロダクトがあればぜひ導入検討してみてください！
103. ©NAVITIME JAPAN A single navigation system for every way around the world! Thank you! 103