なにがでるか

2011/10/10　日本Androidの会10月定例会での発表内容を見た後で追記。 非常に残念な発表内容でした。 Androidの可能性そのものが潰されている気持ちでいっぱいです。 下記の内容を撤回します。 ---- SmartTrainingで AppLog 対応しました。 Twitterでもいろんな意味で 盛り上がって （炎上？）いたり。 AppLogを検出する ツール がでたり。  実際使ってみなきゃ意見を言ってもねぇ。ってことで、使ってみての感想です。  ◆機能面 ログ送信確認画面の表示タイミングが不定。 サービス開始時に確認画面が表示されるわけではない。 どのアプリにAppLogが組み込まれているかわからない。  ユーザとのインターフェイスとして送信確認画面しかないので、このタイミングでどのアプリ経由でAppLogが動いているのかがわからない。 一度許可したら後で拒否するための方法がある。  Marketから「AppLog Opt-in」をインストールして拒否設定に変更できる。後付けで作ったのでこういう状態。いずれSDKに組み込んだほうが良さそう。 ◆それぞれのメリット・デメリット 開発者 メリット 月額報酬 or 収集したログのいずれかが貰える。まだ導入して間も無いので何ももらえてないけど、ログを使って新しい視点で今後の開発に活用していければいいな、と。これまでこういうサービスはなかったので貴重だと思う。（似たような情報はGoogleも収集しているはずだけど、Android端末に関する情報は提供されていないはず）ただ、実際何にどう使えるかは未知（データを見てないので）。 デメリット ちゃんとユーザに説明しないと拒否反応に合う。 当初、Marketの更新情報に「微調整」と書いたことで不評を買ってしまいました。まぁ、ユーザ観点でみたら気持ちいいものではないので、面倒くさがらずにちゃんと「AppLog入ってます」って書くべきだったか。反省してコメント修正しました。 ユーザ メリット 直接的には無い。間接的にはあるかもしれないが、結局開発者次第か。 デメリット 気持ち悪いと感じられる人には気持ち悪く感じられる。 ...

リク美女カレンダー がイイので、非公式にAndroid向けクライアント作りました。 ダウンロードは こちら からどうぞ。 アイコン他、レイアウト等、各種リソースは他アプリの使い回しという雑な仕様だけどいいじゃないか。 リク美女が見れればそれでいい。 RKBJはリク美女カレンダーを応援しています。 技術的には、 ・ Tagsoup でHTMLパース ・ CalendarView をライブラリ化して利用 ・最初からFragmentを使って実装 ってあたりが自分にとって新しい点です。 今時は必要な部品が全部揃っているので楽ですね。 設計＋実装＋試験で工数は7人時くらいでした。 たぶんまだ動作がこなれていないかも。 まぁ、いいか。 あと、使ってみてCalendarViewにサムネイル画像を埋め込みたいな。 「もえちゃん何日だっけ。。。」とかなる。 そのうち対応します。

　今年の5月にSmartTrainingがANT+なフットポッドに対応した後( ANT+なセンサーに対応してみました )、8月くらいに心拍計に対応と徐々にANT+対応を進めてまいりましたが、ようやく今回のバージョンVer.6.5.0で3・4種類目のケイデンス、スピードセンサーに対応しました。手元にあるセンサーはこれで全部対応しました。車椅子向けにちゃんと使えるかどうかはユーザさんからの声が聞けていないのでわかりません。是非車椅子ユーザさんからのご意見を聞きたいです。 ◆対応済みANT+センサー 　・フットポッド 　・心拍計 　・Bikeケイデンスセンサー 　・Bikeスピードセンサー 　実は今回対応したセンサーからデータが取れること自体は5月の時点で確認済みでしたが、常に行き当たりばったりで開発の進むSmartTrainingの機能にハマり込むように機能拡張するために周辺機能の改造に手間取りました。 　以前のSmartTrainingは、GPSからの位置情報がない限り、リアルタイム系のデータ(例えば速度や心拍数など)は記録できないような作りになっていましたが、今回からセンサーから取れる情報は位置情報とは切り離して記録するようにしました。心拍数やケイデンスも同様に記録するようになっています。 　また、「ストローク」を廃止しました。元々、これはトレーニングタイプ水泳を選択した際に水をかいた回数を加速度センサーでカウントしようとしたものでした。これまで利用していた方がいらっしゃったかどうかはわかりませんが、ご不満があれば連絡ください。復活させるかどうか考えます。 　あとANT+的には体重計とBikeパワーセンサーに対応できるかもしれませんが、センサー機材を入手するのが費用的に困難なので、対応は難しいかもしれません。ただ、ご協力いただける方がいらっしゃれば対応できるかもしれません。特にBikeパワーセンサーについてはどなたかご協力いただけると助かります。 　まぁ、いずれにしてもこれで約2年前に初期バージョンをリリースした当時から頭の中にあったデータの種類的にはほぼ全て対応し終えました。次は本格的にクラウド対応しようと思います。この対応が完了すると、データのソースがクラウド上に移行できるようになるので、端末を変えてもデータが引き継がれます。バックアップ機能の替わりにもなります...

@LuckOfWiseさんが開催されていた オープンコーラ が楽しそうだったので、いろいろと調べていたら材料が高い高い。全部揃えると送料込みで2万円なんだとか。 などとTwitterに投げていたら@LuckOfWiseさんから材料譲りますよ、とのありがたいお言葉が。 じゃ、遠慮なく、ということで送って頂きました。 ※オープンコーラについて詳しくは ググレカス 。 必要な材料はだいたい揃っているようです。 しかも、ご丁寧にスポイトまで厳重に包装していただいてます。全てのオイルは丁寧に個包装されており、きっと、大変だっただろう、と思われます。 というわけで、まずは箱を空けて今回はおしまい。 ちなみに、会社に着払いで送って頂いたら、勝手に会社のほうで送料を立て替えておいてくれたらしく、このままほっとこうかと密かに考えているわけはないです。

Facebookに別れを告げた から、というわけではありませんが、MixiがAndroid向けにSDKを公開していたのでやっつけ仕事でSmartTrainingで対応してみました。 細かい話は Mixi Developer を見てください。必要な手続き、サンプル、SDKダウンロード等すべてが揃ってるので敢えてここでやり方を各必要もなかろうと思います。 んで、このAPIを使ってみての所感というか。 ・異常系の処理 例えば、投稿時に通信が利用できないケースでは、Mixiライブラリ側がcatchしてエラーメッセージ出してAPP側にthrowしてくれません。throwしてくれないのは、ちゃんとonFatal()あたりでコールバックしてくれるのでいいんですが、エラーメッセージがアプリ側とテーマが異なったり、メッセージ内容を変更したいといったことに対応できません。ライブラリなんだからUIの領域に踏み込んでほしくないなぁ。 ・onActivityResult()実装の必要性 Facebook SDKも同じですが、Mixiへのアクセス(具体的には認証処理)時に結果を受け取るためにonActivityResult()を実装する必要があります。つまり、Activityから要求を送信することが前提となっています。例えば、Serviceが直接Mixiにアクセスしたい場合もあるわけですが、そういうケースへの配慮がありません。 そんなときは、Mixi送信用のActivityを作って画面表示とともに送信→送信完了もしくは何か異常が起きたら画面終了します。Activityは背景を透明にしておくと見た目上Activityが起動されたことがわからないのでいいカモ。 ・Mixi Developerに登録できるアプリアイコン サイズ76x76というAndroid標準ではあまり聞いたことのないサイズ。48x48とか72x72あたりにしてほしいな。まぁ、そんなことはいいんだけど、GIFかJPEGしか登録できない。いや、PNGでしょ。イマドキさ。。。 ・アカウントの登録 昔からなんだけど、Mixiはキャリアメールを持っていないとアカウントが作れない。当然、Developer登録もできない。なんでよ？Android向けのSDK提供してるならGmailくらい認めてよ。それでサポ...

以前、SmartTrainingからFacebookのウォールに投稿する機能に関して 書きました 。 面倒、面倒と文句を言いつつもちゃんと投稿することができて「 Facebookに対応してよかったこと 」などというフォローの投稿も書きました。 しかし、今こう思っています。「さようならFacebook」 理由： 2011/7/12をもってアプリ側が生成した文字列をウォール投稿用のテキストボックスに自動設定することを不可にしたから。 情報ソース [何か書く...]の下のEditTextにアプリから文字列を設定できなくなった。 文字はめんどくさがらずに全部手で入力しろ、だってさ！バカじゃねぇの？どうしてそんなに閉鎖的なのよ？何のためにデベロッパにハッシュキー登録だの面倒な手続きでアプリ登録させてアプリの認証をやってるのよ？Facebookへのアプリからのアクセスを信頼するためじゃないの？何がTwitterやFourSquareと並んで新しいタイプのIT企業だ。ただ閉鎖的なだけじゃないか。こういう意味ではGoogleの「何でもオールオッケー！でも後で問題があったら消すからね」的なスタンスの方が付き合いやすくて周囲に様々な可能性を提供してくれているんだなぁ、と思います（まぁ、いろいろ批判はあるみたいだけど）。それにしてもFacebook、ユーザーが何億いるか知らないけど小さい！本当に小さいね！ もういいよ、さようならFacebook！

前回はどんな感じでPhone向けのアプリををTablet向けにした際に割り当てていったかを書きました。 今回はもう少し細かく具体的に何やったかをまとめます。 重ねて言いますが、 Google I/O 2011公式アプリ がベストプラクティスなのでそちらを参照して真似るのが一番良いと思います。あと、 ここ とか ここ 見たらちゃんとやるべき事の詳細は書かれています。 なので、このページで書いてあることは、ひとつのPhone向けアプリをTablet向けにする際の一例だと思っていただければと思います。 1.テーマHoloの使用 　TableでActionBarを利用したければ、ActivityのテーマをHolo系にする必要があります。 　 みたいな感じ。 2.ActionBarとMenuとTitleBar 　ActionBarは普通にMenuを利用していればそのまま画面右上に表示されます。自分の場合、Phone向けのUIではあまり頻繁に操作することのない機能をMenuに入れることが多かったのですが、ハニコムでHoloテーマを使用した場合、ActionBar右側にこのMenuが出てくるので、それでいいのか考えましょう。 　Phone前提の画面レイアウトでは、頻繁に利用するボタンを画面下部に配置することが多かったのですが、Tabletの場合にこれが適切か否かを検討しましょう。必要があれば、ActionBarにいれてしまいましょう。 3.リソース 　ちゃんとdp、sp指定して画面レイアウトを構成してあれば、基本的にリソースはいじる必要はないはずです。 　ただ、Tabletでは画面サイズが大きくなるので、大きなサイズで綺麗に表示したい場合はそれ相応の画像リソースを用意する必要があります。 4.android-support-v4.jarのインポート 　ハニコム以前の環境でFragmentをサポートするためにandroid-support-v4.jarをインポートする必要があります。 　android.app.Fragmentをimportする代わりにandroid.support.v4.app.Fragmentを#importします。 　Fragment周りで主に利用するクラス。 　android.support.v4.app.Fragment 　android.support....