「継続的デリバリーが行える環境/仕組み作り」 「マルチスレッドでの疑似サーバの実装完了」
「継続的デリバリーが行える環境/仕組み作り」
-
ReactNative
-
メリット
- Viewのコードを、iOSエンジニア以外にも触れるよう敷居を下げられる
- ネイティヴコードによるビューオブジェクトの依存関係を考えるよりも、Reactのコンポーネントの作り方/Javascriptによる記述は簡単
- Android展開のスタートラインが早くなるかもしれない
-
デメリット
- ネイティブ開発のレールからは逸れる(かもしれない)
- 既存ネイティブ資産との連携
- ReactNative開発コミュニティが以前活発で、全然枯れてないことによって、保守コストが増える可能性
-
-
WebView内に展開するindex.htmlのビルド
- 最新版のAnswerReactを取得するような仕組み作り
-
CreativeServey.comのSurvey周りのデータスキーマをクライアントアプリと連携させる
- サーバのデータスキーマ変更によってクライアントアプリの提供価値が著しく下がらないようにする
「マルチスレッドでの疑似サーバの実装完了」
- APIサーバの挙動をオフラインでも提供する
- ルーティング
- アクションハンドラ
ビューやその他のロジックと結合しない、独立した実装
-
Realmを用いてのクライアントサイドでのデータストアの実現
-
タイプセーフなコードの実現
- SwiftのGenerics, Optional, Promiseを用いて実装する
- ProductionのためのSwiftTipsを貯める
-
マルチスレッドでの実装
- パフォーマンス
- 設計上の理解をもっと深める
-
疑似サーバの検証コードの実装
- ReactNative内でのWebViewから任意のURLパスを指定すると、Swiftでのバックエンド実装の任意の関数オブジェクトが別スレッドで実行され、WebView内にJsonのレスポンスが返ってくる。
- Requestにパラメータが付随する場合も正しくハンドリングできる
- Routeを定義したYamlまたは、route.rbをパースしてroutingを疑似サーバ内でregister
-
デリバリーのためのプロジェクト設定
- ReactNativeをViewとして採用するかどうかの意思決定を行う
- そのために検証プロジェクトのデリバリー環境をきちんと整備
- ReactNativeにロックインされる問題、メリットデメリットの精査
- そのために検証プロジェクトのデリバリー環境をきちんと整備
- ReactNativeをViewとして採用するかどうかの意思決定を行う
-
疑似サーバの検証コードの実装
- Requestにパラメータが付随する場合も正しくハンドリングできる
- Routeを定義したYamlまたは、route.rbをパースしてroutingを疑似サーバ内でregister
-
Realm導入
- APIを理解し、正しくCRUDできる