仕事で Android アプリのコードを触り始めはや数ヶ月。少しは理解が進んだ。 今の仕事のコードは、残念ながらそれほど素晴らしくない。その昔 Android Java にまだ慣れていなかった人々が書いたであろう古いコードが目につく。そして古いコードの昔ながらな残念さは、従来の Java とは違う Android Java の「らしさ」を描き出す。そんな話を数回にわけて書いてみたい。 第一回は非同期性のはなし。 Android のアプリはメインスレッドをブロックしてはいけない。だから色々と非同期に書く。ところが従来の Java は非同期がさほど得意でない。多くの API がブロックする。 ブロックする処理は別のスレッドに追い出せばいい。ただし結果はイベントループを通じてメインスレッドに戻さないといけない。これを綺麗に書くイディオムが、Android では最近まで確立されていなかった(Asy
寿命、ライフサイクルのはなし。(Part.1 はここ) Android の中には、決められた寿命を持つ重要なオブジェクトがいくつもある。代表例は Activity. View も Fragment もプラットホームによって寿命が決められている。 Java は誰かに決められた寿命を扱うのがあまり得意でない。多くのオブジェクトは Java 自身の GC が寿命を決める。GC があるからプログラマは寿命について悩まなくていい。そんな態度が従来の Java にはある。C++ のように神経質な寿命管理は出番が少ない。 Java でも File のような OS の資源は GC でなくプログラマが寿命を決める。Socket なんかはもう一段厄介で、相手側から閉じられると勝手に死んでしまう。そして死んだオブジェクトを触るコードは呪いの例外に見舞われる。 勝手に死ぬ Activity や View の性質は
About the content This talk was delivered live in August 2015 at Droidcon NYC. The video was transcribed by Realm and is published here with the permission of the conference organizers. How can you move away from traditional synchronous state management with variables to asynchronous streams of data? Try functional reactive programming! In this talk from Droidcon NYC, Juan Gomez explains why you s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く