Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

Androidのプロダクトにguavaを入れたくない

雑に考えをまとめるので間違いがあったら教えてほしい。むしろguava入れたら最高だったけど?みたいな話があったら聞きたい。

guavaの何が嫌かといえば、一言で言えばその大きさである。便利そうなものがガッツリたっぷり入っている。まぁ実際便利だし、使いたいクラスもある。けどそれ以上にデメリットが大きいと感じてしまう。

デメリットの1つはアプリ自体のサイズの増加。メソッド数はproguardで削減できるとはいえ、ビルドの時間には影響するだろうなぁ嫌だなぁと感じてしまう。

もう1つはロックインの問題。guavaを導入したい理由はいろいろあると思うけれど、たぶんguavaのほんの一部の機能を使いたいだけってのがほとんどだと思う。自分は、それだけのためにguava入れて大丈夫?最初は軽い気持ちだったんです…みたいなことにならない?と不安に感じてしまう。

特にチームで開発する場合、guavaのような便利でマッチョなライブラリを入れてしまうと各人のコードにブレが生じがちだ。ある人はguava最高じゃんどんどん使うぞという思考で開発してくるかもしれないし、またある人はguavaはこの機能だけ使おうなみたいな認識でいるかもしれない。もちろんコード規約やチーム内の認識あわせで工夫できる部分ではあるけれど、意外と苦労する部分だったりする。そしてそういうブレのあるコードが一度マージされると、それを皮切りにしてどんどん統一感がなくなっていくこともある。

これはguavaに限った話ではなくて、ライブラリをどう選定するかという指針の話かもしれない。自分は何でもできるマッチョなライブラリは敬遠する傾向にある。用法用量を守って正しくお使いくださいという話ではあるのだけれど、経験上そういう指針を維持していくのはわりとコストがかかると感じている。便利なものを見つけたら喜んで使ってしまうのは人の常なのである。ライブラリは提示した課題をスマートに解決してるものがいい。余談だが、最近のButterKnifeはわりと太ってきたと感じることもある。

guava入れるなら、まずは何を解決したいのかを明確にしたい。そしてそれはguavaじゃないといけないのかをよく考えたい。正直、guavaじゃなくても自作できることが多いんじゃないかと思っているし、あるいはguavaの一部機能だけを切り出したライト版もいくつかあるので検討してもいいかもしれない。

余程の理由がない限り、guavaをプロダクトに導入したくない。

Google I/Oで発表されたConstraintLayoutで感じたこと

Google I/Oで発表されたConstraintLayoutはわりと衝撃だったので感じたことを雑にまとめておこうと思う。

ConstraintLayoutはより簡単にレイアウトを組むために登場した新しいViewGroupという理解である。詳細は、圧倒的当事者意識によって書かれた以下の記事にまとまっている。

qiita.com

tech.recruit-mp.co.jp

ConstraintLayoutは、UI Builderを使ってGUIで簡単にレイアウトを組むことができる。簡単に、というと少し語弊があるかもしれない。正確に言えば、「簡単にレイアウトを組むことができるようになるかもしれない」という可能性を秘めたレイアウト。今はまだツールも少しバギーらしいが、これからの進化に期待という感じ。

もしConstraintLayoutが進化していくとしたら、Viewの作り方が従来とはガラリと変わるのではないかと思っている。というのも、ConstraintLayoutのxmlのattributesを見てみると、これは人間の手で修正するものではないなと感じたからだ。~absoluteX、~absoluteYのようなやばそうな属性もあるし、位置関係を表すconstraintLeft~などの属性もRelativeLayoutよりも複雑な印象。

まず感じたのは、細かいところ修正したいときにxml修正するのしんどそうだなという不安だった。俺たちはいつまでxmlを書かなきゃいけないんだよと思う一方で、Viewを思った通りに作れるGUIインターフェースは信じきれていないのだ。これはswingのGUIを作るときにプレビューと実物がだいぶ違ったりと裏切られてきた経験によるところが大きい。Android StudioのUI Builderを信じて使ってみるべきなのかまだ判断がつかない。

ConstraintLayoutをUI Builderで作ることの売りとして、自動的にネストの少ないxmlを生成してくれるというパフォーマンス上のメリットが挙げられている。自分はこれがあんまりピンときていない。そもそもネストによるViewの描画速度はそんなに神経質にならなければいけないほど大きいものではないと思っているからだ。もちろん、RecyclerViewのアイテムなどの繰り返し箇所や、アニメーションが絡むところは意識する必要がある。しかし、I/Oの例に挙げられたようなViewでは気にしなくてもいいんじゃないの?というのが正直な感想である。

やはりConstraintLayoutの価値というのは、GUIで簡単にレイアウトを組むことができるようになるかもしれないというところにあると思う。今後ConstraintLayoutが主流になっていくことを考えて、UI Builderと仲良くなって何かあればフィードバックを送るのがいいかもしれない。

Viewの表示、非表示の切り替えや画面の回転など細かい部分を考えると、RelativeLayoutやLinearLayoutの方が楽なこともありそうだが、まずはConstraintLayout + UI Builderでできることを把握してデザイナーさんに共有することで、逆に無理をしないViewを作るように心がけるのもありかもなぁと思った。

あと個人的に気になったのは、ConstraintLayoutのattributesの名前が~Start、~Endではなく~Left、~Rightだったことだ。あれ…?RTLは…?と思ったが、これは何かしら仕組みが用意されていると信じたい。

以上!

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

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