ナカザンドットネット

Android Developer's memo

Android Studioを立ち上げるのが億劫になってコマンドラインだけで済ませたAndroid出身React Nativeエンジニアの指の動き

AndroidエミュレータでRN製アプリのデバッグをしようと思ったのですが、なんとなくAndroid Studioを立ち上げてエミュレータを起動してRunボタンを押すのが億劫になってしまい、指の赴くままにコマンドラインからアプリを起動してみました。

何も考えないで指を動かしただけなので、もっと良い方法があるかとは思います。読んでもよく分からなかった人は真似せずAndroid Studioを起動してください。

エミュレータを立ち上げる

エミュレータの作成はAndroid Studioを通したほうが楽ですが、作成済みのエミュレータはコマンドラインからでも起動できます。

$ $ANDROID_HOME/tools/emulator -list-avds # 作成済みのエミュレータ一覧を出す
Nexus_5X_API_26
Pixel_API_24
Pixel_C_API_25
$ $ANDROID_HOME/tools/emulator @Pixel_C_API_25 # エミュレータを指定して起動する
emulator: emulator window was out of view and was recentered

emulator: ### WARNING: /etc/localtime does not point to /usr/share/zoneinfo/, can't determine zoneinfo timezone name
emulator: ### WARNING: /etc/localtime does not point to /usr/share/zoneinfo/, can't determine zoneinfo timezone name

本来は $ANDROID_HOME/tools にはPATHを通してあるので、ただ emulator と打つだけでも起動できますが、説明のために冗長にしてあります。

これでエミュレータの起動を待ちます。

bundlerをスタートしておく

最終的には react-native run-android を使うので、そのときに一緒にbundlerを立ち上げてもらえるのですが、諸々の事情でyarn startに単純なstart以外にも処理を仕込んである場合などがあると思います。うちの場合はキャッシュに悩まされてつらかったことがあったので --reset-cache を必ず付けるようにしてたりします。

そんな事情から、 run-android とは別にbundlerを実行しています。ターミナルのタブをひとつ占有させてあげる感じですね。

$ yarn start
yarn run v1.5.1
$ node node_modules/react-native/local-cli/cli.js start --reset-cache
Scanning folders for symlinks in /path/to/rnapp/node_modules (51ms)
 ┌────────────────────────────────────────────────────────────────────────────┐
 │  Running Metro Bundler on port 8081.                                       │
 │                                                                            │
 │  Keep Metro Bundler running while developing on any JS projects. Feel      │
 │  free to close this tab and run your own Metro Bundler  instance if you    │
 │  prefer.                                                                   │
 │                                                                            │
 │  https://github.com/facebook/react-native                                  │
 │                                                                            │
 └────────────────────────────────────────────────────────────────────────────┘
Looking for JS files in
   /path/to/rnapp


Metro Bundler ready.

Loading dependency graph, done.

エミュレータのデバイス名を確認してrun-androidする

エミュレータとbundlerの準備ができたら、あとはアプリを起動するだけです。

react-native run-android にdeviceIdオプションを付けると、インストール先の実機やエミュレータを指定できるので、先程起動したエミュレータのdeviceIdを調べるところから始めます。

$ $ANDROID_HOME/platform-tools/adb devices # エミュレータや実機のdeviceIdを調べる
List of devices attached
emulator-5554   device # これがエミュレータのdeviceId
$ npx react-native-cli run-android --deviceId emulator-5554 # Androidでアプリを起動する
npx: 41個のパッケージを4.999秒でインストールしました。
Scanning folders for symlinks in /Users/y.nakagawa/dev/an-lite-app/packages/app/node_modules (46ms)
JS server already running.
Building the app...

adbでdeviceIdを調べると、大抵はemulartor-5554が出てきます。面倒であれば調べずに決め打ちでemulator-5554を指定してもいいのかもしれません(というかよくやります)。

コマンドが react-native run-android ではなく npx react-native-cli run-android は特に意識の高い話ではなくかなりズボラな話で、何だか面倒になってreact-native-cliをグローバルにもdevDependenciesにもインストールしなくなった*1ので、このときだけ使えればいいやというモチベーションで使っています。この方法の問題として、yarn startとrun-androidで使っているcliの実装が違っているけどいいの?という話はあって、いつか痛い目を見そうな気はしています。

まとめ

Android SDKのemulatorやadbといったコマンドの動きが指に染み付いている人間はこういう変な起動の仕方をすることがありますが、こんなことを新しく覚えるために学習コストを払うくらいなら素直にAndroid Studioを立ち上げたほうが賢明だと思うので、どうしてもやってみたい方以外は真似するのはオススメしません。

*1:たまにしか使わないし・・・

React NativeをWebに持ってくることの意味

React Native for Webは、React NativeをWebに持ち込む試みです。

しばしば、こういった試みに対して「わけがわからない」「本末転倒である」といった意見を見かけますが、筆者は妥当な試みであるという印象を持っています。ちょっと頭の中にあるものを出してみようと思います。

ブラウザはGUIアプリケーションプラットフォームではない

まず前提となっている思想として、 WebブラウザはGUIアプリケーションプラットフォームではない 、というものがあります。ブラウザは元々ドキュメントビューアであり、Webページで情報を閲覧するためのソフトウェアであり、アプリケーションのランタイムではなかった、という立場です。

HTMLもCSSもJS(vanilla jsね)も、綺麗でセマンティックでインタラクティブなWebサイトを作るための進化を遂げましたが、元々がドキュメントビューアなので、アプリを動かすためのフレームワークとしては無理が残ります。

巨大な配列データのリストを省メモリで表示できる仕組み、ユーザーの言語や地域の設定に合わせて自動で表示言語を切り替える機能など、AndroidやiOSであれば当然持っている機能はブラウザには搭載されていません。ダウンロード処理や非同期処理を伴うならばぜひ使いたいプログレスバーも、インジケータ(ぐるぐる)も、標準では搭載されていません。

ブラウザで同じようなことをしたいと思ったら、人気っぽいJavaScriptライブラリやCSSフレームワークを選定し、導入する必要があります。これは「ドキュメントビューアを頑張ってGUIアプリケーションっぽく動かすための作業」です。頑張りの大半をライブラリ製作者が担ってくれているために実感しづらいですが、筆者はそう思っています。

これはブラウザがGUIアプリケーションプラットフォームとして劣っているという話をしたいのではなく、そもそもドキュメントビューアなので、GUIアプリケーションが作りづらいのは自然なことである、という話です。divもspanもul/liも、それらを装飾するCSSも、GUIのレイアウトを組むことに特化した作りをしているわけではないのです。

Flexboxについて

ちょっと主張がブレるように思われるかもしれませんが、Flexboxはアプリ開発に向いているなあ、と思っています。Webサイトを作っていく上でも役立つので、別にアプリ開発のために作られた機能というわけでもないと思うのですが、AndroidのLinearLayoutやiOSのStackViewなど、類似の機能がアプリ開発の現場では欠かせない状況になっているので、これが登場したときには本当に嬉しかった・・・

React DOMはGUIアプリケーションフレームワークではない

ブラウザそのものがGUIアプリケーションプラットフォームでないのであれば、何らかのフレームワークを噛ませることで、ある程度GUIアプリケーションを作りやすくなりそうですよね。筆者はしばらくの間、「React DOMを使ったらブラウザをGUIアプリケーションプラットフォームであるかのように扱える」と思っていました。

さて、現実を見てみましょう。

Reactは、DOMをいくらかの単位で切り分け、コンポーネントとして扱わせてくれます。Reactは、データの更新に対するDOMの更新を最低限に抑えてくれます。Reactのおかげで、複雑なインタラクションを最低限のコストで管理できるようになりました。

これで、どんな複雑なWebサイトでも構築できます!

…………………………

……………………

…………

……やっぱりGUIアプリケーションのフレームワークという感じではないぞ……?

「ドキュメントビューアを頑張ってGUIアプリケーションっぽく動かす」ためのコストを下げてくれる存在であることは間違いないのですが、レイアウトを組むために必要な頑張りの方向性は、楽になっただけで(これはこれでもちろん重要なんですが)、あまり変わっていません。

React NativeはGUIアプリケーションプラットフォームの抽象である

AndroidやiOSはGUIアプリケーションプラットフォームです。React Nativeは両者の上でGUIアプリケーションを構築させるためのツールを用意するにあたり、AndroidやiOSにあったものを共通化する形で「GUIアプリケーションを作るなら大抵こういうのが必要でしょ」というコンポーネント群やモジュール群を用意しました。

特にコンポーネント群には嬉しいものが多いです。基本となるViewText以外にも、ぐるぐるを出してくれるActivityIndicatorや、巨大な配列データを省メモリでリスト表示できるFlatList、挟めばスクロールさせてくれるScrollView、進捗を表示するProgressBar/ProgressView、引っ張って更新のRefreshControlなど、 「無きゃ無いでどこかから調達してくるなり自作なりするけど、あるなら嬉しい」 が揃っています。もちろん足りないものもあるので自作することもありますが、GUIアプリケーションを構築していくにあたっての最低限のベースとしては充実していると思います。

この抽象はAndroid/iOSをベースに生み出されたので、AndroidとiOSでしか有効でないものと思われがちですが、実際にはプラットフォームを限定しない抽象化を行っているため、react-native-windowsreact-native-macosといった、他のプラットフォームの抽象化にも成功しています。

React Nativeは「あらゆるGUIアプリケーションプラットフォームを抽象化するフレームワークである」と言えるのではないかとすら、筆者は感じています。

React Native for Webがブラウザに持ち込んだもの

Webブラウザ上でGUIアプリケーションを構築しようとした場合にも、React Nativeの「GUIアプリケーションを作るなら大抵こういうのが必要でしょ」というコンポーネントのラインナップは、やはり有効です。

React Native for Webは、ネイティブアプリをブラウザ上で再現しようとしたものではありません。React Nativeが提唱したGUIの抽象化を、Webアプリケーションの世界でも使えるようにした、ブラウザ向けのReactコンポーネント&便利モジュール集ライブラリです。

React Native本家のテクノロジスタックとは異なり、次の図のような構成になっています。

f:id:Nkzn:20180529203426p:plain

たまたまReact Nativeと似たようなラインナップのコンポーネントが、たまたま似たような名前のpropsを持っていて、たまたまReact Nativeと似たようなスタイルを持っている、ただそれだけです。スタイルやpropsに関する思想をReact Nativeに寄せてあるだけで、ライブラリとしてはmaterial-uiOnsen UIに近いとすらいえるでしょう。

コンポーネントが便利

というわけで、ただのブラウザ向けReactコンポーネントとしてみた場合に、どんなコンポーネントがあるかというと、

  • ぐるぐるを出してくれるActivityIndicator
  • 挟めばスクロールさせてくれるScrollView
  • 進捗を表示するProgressBar
  • 引っ張って更新のRefreshControl

こういうのが普通に使えるわけです。便利ですね。

スタイル周りも良い感じ

GUIアプリケーション、特にモバイルでの動作を意識したスタイルが最初から効いています。

例えばScrollViewには次のような特性があります。

  • 細かい設定をしなくてもScrollViewの中には慣性が効く
  • 細かい設定をしなくてもScrollViewの中身がオーバースクロールする

例えばこういうの↓を書いただけで、画像が縦にズラッと並んで、慣性スクロールも聴いて、一番下まで行ったらちょっとオーバースクロールもさせてくれるわけです。

<View>
  <ScrollView style={{flex:1}}>
    <Image />
    <Image />
    <Image />
    ...
  </ScrollView>
  <Text>画面下部に固定のテキスト</Text>
</View>

このへんはMobile Safariに苦しめられたことがあったので、地味に嬉しいです。

また、React NativeではレイアウトにFlexboxを採用しているのを踏襲して、次のような特性も持っています。

  • 常に display: flex が効いてる
  • flexDirection のデフォルト値が column (縦並び)

毎回 display: flex を書かなくていいのは完全に楽ですし、モバイル向けのアプリではアイテムを上から下に並べることが多いことから、flexDirectionを指定する機会が減るのも助かります。

TouchableOpacityでタップ表現もラクラク

TouchableOpacityは「タップイベントに応じて囲んだ内側のViewの透明度を変えるフィードバックを表現する」ためのコンポーネントです。

<TouchableOpacity onPress={() => { /* タッチイベント */}}>
  <View /> // 自作のボタンっぽいもの
</TouchableOpacity>

上記のようなコンポーネントを作った場合、内側のViewには一切タッチイベントに関する設定を行わなくても、簡単なフィードバックを実装することができます。

f:id:Nkzn:20180529200955g:plain

他にもいろいろあるけど

GUIアプリケーションを作る際に便利なあれこれが詰まっています。

React Native本家とコードの共通化、みたいな文脈もないわけではないですが、それよりも、単純にWebアプリ開発を便利にしてくれるツールだと思ったほうが気楽に試せると思います。

触ってみたくなった方向けに、create-react-app上にReact Native for Web環境を置いたボイラープレートを用意しておいたので、触ってみてください。

github.com

プロダクション事例が強すぎる

実は、PWAの事例として有名なTwitter Liteは、React Native for Webの事例でもあります。

Twitter LiteはReact Nativeによるネイティブアプリ版が存在するわけでもなく、純然たるWebアプリです。

こういった活用ができる程度には、React Native for WebはWebアプリ開発の文脈で有用なものであると筆者は考えます。

作者のnecolasも語ってた

↑から始まる一連のツイートで、React Nativeそのものやfor Webの可能性について語っています。アツいです。

まとめ

React Native for Webは、React Nativeによって抽象化された「モバイルアプリ開発の当たり前」をブラウザの世界に持ち込んでくれる存在です。

単純にWebアプリ開発の負担を軽減してくれるところもありますし、ネイティブアプリ開発の出身者が初めてWebアプリ開発に携わったときに経験しやすい「えっ、こんなことも自分で工夫しないといけないの」を、いくらか軽減してくれる効果も期待できます。

ScrollViewなどを単独で使うこともできるので、皆さんのWebアプリの一部に取り込んでみてはいかがでしょうか。

余談:React系のアプリケーションフレームワーク

Reactベースでありながらまったく別のコードベースで開発が進められているフレームワークたちを挙げてみます。

  • React Native
    • Android, iOS向けのGUIアプリケーションフレームワーク
    • ネイティブ実装部分を差し替えただけのサードパーティ実装もある
      • react-native-windows(Windows)
      • react-native-macos(macOS)
      • react-native-dom(ブラウザ)
    • この辺の話は先日の記事が詳しい
  • React Native for Web + React DOM
    • ブラウザ向けのGUIアプリケーションフレームワーク
    • React Nativeのコンポーネントを模倣している
  • React 360
    • VRアプリのためのGUIアプリケーションフレームワーク
    • React Nativeのコンポーネントを模倣している
  • Ink
    • ターミナルのためのCLIアプリケーションフレームワーク
    • 独自の生態系を構築している

はい、Inkをオチに使いたかっただけです。

<Color green>
  {this.state.i} tests passed
</Color>

f:id:Nkzn:20180529205525g:plain

完全に独自の生態系ですよ・・・この発想はなかった・・・

マッハ新書できそうだったけどやらずにちゃんと書いたという話

最近、マッハ新書ってあるじゃないですか。

nlab.itmedia.co.jp

golden-lucky.hatenablog.com

実践してる人たちのツイートをリアルタイムで眺めながら、「はー、そういうのもあるのか」くらいに思っていたのですが、期せずして自分の手元にもマッハ新書を出版できる=12時間以内で最低限の思想を表明できるチャンスが巡ってきました。

しかし、結局マッハ新書的な形で出すのではなく、多少の時間をかけてそこそこボリュームのある記事を書くことを選びました。

このあたりの心の動きは来週くらいには忘れてしまっていそうなので、エッセイとして残しておきたいと思います。

続きを読む

Web最新技術がてんこ盛りのreact-native-domから目が離せない

パリで発表されていたReact向けプロダクトがあまりにも未来に生きていて興奮したので、紹介させてください。

この記事のゴール

この記事では、React Nativeの内部実装に関する予備知識がほとんどない人が、React Nativeが元々どういうものなのかをふんわりと理解した上で、React Native DOMがどのように変態かつ未来に生きているのかを分かったつもりになってもらうことを目的とします。

想定読者

  • ReactがわかるJavaScriptエンジニア
  • JavaScriptのマルチスレッド処理の実例に興味がある方
  • WebAssemblyの実例に興味がある方
  • React Nativeのソースコードを読んでみたいけど、JavaScriptならともかくJavaやObjective-Cを読むのはちょっと・・・と尻込みしていた方

はじめに

5月17, 18日に、パリでReact Europeが開催されました。

f:id:Nkzn:20180522084612p:plain

https://www.react-europe.org/

Reactに関する様々な知見が公開されたようですし、スケジュールを見た限りではReact Nativeに関するセッションも多めなように思われました。

中でも私の目を引いたセッションは、Vincent Riemerさん(@)の "Bridging React Native Back to its Roots" でした。動画↓とスライドがそれぞれ公開されています。

www.youtube.com

このセッションは「React Native DOMというプロダクトを作ってみたので、モチベーションと設計方針の紹介、それからデモをするね」というタイプのやつでした。

github.com

字面からなんとなく想像できるかと思いますが、React Native DOMは「React Nativeコードをブラウザ上で動かすためのライブラリ」です。

このへんのユースケースに興味があって調べたことがある方は「えっ、それReact Native for Webと何が違うの?」と思われたことでしょう。はい、私もそう思いました。

ちょうど、Cheap Dive into React Nativeを書いたおかげでReact Nativeのソースを読むのにも自信がついてきたところなので、「まあどうせYet Another React Native for Webでしょ」と思いながらReact Native DOMのソースを読み始めたのです。

そしたらまんまと度肝を抜かれたので、「こりゃみんなにどれだけすごいか伝えにゃいかん」と、こんな記事を書き始めた次第です。

長文で前提条件から細かく書いているので、ひとまず概要を知りたい方はQiitaの記事へどうぞ。

react-native-dom の何がすごいのか

また、React Nativeのことはもうわかってるよ、という方は「React Native DOMはどこがReact Nativeなのか」の見出しを検索して、そこからお読みください。

続きを読む

FluxにはModelがないのではないかと思った覚書

Fluxを使い始めると「おっ、MV*に比べて頭が悪くても状態が壊れないぞ?」という感想になる人が多いと思うんだけど、その理由がふたつあるような気がしてきた。

ModelやViewModelについてはコンテキストが違う人から「それ違くない?」と言われそうな書き方になるかもだけど、思いつきを書きなぐってるだけなので勘弁してください。

1. 単方向データフローが分かりやすく、コードの複雑さの低下に寄与している

これは全くポジティブな要因。

2. FluxはMV*のModel相当の要素が図に含まれていないので考えることが減った

MV*は「Modelって書いてあるからには何かをModelと呼んでデータを突っ込まなきゃいけない」という意識が生まれやすかった(その責務分割が適切だったかは別として)と思う。

でも、FluxにはStoreとかいうViewModel*1みたいなものしかない*2と私は思っていて、MV*でModelと呼ばれていたものを定義させようとする意図は感じられません。

結果的に、Modelについて書いてないので考えるきっかけがなくなって、必要な脳内メモリの量が減った結果、「頭が悪くても〜」という感想になるのではと思いました。

文脈

文脈としてはこの辺の話から来ています。

まとめ

MV*はModel内の設計について定義していませんでしたが、FluxはModelの存在自体を私たちに押し付けてこない子なのでは、と思い始めました。Model相当のものがなくていいわけがないのですが、単方向データフローが強力すぎて、Model相当の部分があやふやでも、みんな何とかなっちゃってるんじゃないかな・・・*3

Model相当の部分を設計したFlux、業務で色々と試してみているので、どこかのタイミングで布教していきたいです。

補足をいただきました

この記事の本質を言語化し直してくれました。

nekogata.hatenablog.com

うん、StoreとVMの話は余計だったなという気持ちはあります。

おまけ

DroidKaigi 2018でベノワさんが紹介していたModel-View-Intentは限定的ながらModel相当の部分(Repositoryとか)にも言及している単方向データフローで、Fluxの単方向データフローしか見たことがなかった私にとってはかなり学びがあったので、興味があれば見てみてください。

speakerdeck.com

www.youtube.com

*1:VMを持ち出すと文脈がぼやけてしまいますが、Presentation Domain SeperationにおけるPresentationの中にいるということだけ伝わればOKです。

*2:StoreがViewModelに見えているのは僕の主観です。Modelだと主張したい方の思想を否定するものではありませんので、異論反論はご自身の主張を自分のブログか何かで展開してください。それはそれで僕も読みたい。

*3:Fat Controller相当のものがAction CreatorやReducerの中に増殖して見通しが死ぬほど悪くなったコードをたまに見かけるし書いたこともあります。

#技術書典 #技術書典4 参加してきました(電書&紙の再販情報アリ)

f:id:Nkzn:20180423164947j:plain

というわけで技術書典4に参加してきました!

経緯や意気込みは下記の通り。

blog.nkzn.info

blog.nkzn.info

ざっくりなにしてたの

実は、サークル参加とは別にスタッフやってました。朝6時に起きて、設営作業をしたり、見本誌の確認とかさせてもらってました(ここの人数が足りなくて駆り出された部分が強い)。

とはいえ11時にはリリースさせていただきまして、自分のサークルのほうに戻りました。スペースの設営やら見本誌対応やら、その後の店番をずっとしていてくれた、売り子の@には頭が上がりません。

実績どうでしたか

12時半になる前には100部が完売してました! 皆さん有り難うございました!

そしてその後来てくださった皆さん! 見通しが甘くてホントゴメンな! まさかこんなに来場者多いとは思わんかったんや! 全部晴天が悪い!*1

その後、売り切れた時のために念の為に用意していたダウンロードカードさんも100枚超が売れまして、累計210部ほどになりました。

みんな本当にありがとうございました。

Boothで電子版のダウンロード販売を開始します

はい、というわけで、各所で予告しておりました通り、電子版の販売を開始します。お値段そのまま1000円です。

echigo-ya.booth.pm

Boothで紙版の受注販売を開始します(!!)

さて、こっちが本番です。紙版の再販にチャレンジします。ちょっとお高めの1500円です。

f:id:Nkzn:20180424151805p:plain

流石にもう一度、ちゃんとした印刷所を使って100部とかするのは精神的にしんどいので、1冊からのオンデマンド印刷ができる、製本直送.comさんに印刷をお願いするつもりです。

www.seichoku.com

技術書典4の現地で再販の希望をいくつかいただいて感激したので、こういう形で用意してみました。

これから試しに1冊刷ってもらって出来栄えを見るステータスなので、注文していただいてもちょっと待っていただくかもしれませんが、気長にお待ち下さい。

価格が上がってることについては、初めての試みということでかかる費用についてのリスクを多めに見積もった結果なので、勘弁してほしい・・・!

初めてのサークル参加を終えて

サークル側で同人誌即売会に参加するのは、TechBoosterでコミケのバックヤードをやらせてもらったときに経験済みでしたが、自分がメインとなって出るのは初めてでした。

気持ちが溢れすぎて長文になりそうなので、箇条書きします。

  • 売り子はいたほうが完全に楽
  • 完売は気持ちいい
  • 完売後に来た人たちには申し訳なかった
  • 色んな知り合いが来てくれて嬉しかった(@さんと初遭遇できたのが最大の収穫)
  • 次回もXamaritansとは隣になりたい(合同でネタタペストリーぶら下げようという話をした)
  • スタッフ業もサークル参加もやったおかげで早朝から夕方まで12時間くらいずっと技術書典をやっていられたし、技術書典を今までの3倍くらい楽しめた気がする
  • 完全に人生の中でも最高クラスの1日でした

というわけで最高でした! また今回みたいな技術書典やりたいな!

次回もサークル参加して部数リベンジしたいと思いました。現場からは以上です。

*1:でも次回も晴れて欲しい

#技術書典 #技術書典4 で「Cheap Dive into React Native」を頒布します

blog.nkzn.info

というわけで、2月に予告していたReact Nativeの本ができました。

タイトルは「Cheap Dive into React Native」です。Deep Diveと名付けるのはちょっと面の皮が薄くて無理だったので、ちょっとトーンダウンしてみました。

f:id:Nkzn:20180418152917j:plain

techbookfest.org

配置

き02にいます。XamaritansPEAKSに挟まれてます。

f:id:Nkzn:20180420155037p:plain

配布形態

あれ これ
サイズ B5
ページ数 88ページ
頒布価格 1000円(おつりオペレーションを極限まで軽くしたかった)

表紙について

妻と「オライリーベースで身も蓋もない感じにしよう」と相談しているうちにこうなりました。

どこからどうみてもなかざん本です。

みんな見つけてくれよな!

モチベーション

DroidKaigi 2018ではReact NativeのAndroid向けの内部実装を調べる機会をもらいまして、かなり深いところまで読ませてもらいました。しかし、カンファレンスという枠組みでの50分という限られた時間の中では、調べたことすべてを話すことはできませんでした。

せっかく調べたので、覚えているうちに全部アウトプットしたい!というのが最初のモチベーションです。

また、ここ1年くらいで実案件にReact Nativeを使う機会が多くなってきました。弊社のチーム開発に適した形で運用していく中で、やはり様々な知見が溜まってきています。こういうのはときどきアウトプットしていかないとお腹を壊すので、いい機会として使わせてもらいました。

内容

記事の内容に合わせて、本の中身や思い出話をお話していきます。

  • 技術書典のiOS版後払いアプリ開発を支えたcreate-react-native-app
  • React Native で Android と Web の同時開発にチャレンジした話
  • WebマークアップエンジニアがRNやってみた(寄稿)
  • ReactAndroid Internals

技術書典のiOS版後払いアプリ開発を支えたcreate-react-native-app

blog.techbookfest.org

技術書典の公式後払いアプリのiOS版をcreate-react-native-appで作りました。私が!作りました!

ejectしない縛りの中で得られた、CRNA/Expoの知見を大放出します。CRNAでプロダクションリリースまで持っていった事例はあまりないはずなのでいい経験になりました。

備忘録として、ここ3週間の出来事を書いてみましょう。

日付 出来事
3/13 わかめさんから無茶振りをもらって面白そうやなと思い快諾
3/27 本業のデスマにより原稿もアプリも白紙のままここまで到達(開発開始)
4/2 リリースに向けた証明書周りの準備を開始(主に達人出版会さんに色々お願いするやつ)
4/4 なんとなく完成したのでTestFlight審査に提出
FGO第二部開幕
4/5 本審査提出
4/7 1度目のリジェクト(カメラパーミッションの指摘。本に書きました)
4/8 FGO第二部第一章クリア(感想は本のあとがきに)
4/9 そろそろフル可処分タイムで作業しなくてもいい気がしてきたので自分の本の執筆を開始
4/10 2度目のリジェクト(サインアップへの動線の指摘。本に書きました)
4/11 審査通った
4/15 パブリックリリース&公式ブログ告知&ゼロデイ障害対応(ごめん)
4/17 本書き終わった
4/18 入☆稿

……うん、よくこの状況で90ページも書いた。偉いぞ俺。*1

4/4〜8の可処分時間の使い方については思うところがないわけでもありませんが、私もFをGOしたかったし、許してくれという気持ちでいっぱいです。*2

謝辞

とはいえ、この短期間でアプリを作れたのは、僕の功績というのはかなり少なめです。

僕が手を付ける前にデータモデルの設計と通信周りのベース開発を7割くらい済ませていてくれた@さんと、素敵なAndroidアプリ版を真似させてくれた@の功績がほとんどだと思っています。自分一人でゼロから作っていたら、こんな時間では到底作れなかったと思います。ありがとうございました。

React Native で Android と Web の同時開発にチャレンジした話

React Native for WebやStorybookを使って、ネイティブとWebの同時開発にチャレンジした事例を紹介します。

qiita.com

こいつをプロダクションで使うために設計レベルで実用性を高めた話です。記事の中身は思想の話が多めになってしまったので、Qiitaと併せて読むと実践的になりそう。

WebマークアップエンジニアがRNやってみた

同僚のWebマークアップエンジニアをReact Nativeのプロジェクトに巻き込んだら結構良い感じだったので、エッセイを書いてもらいました。 RNの裾野の広がりを感じられるいい記事です。

ReactAndroid Internals

React NativeのAndroid向け実装について掘り下げた記事としては、おそらく現時点の日本で一番深くまで潜ったものになっていると思います。Androidエンジニアがこれを読むとReactAndroidがちょっとだけ読めるようになるかもしれません。

  • JavaScriptをどうやって動かしているのか
  • JavaとJavaScriptはどうやって通信しているのか
  • ReactからはReact DOMとReact Nativeがどのように見えているのか
  • どこのレイヤーの処理がどこのスレッドで動いているのか
  • requireされた画像リソースはAndroidアプリのどこに配置されるのか

こんな感じのことを書きなぐった40P超の大作です。

DroidKaigiのディレクターズ・カット版と言ったな。あれは嘘だ。

半分くらい書き直したぜ! DroidKaigiで興味を持った人が更に楽しめる内容になっていると思います。

電書版について

当日までに間に合えば、紙版のおまけに電書版も付けられればと思っています。

また、後日Boothで電書版のダウンロード販売も始めたいので、技術書典に来れなかった方はそちらをお待ち下さい。

というわけで

さあ、お祭りだ! 私は好きにした! 君たちも好きにしろ! みんな楽しもうな!

*1:実はCodeZineの連載も並行で書いてたのでもっと書いてる

*2:オマージュです。