GoogleはWebにアクセスする利用者が増えればいいわけで、積極的に有料アプリを売る事に積極的になる理由が皆無ってところが、開発者的にはどうも気になるなぁと。Googleからすればアプリは無料でくばって使う人が増えてくれればいいわけで。iPhoneと比べてAndroidのmarketのやる気がない感じになってるのも、そこら変に理由があるんだろうなぁと。
あともう一つは、端末が増える事で、異なる端末毎に対応のためのコードが必要になったりするだろうなぁという点で、若干いばらの道がまってるだろうなという。
端末としての完成度考えれば、現状の端末は圧倒的に負けているけれど、色んなところから端末がでる可能性があるというところのオープンさが魅力。色んな端末がでるから3年くらいの長い目でみればトータルでAndroidがのった携帯の利用者数はそれなりの数になるんじゃないかなぁというところに、開発者としての面白さがあるかなぁと。
現状で端末の出来は悪いけど、長い目でみれば、どっかがいい端末だすんじゃないかという期待はあまいのかなぁという気もしつつ。
以下のbest practiceと、Google I/Oの動画みるのが吉。
http://developer.android.com/guide/practices/design/performance.html
http://d.hatena.ne.jp/dann/20090622/p1
めちゃくちゃJavaっぽくない感じの実装になりますが、パフォーマンスを維持するにはいたしかたないって感じですかね。
基本的にモバイル系のデバイスのXML系処理は、処理性能とメモリ制約の関係からXML関係のライブラリのサポートはあまりありません。
割と既存ライブラリは、DOMとかでXMLをつくって、リクエストを生成するので、DOM系のライブラリ使ってる物は、ライブラリを修正してandroid用にportingしないといけません。そのため、APIがAtomPubとかだとそれをサポートするのに既存ライブラリをそのままでは使えずに、自前で作っていく必要があり、作り込みが多くなるのでなかなか面倒ですね。
うーん、android付属のHttpClientのバグっぽいなぁ。
抜け道があるのかソース読まないとわからず。パッチ書いときたいな。このせいで1時間くらい色々ソース読んだりとはまった...
# 結局、RequestContentをDefaultHttpClientで参照しているメソッドをoverrideして対処。RequestContent中で、reuqestに明示的にContent-Lengthが設定されていると、ProtcolException投げるようになってる。
ADV ManagerでADVつくる時に、上記のsdcard_testのパスを、emulator側で指定。
AlertDiarlog.BuilderでsetMultipleChoicedItemsメソッドをつかってCheckBoxをチェックしたが、OKボタンを押したときに、checkされたcheckboxを取得する方法がわからない... ソース嫁って話な予感も.
# ソース読んだけどとれなそうってことで、チェック状態を外部で管理する事に。うーん、CheckBoxを取得して、そのCheckBoxに状態を聞く方が、自然だと思うんだと思うけどなぁ。
androidのソース読み。Handlerの仕組みがわかった。
要するに、UI Threadはシングルスレッドで他のスレッドからいじれないようにしていて、そのUI ThreadでUIを操作させるのだけれど、UIを他のスレッドからマルチスレッド風にいじりたいときにHandlerは使う。
流れは、大体以下のような感じ。
別スレッド作って、HandlerにRunnable渡すって時点ですごい冗長。これは、もっとフレームワーク側で隠蔽したいなぁ。Handlerなんてのが、ユーザーに見える必要全くないと思う。ここらは作ろう。
# と思ったら、既にクラスがあった。
AsyncTask
やってることは上と同じ。上のクラス内のInternalHandlerを読めば、Hookpointがどう動くかわかる。
PerformanceまわりのBKがまとまってる。
本家にまとめた
http://www.youtube.com/watch?v=U4Bk5rmIpic
これは後で。
azurestone2009/06/23 14:52BKってなんでしょうか?
dann2009/06/28 03:30バッドノウハウ !