15 min/d

ぼうずやのにっき

常識の差

前提条件をあわせるのって難しい。前提条件と書いたけど、常識ととってもいいし、経験から感覚的にやっている何かととってもいい。

たとえば、ソースコードは適切な単位で分割するのが良い。そういう価値観を前提条件として共有できているだろうか。ぼくはわざわざ言わなくてもわかると思っている。つまり、それは僕の中では常識なのだ。ぼくは lint プログラムではないので「メソッドが 5 行を越えたら分割しないといけない」のような厳密な何かを持っているわけではない。ただ経験や感覚的にこれくらいで割っておいたほうが分かりやすいなどと考えてしまう。

そういう常識が通じない相手は居る。年齢が違えば技術に触れてきた時期も変わる。家族や友人によっても変わる。才能と経験も違う。どうして常識が同じになるだろう。

だから、ぼくは考えている。

自分の常識を示していく必要があるのか。相互にそういうものを示して、ズレを減らす仕組みが要るのか。ペアプロもそうだし、コードレビューもそうかもしれない。

「関数を適切に分割して、関数の単位でテストを書くと……」そんなことをぼくがわざわざ言う必要はあるのか。本をすすめるのも良いかもしれない。良い本を探すのが面倒だけど……。

Android の <animation-list> と <rotate> でパラパラ漫画的に回転

Android<animation-list><rotate> でパラパラ漫画的にくるくる回転するアレをつくった。

res/anim/ に置いたものを AnimationUtils で読んで……とやればスムーズに回転する動作ができることは知っている。最初はそれで実装した。ただ、どうも期待している動作がそれではなかったようだ。一定時間ごとに一定角度 (45deg) ずつ回転する挙動が必要らしい。結果的に冒頭のような形となった。

<rotate> と書いているのだけど、 Java でいうところの↓のふたつのうちどちらになるのかが、よくわかっていない。RotateDrawable からは RotateAnimation を参照するように書かれているので、きっと実装としては同じものなのだろうけど。

もっと賢いやりかたがありそうなものだけど、とりあえず意図した形になったので良しとする。

ここに限らず JavaXML の関係について把握するのも良さそうだ。 layout のほうは View を継承しておくとか、決まったコンストラクタを提供しておくなどで、使えるのだろうな。

Android の Drawable Resource とたたかう / 『ドクター・ストレンジ』を観た

Android の Drawable Resource でちょっとした図形を書けないかとがんばってみたけど、自動でのサイズ変更が邪魔で厳しい。画像と組み合わせれば制御できるらしいけど……。

Drawable まわりいろいろ間違ってる気がするなあ。大量の画像を commit しているのも Vector Asset Studio で回避できそうだし、Android 5.0 以降 (API レベル 21 以上) ならそもそもベクターだけでいいような気がする。


映画『ドクター・ストレンジ』を観た。

インセプション』で観たような雰囲気の映像がたくさん出てくる。建物が波打ったりする感じの。優秀・傲慢・ときどきドジをやる(茶目っ気がある?)感じの主人公。なんとなく『アイアンマン』を思い出した。こういう人物像が定番の形としてあるのかな。

Android の ConstraintLayout は要る

FrameLayoutLinearLayout でなんとかなる」 そう書いた 2017-05-22 のは嘘だった。完全に嘘ではないが、わりと嘘だ。なんとかなるが、つらい場面もある。

たとえば、縦横比を維持したまま拡大縮小した画像を中央配置しつつ、その上に指定の割合の位置で何かを配置するような……。気合を入れて Java 側で割合を計算していたのだけど、さすがにおかしいだろうと思って調べたら ConstraintLayout で簡単にできた。

明らかに難しいから食わず嫌いしていた Android Studio で Activity を作成した際のデフォルトレイアウトであるところの ConstraintLayout 。そこに意図せず戻ってきた。縦横比の維持や割合での配置は ConstraintLayout を使えば簡単だった。

Dialog -> PopupWindow

AndroidDialog だと画面いっぱいに表示できなくて PopupWindow に変えた。 PopupWindow に変えたら、 FragmentPagerAdapter が動かないので PageAdapter を使うように変えた。結果として FragmentView に変えた。こういうのつらい。

ActivityFragmentView の違いがよく分かっていない。なぜ View じゃダメなんだろう。元気が出たら調べる。

2017-W23 ふりかえり

2017-W23 をふりかえる。

2017-06 の目標

  • bbna あるいは別の Android アプリに知見を活かす
  • Haskell / Rust を日常に取り込んでいく

Android 。 bbna は Repository & UseCase を導入しようとしている。また別で書く。

Haskell / Rust 。今週は進捗なし。

2017-W23 の目標 とその記事

こまごまとした気づきを書いている。 Android のテスタビリティのために MVP や Dagger 2 (DI) を調べていた。まだ書いていないが、上位の The Clean Architecture の考え方に改めて触れている。 The Clean Architecture については、また別で書く。

Timber や Android Studio の Live Templates に触れている。導入の容易さも含めて良い。

つくったもの

2017-06-05/2017-06-11

テストをすこし増やしたくらい。別ブランチでやっている Repository & UseCase の導入を進めているが、まだ適用されていない。

その他

忙しい。今週も土曜日に出勤。休日出勤も何週目だろう……。まだまだ続く。

髪を切った (2017-06-06) 。気まぐれに切っている。もうすこし定期的に切れないかな。奇数週の水曜日に切る、とか。伸びて邪魔になってから切るという後手な感じが嫌いだ。

アサシン クリード』を観た (2017-06-10) 。アサシンクリードをクリアしたい気持ちがある。ゲームする時間があるかは別として。

Android 関連の記事。ひとつの記事にひとつの情報にまとめることができないか。また記事の質を上げることができないか。 StackOverflow に書いて、その URL を貼って補足を書くほうが良いのではないか。ハマった点をメモしておくのがまず大切か。

2017-W24 の目標

  • Android アプリ開発でハマった点を書く
  • The Clean Architecture について書く
  • bbna への Repository & UseCase の導入について書く

POJO / 映画『アサシン クリード』

仕事。 Android アプリも半分ほどできてきたような……。

ところどころで marker interface を使っている。 data A = B | C 的なことがやりたい場合の A を marker interface にしている。 marker interface ではなく abstract class にすることもある。

どちらにせよダウンキャストがつらい。 if (a instanceof B) { /* ... */ }B b = (B) a; するのが。 Kotlin は TypeScript のような文脈での型推論をしてくれるんだっけ。少なくとも null まわりはしてくれるらしいね。

冗長ではあるけど、 typeenum でつくっておくこともある。type に文字列や数値のキーを割り当てる場合に都合が良い。 API のレスポンスに type 列があって……とか普通にある。 type-safe を気にしないなら String で保持して String 定数クラスのフィールドと比較して……とかになるのかな。つまらない間違いはコンパイルエラーになってほしいので、 enum と併用してガリガリやる。

文章で説明すると分かりにくいので、コードで説明すると↓のような形。

enum AType { B, C }

abstract class A {
  private final AType type;
  protected A(AType type) { this.type = type; }
  AType getType() { return this.type; }
}

final class B<T> extends A {
  private final T value;
  B(T value) { this.value = value; }
  T getValue() { return this.value }
}

final class C extends A {
  C() {}
}

だいたい↑っぽい形に落ち着くことが多いのだけど、ここまで進めるのがわりとだるい。 Java かそれを使うぼくとの組み合わせが悪い。

書いていないけど Optional を自作した。 Android では API level 24 以降で使用できる のだけど、 API level 24 って Android 7.0 (N) なので……。どう考えてもとうぶんは使えない。

serialize (Parcelable) まわりで NullPointerException がでてしまって、テストしなきゃ……という気持ちになっている。 Parcelable をテストするためには Android 上でテストを動かす Instrumented Unit Test にしないといけなくてつらい。 android.os.Parcel not mocked が出る。

最初はデータとして扱うクラスをそのまま Parcelable にしていたけど、↑のような Android 依存に気持ち悪さがあったので、 Parcelable 用にクラスを分離した。たとえば UserParcelableUser にして、それを Parcel にする。 シリアライザー的な。

class User {
  private final String name;
  User(String name) { this.name; }
  String getName() { return this.name; }
}

class ParcelableUser implement Parcelable {
  ParcelableUser(User user) { this.user = user; }
  User toUser() { return this.user; }
  /* ParcelableUser(Parcel in) ほか Parcelable としてのメソッド ... */
}

なんだろう。 Java の持つ冗長さと、ぼくの持つ冗長でもいいからきれいにしたい感じが相まって悪い結果をもたらしているような……。


映画『アサシン クリード』を観た。 Google Play で購入。 Paypal が 200 円引きクーポンを配っていたのをきっかけに。 500 円から 200 円引きで 300 円って値引いても別に安くないけど、絶対的に高いわけじゃないので気にしない。

ゲームの『アサシン クリード』は持っているのだけど、すっかり忘れている。そもそも確かクリアしてないはず。パルクール駆使しつつ、かっこつけて移動する、おつかいゲーなイメージ。 2017-04-04 にも似たようなことを書いている。そのくせクリアしていないはず。

動きの再現度は高そう。確かにこんな動きだった。まあ、はっきり覚えてないんだけど。……ていうかこんなごついアームの装置だっけ、アニムス。 Portal の GLaDOS を連想させる。カッコいいけど、場所も食うし、金がかかりそうなデザインだな。でもまあ映画は絵にならないといけないもんな……。

いかにも続編をつくれる感じの終わりかただった。