これが夏バテってやつか。。。
はい。
クリフはどうやら夏バテにやられているようです。
どうもだるさが抜けなくて、胃腸の調子が悪い。
と言っていたら、「それ典型的な夏バテ」と指摘されてしまいました。
いままで経験した事無かったんですけどね。
年かな。。。
と言う事で、
最近、中々ちゃんと開発に取り組めていなかったのですが、
今日はちょっと進展がありました＾＾
先日作った画像作成アプリで作った画像を、
別アプリで読み込んで表示する実験に成功＾＾
この辺のサイトを参考にしました。
http://android.roof-balcony.com/shori/strage/localfile-2/
http://d.hatena.ne.jp/Kazzz/20100116/p1
ふふふ。
これで何やろうとしてるかばれちゃいますよね。
ま、乞うご期待と言う事で。
今日、mixi meetup2010にて、
同社の新プラットフォームと大胆なアライアンスの発表がありました。
新プラットフォームの内容については、
忠実なfacebookの模倣＋スマートフォン対応と思えば間違いないかと。
つまり、ソーシャルグラフをオープンにしたけど、
目新しい「機能」は特にありませんでした。
しかし、サプライズは機能面ではなく、アライアンスにありました。
登壇した順に会社を紹介しましょう。
まずは、楽天市場。
彼らは今回のプラットフォームリリースに向けてmixiのソーシャルグラフAPIを活用した、
マーケティングシステムをがっつり作りこんでおり、
今日時点ですでに楽天での口コミ等の履歴がmixiチェックに連動される様になっています。
それだけでなく、その履歴を分析しマーケティングに活用するバックエンドの仕組みもあるそうで、
楽天の本気度合いが分かります。
次に登壇したのは、はてな。
はてぶを始めとする彼らのサービスも今日からmixiとの連携が始まっています。
次がちょっと驚きのDeNA。
一見競合に見える、モバイルコミュニティーの雄モバゲーにも、
mixiチェックボタンを実装するそうです。
DeNAの安守氏曰く、「日本のソーシャルグラフはmixiに任せて、モバゲーは世界でゲームで勝負する」
なるほど。良い思いきりだと思います。
次はYahoo!でしたが、これは元々提携があるのでまあ既定路線。
ここまで聞いた所でクリフは、
FacebookやTwitter等の米国SNS VS 国産SNS連合の構図かなと思っていました。
でも、mixiはもう一歩先へ行ってくれました。
次に出てきたのは
中国最大のSNS「renren.com」と、
韓国最大のSNS「cywirkd」！！
mixiは彼らとグローバルなソーシャルグラフプラットフォームの共通化で、
提携したと言う事です。
つまり、
mixiユーザーは中国や韓国のソーシャルアプリが利用できるし、
各国の人とのコミュニケーションもとれます。
また、ソーシャルアプリプロバイダーにとっては、
同じ仕様、同じ手続きでグローバルなビジネス展開が可能となり、
大きなメリットがあります。
そうです。
日本対米国なんてケチなもんじゃなかったんです。
アジア連合 VS 米国だったんです。
なんか、ちょっと熱いものを感じてしまうのはクリフだけでしょうか？
昨今のGoogle、やTwitter、Facebook等、米国発サービスの普及は、
ユーザーとして見れば楽しい限りでしたが、
ビジネスに携わる者として、日本人として見ればこれ程悔しい事もありません。
いつまで日本は米国のまねをしていればいいのか？
そんな風に思っていた人も多いのではないでしょうか？
実際、TwitterやFacebook、googleのパワーは計り知れないものがあります。
彼らに打ち勝つのは並大抵の事ではありません。
それはすなわち、日本最大のSNSであるmixiにとってこの先の展開が閉ざされてしまう事を意味します。
でも、mixiはそこであきらめ無かった。
ただ、技術、サービスでの真っ向勝負を挑む愚は犯さなかった。
後発のメリットを活かし、
facebookの良い所を日本風に消化した上で、
中国、韓国まで巻き込んだ連合軍を編成して、強大な米国サービスに対抗しようとしたのです。
はっきり言って、私は今日の今日までmixiをビジネスの対象として見ていませんでした。
twitterの次に来るのはfacebookだと確信していました。
今でも冷静に機能、シェア等を比較すればfacebookに軍配が上がる事でしょう。
でも、それ以上に今回のmixiの取り組みは、
日本人としてmixi連合軍に参加したいと思わせるに足る魅力がありました。
出来る事なら、
日本（もしくはアジア）発のプラットフォームでソーシャルコマースをやって見たい。
クリフは今そんな風に思っています。
皆さんはどうお考えでしょうか？
ふふふふ。
ずーっとやりたいと思っている、
CliphWeatherの背景画像カスタマイズ機能追加に向けて、
サンプルアプリで実験して見たんですが、
第一段階成功＾＾
実験した機能は以下の通り。
１．アプリ上での四角画像の生成
色、透明度をスライドバーで選択して思い通りの色の四角形画像を生成する機能。
２．画像保存機能
上記で作成した画像をファイルとして保存する機能。
３．画像読み込み＆表示機能
上記で保存した画像をアプリに読み込んで、アプリ上に表示する機能。
これが一通りできました＾＾
これで、背景カスタマイズ実装に向けて一歩前進かな♪
次は、contentproviderの勉強しなきゃ。
ふう。
またこんな時間だ。。。
自動更新機能を改善できそうなポイントがあったので、
リリースしてみました。
実装したポイントは２点。
１．ペンディングインテント競合の解消
CliphWeatherではAlarmとWidgetのタッチイベントにそれぞれ天気予報更新サービスを起動するIntentを搭載した、
PendingIntentを設定しているのですが、これが実は共通のものなので、Alarm様に設定したパラメータが、
Widgetへセットするパラメータで上書きされてしまっていました。
なので、これを独立させる様な改修を行いました。
２．WakeLockロジックの実装
スリープ中に起動して天気予報を更新する場合、AlarmManagerを使いますが、
AlarmManagerは起動先のonReceiveが終了するとスリープに戻ってしまう為、
更新処理が終わる前にスリープしてしまう可能性があるらしい。
よって、更新処理が始まったらPowerManagerクラスで電源ONの状態を確保してから、
実際の処理を行う様にして見ました。
ただ実は、この実装方法は自信がありません。
おかしな動きをしたり、やっぱり自動更新しないようであればご連絡ください。
よろしくお願いします。
ふむ。
100%の確信はないけれど、自動更新失敗の原因の一つである可能性があるものを発見。
Android DevelopersリファレンスのAlarmManagerのページに普通に以下の様な記述が、、、
The Alarm Manager holds a CPU wake lock as long as the alarm receiver’s onReceive() method is executing. This guarantees that the phone will not sleep until you have finished handling the broadcast. Once onReceive() returns, the Alarm Manager releases this wake lock. This means that the phone will in some cases sleep as soon as your onReceive() method completes. If your alarm receiver called Context.startService(), it is possible that the phone will sleep before the requested service is launched. To prevent this, your BroadcastReceiver and Service will need to implement a separate wake lock policy to ensure that the phone continues running until the service becomes available.
簡単に言うと、
AlarmManagerでスリープ中にwakeupされても、onReceive（）が終了次第またスリープしちゃうよ。だから、電源確保は各自ヨロシク！
って事らしい。
はい。
完全に見落としてました。
なので、更新掛けようと思ったけど途中で電源落ちて終了ってな事が起きてる予感。
これを回避するにはPowerManagerクラスを使って、電源を確保する事が必要見たい。
↓がそのクラスの説明。
http://developer.android.com/intl/ja/reference/android/os/PowerManager.html
具体的には↓の様に書くらしい。
PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, “My Tag”);
wl.acquire();
..screen will stay on during this section..
wl.release();
wl.acquire();でロックして、wl.release();でロック解除するらしい。
これを実装すれば自動更新処理が安定する！。。。はず。
でも、もうひとつ、
PendingIntentの扱いが良く分かって無いんだよな。。。
これも確認しなくちゃ。
うーん。
分からん。
どうも、CliphWeatherの自動更新が途切れる事があると思ったら、
タスク管理ツールでKillされるとAlarmManagerに登録したAlarmも解除されてるみたい。
なので、
CliphWeatherをAutoKillリスト等に入れていると、
自動更新が機能しません。
これ、Alarmは消されない様に対処するにはどうしたらいいんだろう。。。
ま、じっくり調べますか。
強制終了する不具合があったので改修しました。
これで今回のIS01対応の混乱はひと段落のはず。
はずはず、と言っておきながら最近色々やらかしてるから不安なんだけど＾＾；
ま、その時はその時で＾＾
ああ、早く前向きな開発に掛かりたいぜ！
表題の件、
ちょっと、整理しようと思います。
ニーズのままに拡張を繰り返して来たら、
ソースコードがかなりごちゃごちゃして来てしまった。
多分、最近ミスが多いのもこれが原因だと思う。
と言う事で、
先に進む前に、一度ソースコードの整理整頓をして、
見通しの良いソースコードにしようと思います。
ついでに、
無駄なDBアクセスを繰り返している所があれば、
一回で済むように組み替えるなどしてパフォーマンス改善も図ります。
今日はとりあえず、
日付・時間系の処理を共通処理化しました。
これで、大分ソースがスリムになった＾＾
それから、今まではプリファレンス変更都度、
widget更新intentを投げてたけど、これが重いので、
プリファレンスActivity終了時（onPause）に一本化しました。
てな感じで、
ちょいちょい進めて行きたいと思います。
ホントはデザインカスタマイズ系の機能拡張したいんだけど、
中々そこに着手出来ないんだよな～＾＾；
ま、がんばりますか。
ちょっと今回は反省。
はっきり言って検証が不十分でした。
わざわざバージョンアップして頂いた方、
ご迷惑おかけしました。
改めてバグフィックスを行い、再リリースしましたので、
ご確認ください。
それにしても、
多くの方に使ってもらっているってのは嬉しい反面、
やはり結構大変なものですね。。。
やさしいお声をかけて下さる方も多いですが、
それでもやっぱり、期待を裏切るのは心苦しいもの。
今後はもう少し慎重に検証を行おうと思います。
ふう。疲れた。
今日は夕方にフットサルの試合を４本やって来たので、
結構疲れてます。
明日の筋肉痛が怖い。
ま、そんなことはさておき、
CliphWeatherのIS01対応第一弾として、
横画面用４×１widgetを追加しました。
先日のエントリーでも書きましたが、
縦画面と横画面ではwidgetサイズが大きく異なるので、
情報のレイアウトを大分みなおしました。
まず、
縦幅が狭く、下に更新日時や、地域を表示するのが難しくなりました。
これは、その分広がっている横幅を生かして、右端に情報エリアを設けました。
また、これらの情報を表示しない場合は、
右端が空いてしまってカッコ悪いので、６日目の予報を表示する様にしました。
こんな感じでどうでしょうね？
良ければ他のサイズのwidgetも作って行きます。
てことで、寝るか～
