リアルタイムで飛行機の飛んでいる状況が分かります.
Flightradar24.com - Live flight tracker!
旅客機以外もたくさん飛んでいます.
調査や救助や支援などだと思いますが,
どうか事故のないようにお願いします.
ライブラリのメソッド数などをあらかじめ確認できる「METHOD COUNT」
外部ライブラリのメソッド数 (65k問題) を確認するにはコマンドラインツールがありますが.
JesusFreke / smali — Bitbucket
それを利用した 便利なshスクリプトも Gist にありますが.
`classes.dex` method count helpers.
それを内部で利用しているかはわかりませんがそんなWEBサービスがあります.
Methods Count - Your solution for a perfectly fit APK
検索欄からパッケージ名を入力しようとするとサジェスチョンしてくれます.
依存するライブラリのメソッド数や jar/dex のサイズも各バージョン別に確認することができます.
IDE向けのプラグインもあるようです.
実際に追加・ビルドする前にライブラリを選定する目安にもなるので便利に使えます.
ソースディレクトリの構成時にもっておくべき「会社別」のイメージ
ひとつの部分を変更しようとして, 必死に複数のファイルをいったりきたりしながら更新してみると, 意図しないところが壊れている.
想像してみてください.
マネージャー会社, プログラマー会社, 人事会社, マーケティング会社がある.
プログラマー会社には, マネージャーやマーケティングや人事の人はいなくて, プログラマーしかいない.
いきなり src 直下に「activities」「fragments」「views」ディレクトリを作成してしまうことに似ていません?
「何をするか」ではなく「何であるか」でまとめられたものは, 探そうとすると何度も大きく移動しなければならない.
「会社の業種別」「会社別」のような「何をするか」を優先させたイメージでディレクトリを構成していくと以下のようになります.
良い点
- 高モジュール化.
- 見つけるのが分かりやすい.
- 高レベルな抽象化.
- 機能とレイヤー両方で分けられている
- 構成のメンテがやりやすい.
- 凝縮されている.
- スケール変更しやすい
- 関係ないクラスやファイルを変更するアクシデントが少なくなる.
- 機能の追加や削除がしやすい.
- 再利用しやすい.
Package by features, not layers — The linkedcare Engineering team — Medium
【2015-10-14 公開!!】Google I/O 2015 のソースコードに見るディレクトリ構成
ひとつの考え方として根底にあったほうがよいと思いました.
これに合わせてリソースディレクトリも小分けにできるという話は以下から.
res ディレクトリは小分けにしたほうがいいのではないか