KotlinのSealedクラス使いたくて無理をした
Kotlinのsealed class
を使いたいと虎視眈々だったんだけど
ついに突っ込んでみた。今回の用途ではそんなにメリットはないけど。
よくある成功or失敗を柔軟にという感じはなくemun
の拡張くらいの気持ち。
使ったとこ
Firebase AnalyticsでUser Propertyを設定したかったんだけど、enumで
enum class UserProperty( val propertyName: String, val value: String ) { AREA_KYUSYU("area", "九州), AREA_SHIKOKU("area", "四国), ... }
とするのは毎回area
って書かなきゃなのがかっこ悪いなと。
おっ、と思ってsealed class
使って見ると
sealed class UserProperty( val name: String, open val value: String ) { abstract class Area(override val value: String) : UserProperty("area", value) object Kyushu : Area("male") object Shikoku : Area("female") ... }
って書けた。コレジャナイ感は否めないけど、こっちのほうが好みなので良しとしよう。
まとめ
もっと活用していこう。あとブログちゃんと書くぞ!(n回目)
KotlinでGsonでStringをBooleanにする
やったこと
AndroidでRetrofit + Gsonを使っているときのおはなし。
APIレスポンスにStringで"0"、"1"が返ってくる場面に出くわして
これをBooleanとして扱いたくってTypeAdapter
を使ったよ。
なにが起きたか
{ "is_success": "1" }
みたいなやつをBooleanで扱うぞと思って
data class Response( @SerializedName("is_success") val isSuccess: Boolean )
というふうにしてたら全部true
になった。全てが正になった困った。
どうやったか
パッと思いついたのはコンバータクラス作って
// レスポンスはStringで受ける // data class Response( // @SerializedName("is_success") // val isSuccess: String // ) object ResponseConverter { fun convert(res: Response) = Item(isSuccess = res.isSuccess == "1") } fun Response.convert() = ResponseConverter.convert(this)
みたいにするのだけど、毎回するのアレだよな〜と思って調べたら
TypeAdapter
なるものを知った。詳しくは説明しないけど便利。
ということで
class IntToBooleanTypeAdapter : TypeAdapter<Boolean>() { override fun write(out: JsonWriter, value: Boolean?) { if (value == null) { out.nullValue() return } out.value(if (value) 1 else 0) } override fun read(`in`: JsonReader): Boolean { if (`in`.peek() == null) return false return `in`.nextInt() == 1 } }
というふうにしてあげて、レスポンスを
data class Response( @SerializedName("is_success") @JsonAdapter(IntToBooleanTypeAdapter::class) val isSuccess: Boolean )
のようにしてあげることで、無事変換された!!
おわりに
Gsonがどのようにうまいこと変換してくれるかまで
調べるのに手が回ってないので時間ができたら調べる。
Gsonなのか、Kotlinの型の問題なのかわすれちゃった。。
Javaのときはできてたような…できてなかったような…
調べたら追記するかも。明日はDroidKaigi。
使わないパラメータでWarningを出さない for Kotlin
Androidの話。
MVVMアーキテクチャで開発をしていると、ViewModelにクリックメソッドを実装する事が多い。
その際、
fun onClickHoge(view: View) { someThing() }
のように定義するんだけど、このview
というパラメータはそこまで使わない。
使わないパラメータで警告を出さないようにしようと
fun onClickHoge(@SuppressWarnings("unused") view: View) { someThing() }
としてたんだけど、これでは警告が抑えられていなかった。
調べてみると、これはJava
の書き方のようで、Kotlinだと@Suppress
を使うらしい。
そこで、
fun onClickHoge(@Suppress("unused") view: View) { someThing() }
としたんだけど、これでも警告が抑えられていなかった。
調べてみると、unused
じゃなくてUNUSED_PARAMETER
を使うらしい。
そこで、
fun onClickHoge(@Suppress("UNUSED_PARAMETER") view: View) { someThing() }
とすると、警告が抑えられた!🙌
conclusion
困ったらalt
+ Enter
だ 🙏
DroidKaigi conference-app-2018にコントリビュートした
このブログをはじめるきっかけにもなったDroidKaigi 2017。
一番最初のブログで、こんなことを言ってた。
来年もまたあったら絶対にコントリビュートする!と心の中で誓う私。
DroidKaigi 2017 is awesoooome!!! - イニシャルがリムーブ
コントリビュートした💪
有言実行。簡単なissueを拾ってコントリビュートさせて頂いた。
github.com
このissueをこう。
github.com
やったぜ!
すごい :+1: の飛び交う雰囲気でとてもあたたかくて
PR出すまで緊張してたけどとっても嬉しかった!
もういっちょ
あとは見ていてコードでの知見もだがUI的にも参考になる。
ぜひとも見て触って欲しいと思う。集合知である。
触ってたら
DroidKaigiアプリ学びしかないと見てたら挙動がちょっと変なとこあったのでもういっちょPR出してみたぞ(行を入れ替えただけ)
— アルまきやま (@_rmakiyama) 2018年1月15日
なんて事もあって1行入れ替えのPRを出したら
爆速でマージしていただいてさらに良い経験になった!
英語が本当にひどいので頑張ろうと思った。
けど、こんな英語でも怒られることはない!(?)
やってみて所感
今回のコントリビュートで、OSSに関わるって
楽しいし夢があるし学びしかないと身を持って感じれたのが
1番の収穫だったと思う!機会があれば狙っていきたい!
今がチャンス
easyタグのissueが増えた今がチャンス!
ぜひこの体験をあなたも!あなたも!
P.S.
2週間に1記事が聞いて呆れるけど、気にせず続けていきます🙌
RxKotlin2.2.0での注意点
ギリギリ前回から2週間以内。あまり重く考えず、会社の休憩中に書いていきます。
RxKotlin
軽く紹介すると、RxJava
はRxのJava実装ですが、RxKotlin
はRxのKotlin実装ではなく
RxJava
に便利な拡張関数を追加できる軽量ライブラリです。
約一ヶ月半前のことです。バージョン2.1.0
のリリースノートを見て、「最高かよ…」と思い
用法用量を社内コンフルにまとめて、さっそく実務投入しました。
そして12月に差し掛かったある日。
困ったというかビックリしました、、
2.2.0での注意点
バージョン2.2.0
のリリースノートに書かれたことが全てです。
(個人的に)大きく変わったところは、single
とmaybe
のto~
メソッドが削除されたところです。
// hoge()の処理からSingleを生成 Single.just("hoge") // RxKotlin 2.1.0 "hoge".toSingle()
簡易的にSingle
やMaybe
を生成する場合に重宝するかなと思っていた部分だったのですが
どうやら他のライブラリなどと競合する部分もありなくなったようです。
あまりいないかもしれませんが、使っている方は注意。
私の2.1.0での勘違い
指摘されるまで気づかず使っていたのですが、toSingle()
メソッドの定義は以下のようになっていました。(2.1.0では)
// ver.2.1.0 -> https://github.com/ReactiveX/RxKotlin/blob/2.1.0/src/main/kotlin/io/reactivex/rxkotlin/single.kt fun <T : Any> T.toSingle(): Single<T> = Single.just(this) fun <T : Any> Future<T>.toSingle(): Single<T> = Single.fromFuture(this) fun <T : Any> Callable<T>.toSingle(): Single<T> = Single.fromCallable(this) fun <T : Any> (() -> T).toSingle(): Single<T> = Single.fromCallable(this)
あるメソッドをストリームに載せたい場合に安易に
hoge.toSingle()
としていたのですが、これではSingle#just
メソッドが呼ばれるためストリームに乗らないのでした。
勝手にSingle#fromCallable
が使われていると思っていました。とんだ間違いでした。。
※ 現在(ver 2.2.0)はtoSingle
メソッドは一掃されて存在しません。
まとめ
- ライブラリアップデートでBreakingな変更はウォッチしよう!
- ライブラリは内部実装もある程度読んで、動きを把握した上で使おう!