RxJava2.0の基本クラスを学ぶ
今さらですがRxJava2.0について学びたいと思います。
RxJava2.0ではObservableに似たクラスとしてFlowable, Maybeが追加されています。
今回は復習の意味も込めて、Observable, Single, Completable, Maybeの違いについて調べてみたいと思います。
Flowableはだいぶ特殊でObservableで扱うストリームでバッファを考慮するとき等に使うようで、（自分にとっては）現状あまり用途がないので割愛します。
Observable
0~N個のオブジェクトの流れ、完了、エラーを扱います。
プログラム
Observable.range(1, 10) .subscribe(System.out::println);
出力結果
1 2 3 4 5 6 7 8 9 10
Single
1つのオブジェクトの流れ、エラーを扱います。 onCompleteは呼ばれないです。
プログラム
Single.just(1)
.subscribe(System.out::println);
出力結果
1
Completable
オブジェクトの流れは扱わず、完了かエラーの判定のみ扱います。
完了
プログラム
Observable<Integer> observable = Observable.range(1, 10); Completable.fromObservable(observable) .subscribe( () -> System.out.println("Complete!"), e -> System.out.println(e.getMessage()));
出力結果
Complete!
エラー
プログラム
Completable.fromObservable(observable)
.subscribe(
() -> System.out.println("Complete!"),
e -> System.out.println(e.getMessage()));
出力結果
damepo
Maybe
0~1個のオブジェクト、エラーを扱います。 onCompleteは呼ばれます。
プログラム
Maybe.just(1) .filter(integer -> integer == 2) .defaultIfEmpty(3) .subscribe(System.out::println);
出力結果
3
感想
SingleとMaybeの違いが分かりづらいです。 Singleに0個のオブジェクトの時の処理を追加したのがMaybeなのかな・・・。もっと勉強しないと！
参考URL
GitHub - ReactiveX/RxJava: RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM. RxJava2.0 Observable, Single, Maybe, Completableの使い分けメモ - Qiita
KalitaのネクストGを購入しました！
今回は念願のネクストGを購入したので使い心地や感想を書きたいと思います。
きっかけ
前々から今使ってるコーヒーミルの微粉の多さに悩んでましたが、次買うとしたら高性能なコーヒーミルを買いたかったので躊躇してました。
そんなとき、神乃コーヒーのコーヒーセミナーに参加して、そこで使用していたミルと挽いた豆の粒の揃い具合に驚愕しました。フジローヤルのミルを使用していたのですが、そんなに大きくないサイズでしっかり粒の揃った豆を挽けるとは・・・これは買うしかない！という流れです。
そのあとコーヒーミルの調査をして最終的にみるっこDXとネクストGが残りました。なぜネクストGにしたかと言うと完全に値段の問題です。現時点でネクストGの方が１万円くらい安かったからです。性能的にもそこまで差は見られなかったのでネクストGを購入しました。
良かった点１ 雑味が減った
当然といえば当然ですが粒が揃って微粉が減ったので以前より雑味が減りました。これで新鮮なスペシャリティーコーヒーを挽いて飲んだ日にはその日1日上機嫌で過ごせそうです！
良かった点２ 音が静か
以前から音はあまり気にしていなかったのですが、以前使っていたコーヒーミルよりも音が小さくなりました。ネクストGの特徴としてカッターの回転速度が遅いという情報があったのでそのおかげかもしれないです。
まとめ
結果として、ネクストGのおかげで以前より美味しいコーヒーが飲めるようになったので買って正解でした。道具をアップグレードしてより美味しいコーヒーが飲めるようになるのって、RPGに近い感じがしますね。
「成長している」という感覚を大事にしながらより美味しいコーヒーを追求していきたいと思います。
次は水出しコーヒーかなぁ。サイフォンもやってみたい。
おまけ情報
コーヒーセミナーで使ってたコーヒーポッドが良かったので紹介しておきます。
タカヒロというメーカーのコーヒーポッドを使っていたのですが、狙ったところにお湯を注げてあまりの使いやすさにセミナーの講師の方に聞きました。注ぎ口の先端部が曲線になっているのが特徴らしいです。
いつか買いたい・・・
ConnectionResult.SERVICE_VERSION_UPDATE_REQUIREDを受け取ったときに試すこと
検証端末としてHuawei MediaPad M3を購入して自作アプリとかの動作検証してたらマップ表示ができなくてはまったので備忘録として記載します。
原因
if (ConnectionResult.SUCCESS != GooglePlayServicesUtil.isGooglePlayServicesAvailable(this)) { //エラー処理 }
マップ表示前に上記のように分岐させてGoogle Play Servicesが有効かチェッックしていたんですが、ここで今回購入した端末のみConnectionResult.SERVICE_VERSION_UPDATE_REQUIREDを返却されてました。 内容としてはPlayストアを最新にしてくれってことらしいんですが既に最新版なっていました・・・。
解決策
原因はPlayストアのパーミッションでした。
端末の初回設定後、ログインした以外特に何もしていないのですがパーミッションの状態が下記のようになっていました。
位置情報がOFFになっている・・・
位置情報パーミッションをONにしてあげることで解決しました。
暫定対応策としては上記のような方法になりますが、根本対策はGooglePlayServicesUtil.isGooglePlayServicesAvailableではなく
GoogleApiAvailability.isGooglePlayServicesAvailableを使う方法らしいです。deprecatedメソッドは使わない方が良いですね。
我が家のコーヒー事情
自分がコーヒーをハンドドリップで淹れ始めたきっかけは一昨年から始めたコーヒーダイエットです。
朝食にバターを入れたコーヒを飲むことに最初はすごい抵抗感がありましたが、今では完全に習慣化されて朝食にご飯を食べることに違和感があるくらいです（笑）
なぜ続けられたか考えてみると、どうせ飲むならより美味しいコーヒーを飲みたいと思って試行錯誤するのが楽しかったからだと思います。
今回は、そんな試行錯誤の状況を時系列とコーヒー豆・ドリッパー・ミルの３要素で振り返ってみたいと思います。
2015年11月頃
コーヒー豆
カルディコーヒー・近所の個人経営してる珈琲屋さんから購入
ドリッパー
カリタ製コーヒードリッパー
ミル
なし
コーヒーダイエットを始めた時期ですね。
まずは最低限の道具で始めようと思ってドリッパーだけ買いました。
豆は近所にカルディがあったので基本的にはそこで買うようにして、たまにスペシャリティコーヒーを売っているお店で買ったりしてました。
スペシャリティコーヒーは美味しく感じますが継続的に飲むにはちょっと高すぎました。。。
2016年
コーヒー豆
ドリッパー
カリタ製コーヒードリッパー
ミル
カリタ製セラミックミル
この年はまず、コーヒーミルを買いました。粉の状態で買うと１週間たたないうちに酸化した豆の匂いがしたり蒸らすときに豆が膨らまなくなったりしました。豆を買ってるお店で聞いてみたら、豆は豆のまま買って飲むときに挽くといいですよ、と教えて頂きました。そこでオススメのミルを聞いた結果がこれでした。たしかに豆のまま保存したほうが持ちがよかったです。
あと、この年の一番の発見は辻本珈琲さんの豆ですね。会社内のふとした話から知ったのですが、500gで約600円とコスパがやばかったので即購入しました。スーパーで売ってる豆と同じくらいの値段なのに蒸らすとめっちゃ膨らむ！と感動しました。今では常連で1kgとか普通に買ってます。
2017年
コーヒー豆
辻本珈琲
ドリッパー
- カリタ製コーヒードリッパー
- ハリオ V60ドリッパー
ミル
カリタ製セラミックミル
今年ですね。ハリオのV60が気になってて買おうと思っていたのですがスペース的な問題で買えなかったのですが引っ越しを機に買いました。
使った感じコーヒーの抽出量をコントロールできるのがよかったです。濃いコーヒーが苦手な人には薄めで入れたりできるので。
今年はあとミルを新調したいです！今のミルだと微粉がやばいことになってて茶こしで微粉を落とすとかなりの量の微粉が取れます。豆の４分の１くらいは微粉になってそうな勢い・・・。もっといいやつ買う。
以上です。快適なコーヒーライフを
Settings.Global.getFloatでAnimationScaleが取得できない
Android 6.0.1の端末でAnimationScale(Transition, Duration)が取得できない問題に遭遇しました。
Mからパーミッション変わった影響かなーとパーミッション見直したり、Settings.Globalのソースを見ても特に問題ないような・・・
ぐぐってもアニメーションOFFにするとスマホが早くなるよ！みたいな記事ばかりでうんざりしているとCLIで端末の設定を覗けることが判明。
試して見ると
$ adb shell settings list global | grep anim $
何も表示されず・・・。設定が見えない。さらに調べてみると
AndroidフレームワークのAnimation設定まわりでバグがあったようです。
これの影響かどうかわからないですが、開発者設定でアニメーション設定を変更したところ
$ adb shell settings list global | grep anim animator_duration_scale=1.0 transition_animation_scale=1.0 window_animation_scale=1.0 $
表示されるようになりました。何かスッキリしないですがそんなことがありました。
CalendarクラスのcompareToが分かりづらい
今まで日付の比較を行うときはCalendarクラスのcompareToを使ってやってました。
でもcompareToって直感的じゃなくて毎回リファレンスみて「なるほど」となってたんですよ。
なんか良い実装ないかなぁと思ってましたが、よくよくソースを見てみるとやってることは単純でした。
public int compareTo(Calendar anotherCalendar) { if (anotherCalendar == null) { throw new NullPointerException("anotherCalendar == null"); } long timeInMillis = getTimeInMillis(); long anotherTimeInMillis = anotherCalendar.getTimeInMillis(); if (timeInMillis > anotherTimeInMillis) { return 1; } if (timeInMillis == anotherTimeInMillis) { return 0; } return -1; }
要はUnix時間を比較してるだけなんですね。
これなら２つのCalendarで
if (calendar1.getTime() < calendar2.getTime()){ //処理 }
としたほうが直感的だと思ったので最近はこちらを使うようにしています。
アニメーション設定を見てアプリの挙動を変えたいとき
アプリに凝った実装を入れるのは大事だなーと思ってアニメーションを加えてみました。
しかし、アプリリリース後に早速問い合わせが、、、
加えたアニメーションはゆっくり縦揺れするアニメーションでしたがユーザの問い合わせによるとアニメーション対象物がブルブル震えてるとのこと(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
調査したところ開発者オプションのアニメーション間隔設定がオフされていると再現しました。
そんなときは
canUseDuration = Settings.Global.getFloat(contentResolver, Settings.Global.ANIMATOR_DURATION_SCALE, 0);
APIレベル17未満の場合は
canUseDuration = Settings.System.getFloat(contentResolver, Settings.System.ANIMATOR_DURATION_SCALE, 0);
のように書くと設定値が取得できます。オフの場合は0が返ってくるのでその場合はアニメーションしないようにしました。
