LiveData について勘違いしていたことをいくつか - Qiita
Android Architecture Components(以下 AAC) に含まれる 「LiveData」 のサンプルを Kotlin で書いてみました。 LiveData とは LiveData とは、「ライフサイクルに応じて自動的に購読解除してくれる通知プロパティ」です。 モダン(と呼ぶにはもはや古い？)なUIパターンでは、UI側はデータの変更を検知して自身を書き換えます。 すなわちUI側では、「データを購読する」というコードを書くわけですが、「購読をやめる」というコードも合わせて考えなければなりません。しかし Android の Activity や Fragment はライフサイクルが複雑で、購読を管理するのも一苦労であり、不具合の温床になりがちです。 LiveData は AAC に含まれる Lifecycle と深く結びつき、この「購読解除」をほとんど自動的に行なってくれ
2-wayデータバインディングが格段に実装しやすくなったAndroid data-binding 3.1.0 - Qiita
データバインディングでLiveDataが使えるようになったみたいな話があったので、いじってみたときのメモ。 ユーザ名とパスワード、規約にチェックしてないとsubmitボタンを押せなくするみたいな制約条件をデータバインディングで実現するのが今回のテーマです。 レイアウトXML →いままでどおり <?xml version="1.0" encoding="utf-8"?> <layout> <data> <variable name="viewModel" type="io.github.yusukeiwaki.twowaydatabindingpractice.SignupActivityiewModel"/> </data> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:la
エラーメッセージはフォームのどこに表示するべきか
UX Movementの著者および設立者です。ユーザー体験のデザインスキルの開発を手助けしてよりユーザーフレンドリーな世界のために、このブログを創設しました。 フォームのどこにエラーメッセージを配置していますか？ ユーザーの期待する場所にエラーメッセージが置かれていないと、ユーザーはフォーム入力を完了できなくなってしまうかもしれません。 フォーム入力を間違えたら、ユーザーはそれを修正して送信し直すために、なにが間違っていたのかを理解する必要があります。フォームを完了しようと思っていたとしても、それがあまりにも大変であればユーザーは心変わりしてしまうでしょう。 フォームの上か、フィールドのインラインか エラーメッセージの配置場所でもっとも一般的なのは、「フォームの上」と、「エラーのあるフィールドのインライン」という２箇所です。どちらの配置場所が、ユーザーにとってより直感的でしょうか？ 調査に
Kotlin Fest 2018でコルーチンの話をしてきた - visible true
kotlin.connpass.comでコルーチンに関する話をしてきました。 Kotlin コルーチンを理解しよう スライドはコチラ。音声や動画が無くても大体読めばわかる内容になっていると思います。 流れ 6月末にひつじさんからお手紙がとどく 直前の技術書典4でKotlinのコルーチンを使う前に自前で実装してみるという話を書いていたこともあり、 その辺をベースにした話の組み立てでできそうな気がするということでシュッと受けた。 結果的にめちゃくちゃ大変でしたが最終形はなんとかまとまったので良かったです。 調べたことや登壇時は触れられなかったことなど 話のベースは頭の中にあったものの、コルーチンの概念そのものが一体どういうものなのかあまり深く理解していなかったこともあり、その辺の調査もしなきゃな〜と手を動かし始めるとそのままどツボへ真っ逆さま。今回話の流れや時間的に触れられなかったことなんかを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
東京圏から移住に最大300万円補助 - 日本経済新聞
