Google I/O 2016 初日キャッチアップ所感

Google I/Oは現地には行かず日本で鬼のように寝て朝からざっとキャッチアップした。速報がたくさん出ていて圧倒的感謝というしかない。

いくつか感じたことを雑にメモしておこうと思う。

Firebase Cloud Messaging

GCMじゃなくてFirebaseでプッシュ通知を受け取れるというやつ。FacebookのParseを思い出したが、管理画面見てみたらほぼParseと同じだった。Parseといえば、GooglePlayの入っていない廉価端末や海賊版端末でもプッシュ通知を受け取ることができたところが最高だったが、Firebaseでも可能なんだろうか。海外だと水道は通ってないけどAndroid端末は持ってるみたいな人もいて、そういう人は1000円くらいで買える端末を使っていたりする。そういう端末にもプッシュ通知を届けられるのはわりとアツい。

Firebaseの他の進化

なんかFirebaseいろいろ進化してた。AnalyticsがついたりBugTrackingがついたり、Fabric要らなくなるのでは？と思ってしまった。個人的にはあまりに全部のせの仕組みは好きじゃないので、モジュールで分けてくれたりするとありがたい。Parseみたいに「もうみんな死ぬしかないじゃない！」ってなるのも嫌だし。とはいえ、I/Oのセッションを眺めてもFirebaseに力を入れている感じだし一度がっつり使ってみないとなと思った。

Instant apps

インストールしなくても検索結果からアプリが使えるという謎技術。どういう仕組みかはよくわかってないけど、バイナリを落として使うらしい。バイナリ落とすとなるとネットワークよわい環境だとどうなんだろうかと思った。どこかでアプリの実態があって、端末はシンクライアントとして動作するという方法よりはサクサク動きそうなのでいいのかもしれない。気になるのは、今までWeb版を作っていたところをInstant appsにした方がいいのかよくわからんというところ。まぁiOSも考えるとWeb版は作っといた方がいいのかもしれないが、Instant appsでアプリのインストール率を上げて継続率も高めるみたいなことを考えた場合、どう棲み分ければいいのか考えないといけない気がする。

あとInstant appsの登場で、ネイティブの立ち位置がよくわからなくなった。自分は今までWebの進化がすごすぎてこれはまたWeb回帰していくんだろうなぁとぼんやり考えていた。最近のGoogleのWebサービスや海外のECサービスなんかを触っているとわかるが、もうアプリとほとんど見分けがつかない。ブラウザさえあれば動作するWebでここまでできるならWebでええやんと思っていた。けどInstant appsでアプリをWeb側に持ってくるみたいなことになってきたので、これどうなんの？というのが正直な感想である。

Android Studio 2.2

なんかいろいろ速くなったらしい。Layout DesignerはStoryBoardみたいな感じなのかなと思ったけどまだよくわからない。自分は「考えるな、感じろ」みたいな感じでxmlだけでガーッと組むことが多くて、そのやり方に慣れてしまったのでなんともいえないところ。こういうのは、便利な機能が信頼できないと使わなくなっていく。Instant runもそうだった。しかし、使ってフィードバックしないとIDEも進化しないので、みんなで育てていこうな！みたいな心持ちでやっていきたい。

---

まとめをざっと見て感じた印象でしかないので、間違いもあるかもしれない。

ちなみにAndroid Nはニッキ飴がいいと思います。赤坂からは以上です。

設計とアプリの規模の話

設計はアプリの規模が大きくならないかぎりは変に意識する必要がないのでは？という意見についてはその通りだと思う。面倒なのは、アプリの規模とはなんなのか、大きな規模とはどのレベルなのかという認識が人によって認識が違うところで、そこを合わせないかぎり議論は食い違ってしまうことが多い。

例えばHello WorldのアプリでModelを意識する必要はない。Hello Worldの文字を自由に変えられるようにするアプリだとしても同様である。では、一覧と詳細だけのあるアプリではどうなのか？自分の考えでは、特に必要ではない。たしかにAndroid独特のめんどくささはあるが、1つの一覧、詳細の表示だけであれば、ゴリゴリ書いてもさして問題にならないからだ。むしろ逆にその方が開発のスピードは上がる。

DroidKaigiの公式アプリはどうか。あれは逆に面倒な設計はない方がいいと思っている。ガッツリと癖のある設計を入れると、初見で理解するハードルは上がるからだ。

書いていて思ったが、たぶん設計という言葉自体に対するイメージが人によって異なるのが問題なのかもしれない。自分のイメージはたぶんただのクラスやパッケージ構造の話にすぎない。アプリ開発において3回以上発生しそうな実装をどう書くべきかというルールを決めることで、実装時に余計なことを考えなくて済む。そうして実装のスピードを上げていく。どこにロジックを書くべきか、命名はどうするべきかといったことに頭を使うのはなるべく避けたい。

アプリ開発では、正直そこまで複雑なことをすることはない。複雑だと感じるとすれば、それはフレームワークの独特さに対する学習コストが高すぎるというだけだと思う。アプリの規模がサンプルアプリレベルの小ささであれば設計など意識しない方が早い。

規模というとエンジニアの人数を思い浮かべることもあると思うが、1人で開発していれば設計は要らないというのは違うと思う。あくまで自分の指針はアプリ開発独特のめんどくささを考えなくて済むためにはどうすればいいかという話なので、1人で開発していてもアプリが複雑なのであれば必要だ。そして大概の場合アプリは自分にとって複雑になる。

設計はアプリの規模が小さければ要らないとは言っても、規模や複雑さはほとんどの場合において閾値を超えてくるので最初から設計を意識しておいた方がいいと思う。

Androidでよくあるめんどくささ

最近Androidを楽に開発するためにはどういうクラス構造にすればいいかを考えている。

巷にはMVP、MVVM、MVC、FLUXなど様々な設計が溢れているが、サンプルコードを見てもなかなかイメージがつきにくい。理由はサンプルが簡単すぎるからだ。シンプルなTODOアプリではメリットよりコード量の増加や見通しの悪さといったデメリットの方が目についてしまい、どうしても『なぜ』その設計や構造が必要なのかを理解しにくい。理解できても1週間後には忘れている。

Android開発においてなぜ設計が議論されるかと立ち返ってみると、考えることを少しでも減らしたいからだと言える。わかりやすいところで言えば、複雑なライフサイクル、画面回転を考慮したデータのロードにエラーハンドリング、その状態に応じた画面表示あたり。Androidの開発をする上で、考慮しなければいけない事象はバージョンアップのたびに増しており、それをいちいち個々人で考えていては開発のスピードも品質も落ちてしまう。

設計は、それら多くの考えなければならないことを減らすためにある。指針を決めてそれに沿って開発することで、イニシャルコストは増えるがその後はあまり考えなくて済む。interfaceやパッケージスコープなどJavaの言語仕様で実装を強制することでミスを減らすこともできる。

逆に言えば、Android開発の現場において何が面倒くさいかを吐き出しておけば、その設計で何が楽になるのかがイメージしやすい。単純なTODOでは役不足。どんなケースがあるのか雑にメモしておこうと思う。

1. 一覧のロード中に画面の向きが変更された時にそのままロードと表示させたい。
2. 一覧のロード中に画面が閉じられた時にロードを中止したい。
3. 一覧でいいねを押してからタップして詳細を開いた。
4. 一覧でロードエラーが発生した時にリトライしたい。
5. オフライン状態で一覧画面を開いた。
6. 一覧のデータが0件の時は大きなレクタングル広告を表示、1件以上の時はフッタにバナー広告を表示したい。
7. 一覧の上部に特集一覧を表示する時、2つのロードをいい感じにしたい。
8. 一覧の2つ目と8つ目にネイティブ広告を表示したい。表示の速度も考慮してプリロードもしておきたい。
9. メッセージ画面でメッセージを送信する時、リクエストが成功する前に画面に表示させたい。
10. メッセージ画面でメッセージを送信失敗した時、リトライしたい。
11. 低ネットワーク環境下では低画質の画像を表示したい。
12. wi-fiにつないでいる場合のみ、プリロードして表示を高速化したい。

たぶんもっといっぱいあるけどこのへんで。

雑に思考をまとめたい

もう一つのブログの方は、雑に思考整理するために1年くらい前に始めたのだけれど、最近雑なことを書きにくくなってきた。読む人が多くなってきたのが原因で、その分突っ込みどころに注意しないとものすごく批判を受けるからだ。内容によっては、どんなに伝え方に気をつけても批判は受ける。これはもう仕方ない。ただ、そのせいで雑にものを書けないと思考を整理する機会がなくなってあんまりよくない。

そこで、もう一つ雑に書くための場所を作っておくことにした。これは本当に雑で、15分以内で書くことをルールにしている。見直しもあんまりしない。雑なので、間違いもあるし誤解も招くとは思う。もし見るなら、期待値をできるだけ下げて適当に読み流してほしいくらいである。そして変に細かいところで突っ込みしないで優しく接してほしい。いろんなところに気を遣って文章を書くのは疲れた。

ある程度まとまったらもう一つのブログの方にまとめるかもしれない。まとめないかもしれない。雑最高。