過去に複数人がコードの修正を行ったとき
git blame class path を用いれば効率よく犯人探しができるので良き。
まあいつも大体犯人側なんですがね…
android 汎用密度に対応した画像の追加の方法
結構初歩的だと思われるのだが、私は数時間つまづいたので書いとく。
android端末ではある程度dp解像度が絞れるので(mhdpiとかxxxhdpiとか....)、それに合わせた画像を用意すれば、どの端末にも同程度の解像度の画像が表示できる。
今回の業務の場合は、画像はすでにデザイナーさんに用意していただいていたので、
あとは画像を追加するだけだった。
しかししかし、今回やった方法は違う。
finderでそれぞれのdp解像度に対応した画像用のフォルダーを作り、
そこに一枚一枚入れて行くと、drawableフォルダの中に
まとまって作成されるので、画像をセットする時にフォルダ名を指定すれば、
端末に対応した画像が表示される。
! は使わず .not()を使った方がスマート
普通に
if (!name == null){,,,,,}とかやっていたが、
.not()というのがあるらしく、それを使った方がスマートらしい。
◯
val isFavorite = true
if (isFanvorite.not()) {......}
私にはここのコードがスマートでない、とか、
ここはこれで書いた方がいいみたいな
リファクタリングの考えがまだ染み付いていないので、
ただでさえ夫妻の溜まったコードなのに、そこに負債を重ねてしまうので
早急にリファクタリング能力欲しくなっている。
以下、参考にしたページ
not - Kotlin Programming Language
型推論に関して
私はいつも明示的に型を指定していたが、本当はしない方がいいとわかった。
理由は、基本的に1 つなのだが、細かくすると2つになる。
言語仕様が変更になった時に手間
プログラミング言語の仕様は素早く変化する。
型の仕様が変更になった時に、明示的に型を指定していた場合、
その型が動かなくなることもあるし、変更する手間も増える。
型推論を指定れば自動で切り替わる（はず）なので、
基本的に型推論を使用すべき。
◯ val name = "sanae"
× val name: String? = "sanae"
変数の中身が変わった時
無論なのだが、中身が変わることはよくあることなので、
明示的に型を指定すると変更する手間が増えるのでやらない方がいい。
◯ val name = "sanae"
✖️val name: String = "sanae"
name = null←こんなことないやろ笑
忘れてはいけない勉強法
1. 検索練習
2. 交互練習
3. 多様練習
4. 分散学習
5. 精緻化
電車の中で毎日、立ったり座ったりあるきながら、いろんなものと関連付けて、自分の言葉で置き換えて、意図的に思い出しながらメモリの話とか見てる。
忘れてもいいようにメモ。
android actionbar toolbar
デフォで影のつくactionbarとつかないtoolbar
dependencies { compile 'com.android.support:appcompat-v7:21.0.+'}
ツールバーを作りたいならアクションバーを消す必要があるそう。themeでnoactionbarを使う。 あと、onCreateで必ずsetActionBarする。
以下、参考にしたサイト
