Android小話メモ(2) data-binding
はじめに
自分用のTL参照メモ。
過去のアーカイブ
TLメモ(data-binding)
data-bindingの利用に関して
・ListViewのカスタムViewに
— 味ついてておいしいです (@wakamesoba98) 2017年8月21日
・高さがwrap_contentなViewで包まれた
・内部の要素を
・DataBinding使わずにsetVisibility
すると、たとえexecutePendingBindingしてもListViewの要素の高さが狂いまくる
レイアウトが崩れる問題は target apiを上げたことによる影響だと思うんですけどね・・
LinnerLayoutが縦 wrap_content指定だと 縮むので、マイグレーション対応でRelativeLayoutに直していたりする
どうも挙動変化タイミング的には RecyclerViewのレイアウト修正対応絡みのタイミングっぽい*1
android.jar側に修正が入っている感じ
条件が限定的すぎるけど、要するにDataBinding使ってレイアウトXMLでビューの表示の制御をするなら、Java側に「binding.hogeView.setVisibility(View.GONE)」みたいなコード書いちゃダメっぽい
— 味ついてておいしいです (@wakamesoba98) 2017年8月21日
bindView側でやると駄目というか、凄くちらついたので View側で確かに制御してるかな・・
android.visibility=@{TextUtils.isEmpty(bean.hoge) ? View.VISIBLE : View.GONE}
BindingAdapterを導入してみてデバッガーで止めればわかるけど、
ViewレンダリングのタイミングはbindingViewよりかなり遅延して実行されているのでタイミングが合わないんだと思う
googleのサンプル自体も、View側で制御するの推奨してるっぽいし
DataBindingをfindViewByIdの直接的な置き換えとして使うのは場合によってはwrap_contentの高さ計算のタイミングと合わないなどのトラブルの元になりそう
— 味ついてておいしいです (@wakamesoba98) 2017年8月21日
findViewByIdを使わないために、databinding導入が確かに一時期はやったけど
data-binding plugin が定期的に動かなくなる度にダメージ食らってるので
どのためのkotlin化推奨の流れ だと正直な所思ってたりしてる
イミュータブルなViewModelオブジェクトを作ってあとはDataBindingで表示するだけ、という美しい世界を構築しようともがいてたけど、後からViewの属性に触ると微妙にバグるのでViewModelオブジェクトに泣く泣くsetterを追加
— 味ついてておいしいです (@wakamesoba98) 2017年8月28日
DataBindingで綺麗に仕上がらないならそれは設計が間違っている、と考える事も出来るが趣味なので設計はいい感じにやっていい感じに仕上げる
— 味ついてておいしいです (@wakamesoba98) 2017年8月28日
結局のところ
findViewByIdはキャストが面倒くさいので<T extends View> T findViewById(int id)というコードが現役だったりする
— nao20010128nao (@2ndLesmi) 2017年8月21日
で十分かなと思う面も多々ある。
@SuppressWarnings({"unchecked","deprecation"}) protected <T extends PreferenceGroup> T _findPreference(final String key){ return (T)findPreference(key); } @SuppressWarnings("unchecked") protected <T extends View> T _findViewById(final int id){ return (T)findViewById(id); } @SuppressWarnings("unchecked") protected <T extends View> T _findViewById(View parent,final int id){ return (T)parent.findViewById(id); }
data-bindingの仕組み的な話
DataBindingライブラリの内部構造を知る https://t.co/2c5dq9kmT0 最近出会った不具合のおりにしたDataBindingの内部構造調査結果です。ご査収ください。
— mhidaka (@mhidaka) 2017年8月18日
この記事の記載読んでたんだけど
binding.executePendingBindings();
って、executePendingBindings 処理中にバックキーで戻ったりすると落ちるんで
try-catchで囲んだほうがいいかなーとは思った。
再現的には ListActivity とかのほうが容易だとは思うけど
お。Android plugin for Gradleのことかな。2.2.3かな。割と古い。
— mhidaka (@mhidaka) 2017年8月18日
そのあたりの差分情報もあんまり出てこないですよねぇ。アプデ時の検証とかで役に立つんでまとまってて欲しいところでは有るんですが。
— mhidaka (@mhidaka) 2017年8月18日
このあたりの知見情報をとりあえずさっきの記事に追記しておいていいですか(まとまってるほうが有益そうというゆるい気持ちです)
— mhidaka (@mhidaka) 2017年8月18日
このpatchがやっと採用された著名開発者のSTAR_ZERO さんの改善された言及はありますが
実際の処、Beta以降はdatabindingはリビルドが不安定。クリーンして初回ビルドすればいけるけど。
ただkaptを使うと安定する という話は有るようなので
AS3.0で開発するにはkotlin前提にしないと、不具合対応自体厳しくなるかもしれない。
G様内部の開発者がkotlinしか使ってないなら、ローカル単体テストもその環境下でしかしてないでしょうし。
なんかTLに「Android Oの発表ついでにAS3.0正式版にしちゃえよ~」 なの結構流れてたけど
それで見切り発車なら、まあkotlin界隈だけが喜ぶ感じになりそうかな~(^^;; *2
data-bindingの不具合的な話
DataBindingは縦横違うレイアウトだとハマります😇#SouzohAndroidTalk
— ogaclejapan (@ogaclejapan) 2017年8月25日
DataBinding、メソッド名が長いとビルド通らない問題とかあったしなぁ…。 #SouzohAndroidTalk
— Tomoya Miwa (@tomoya0x00) 2017年8月25日
Architecture ComponentsのGoogleのドキュメントでDataBindingsを併用するやり方が説明されていないのは、中の人も辛いと思っていて入れなかったのか…??(想像) #SouzohAndroidTalk
— ほたて (@plavelo) 2017年8月25日
タブレット対応とかで NPE もあるよ
— びな🙋 (@bina1204) 2017年8月25日
確かに! 扱う側の Activity は if とキャストだらけになって可読性落ちまくりだから、Kotlin が十二分に活かせますね😂
— びな🙋 (@bina1204) 2017年8月25日
data-bindingとkotlin (2018/06/18追記)
android studio 3.1 Canary6 からはkaptも書かなくて良くなったらしい
因みに、LiveData(Lifecycle)のクラスを使うには appcompat 26.1.0以上が必要。
これ書いてるドキュメントが公式1文しかなくてだいぶハマってた。。。*3
TLメモ(SNS連携)
SNS連携におけるクローズドAPI or 機能に関して
FacebookのevilさはAPIの改定でうちのアプリが締め出された時点で強く実感してたんだけど、本質的に怖いのはそうした「クローズドAPI」を採用するFacebookやInstagramがSNS界隈で主流になりつつあって、その流れをTwitterも追いかけようとしてることです
— 竹内裕昭 (@takke) 2017年8月21日
UserStreamそのうちなくなるし、同じ内容のアプリ登録したらBANされるようになるっぽいし、DM周りのAPIもごちゃごちゃ変わって使いにくくなるし、、Twitterが開発者と仲良くすると言ってたのはまじで幻想だったんじゃないかと。
— 竹内裕昭 (@takke) 2017年8月21日
冗談じゃなく、Jackのあの発言はなかったものだと思った方がいい。Twitterの非公式アプリもそのうち締め出される。理想的には一度その方向で舵をきってもらって、ユーザーが激減し始めたタイミングで大いに反省していただいて、一気にAPIを緩くして欲しい。
— 竹内裕昭 (@takke) 2017年8月21日
結構みなさんアカウント切り替えて使ってるんですね…
— 味ついてておいしいです (@wakamesoba98) 2017年8月20日
twitter社の「サポートしたい」がどの程度のものなのかについては、全サードパーティ開発者が知っている。具体的に言うと、いきなり制限して放置し、急に「やっぱ間違いだった。信頼回復したい」と言い出してその後、放置する。
— 尾野(しっぽ) (@tail_y) 2017年8月28日
twitter社、アイコンを丸にした時も「日本のユーザーについて、これからも勉強していきたい」って言って、特に何か対応するわけではなかったからねhttps://t.co/YzKwfvSRO1
— 尾野(しっぽ) (@tail_y) 2017年8月28日
「開発者との関係を回復したい」(APIキーを凍結しながら)(DM権限を剥奪しながら)(UserStreamの廃止を宣言しながら)(Restricted from performing write actions)
— 味ついてておいしいです (@wakamesoba98) 2017年8月28日
自分的考察
よくアプリにTwitter タイムライン Viewerを入れたいみたいな話はあって、
— close_yutori (@kimukou2628) 2017年8月21日
* ユーザ切り替え的な機能欲しい
* でもiOSだとTwitterkitみたいなのをいれて対応するまでは微妙
* じゃあ対応しなくてもいいか(i/a差異不許容)
みたいな流れになることが有るな〜
たしかにそれは思いますね。
— close_yutori (@kimukou2628) 2017年8月21日
TwitterKit使って思うんですがTwitterクライアント劣化版しか作れないようにして基本Twitter公式アプリ にリダイレクトされるような挙動になるので正直微妙に思ってたり(min14以下でtwitter4jと併用するとなお顕著
企画レイヤーの話だと FacebookやInstagramやTwitter公式アプリっぽい見た目の機能の一部切り取りみたいなのSNS連携っぽいの入れたい
— close_yutori (@kimukou2628) 2017年8月21日
はよく有るんだけど、公式FW SDK 利用だと向こうのマネタイズ戦略的に公式アプリ使わせる為の導入口に利用されがちなんだよな〜
しかもあくまで「見た目だけ公式っぽい」だけので、そのまま利用した場合かなり劣化。
— close_yutori (@kimukou2628) 2017年8月21日
まあ同じ機能のアプリを作らせないための対処法だとは思うんですけどね。
本家に近いアプリを作りたい場合は、G様のGoogleWork みたいに企業契約が必要なみたいなかんじで有料になるのかな・・