なにがでるか

リク美女カレンダー がイイので、非公式に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....

前回はハニコム対応したアプリケーションの基本機能を紹介しました。 今回はTablet対応した際にPhone上で実現していた機能をどういう風にTablet上で表現するかを説明していきます。 まずは実際に対応を完了したアプリの画面を見ながら結果的にどうなったのかを説明していきます。 ◆Tablet用画面 ・画面を左右2分割して左側にサムネイル用のGridView、右側に選択した画像の高解像度表示を行います。 ・画面上部にはActionBarを配置して、左上にはアプリケーションロゴと名称。右上には各機能呼び出し用のボタンを表示します。 ・画面下部にはサムネイルの切り替え（ランキング／お気に入り）ボタンと、全ユーザのお気に入り登録回数とお気に入り登録ボタン（☆）を表示します。 ・画面右下にリング型のProgressBarを配置して、サムネイル更新中または高解像度画像ダウンロード中はProgressBarを表示します。 フレーム表示だとこんな感じ ◆Phone用画面 基本的には対応前と変わりませんが、以下の点が変わります。 ・タイトルバーの代わりに、ActionBarっぽい感じで独自レイアウトのバーを画面上部に表示します。 ・詳細画面でアプリロゴを選択するとホーム画面(サムネイル画面)に戻ります。 サムネイル画面 サムネイル画面フレーム 詳細画面 詳細画面フレーム ☆基本戦略 ◆Tablet画面 ・サムネイル画面と画像表示画面をひとつの画面に固めることで画面遷移をなくす。 ・画面下部に配置していたボタンのうち、よく操作するものをActionBar内に配置する。 ◆Phone画面 ・Tablet画面と画面デザインを合わせるため、タイトルバーに相当するバーの高さをTabletのActionBarと同じ高さにする。 ・その他よく使用するボタン配置は使い勝手を優先して位置を変更しない。 だいたい以上のような感じになります。 次回はもう少し具体的に実装面で考慮すべき点をまとめようと思います。