なにがでるか

久々にSmartTrainingのバージョンアップ(6.6.0)を行いました。 今回のバージョンでは、地味だけど重要な変更を加えています。 ---- ◇ Ver.6.6.0 変更内容 ・使用するパーミッションとライブラリの変更。 ・Android 2.1以降でサービスをフォアグラウンドに設定 ・Android 2.1以降で端末のGoogleアカウントと連動 ・Android 2.1以降で過去に端末内に保存したGoogleパスワードの削除 ---- ・使用するパーミッションとライブラリの変更。 最近、Androidに対する情報セキュリティがいろいろとうるさくなってきました。アプリケーションが持つパーミッションに対する意識も高くなり、ただの万歩計なのになんでそんなパーミッションが必要なの？とコメントをいただくこともでてきました。このアプリケーションは元々私自身がAndroidアプリ作成と公開を通じて様々な知見を得ることが目的で作り始めたものでした。そのため、通常の利用者が必要としないいくつかの機能を含んでいます。ここのところ実験的に取り入れた機能のために与えたパーミッションが増えてきたので、一度整理してみました。合わせて、使用しているパーミッションとその使用目的をAndroid Market上に公開しました。 ---- このアプリケーションが使用する各パーミッションが必要な理由は以下の通りです。 ・データをGoogleサービスにアップロードする際に端末内のGoogleアカウント設定を使用するために必要としています。 android.permission.USE_CREDENTIALS android.permission.GET_ACCOUNTS android.permission.AUTHENTICATE_ACCOUNTS ・画面テーマ変更時に自アプリケーションのリセットのために必要としています。 android.permission.KILL_BACKGROUND_PROCESSES ・GPSによる位置情報を取得するために必要としています。 android.permission.ACCESS_FINE_LOCATION ・広告モジュールが動作するために必要としています。 andr...

AccountManager#getAuthToken()を利用することでAndroid端末に登録したアカウント情報のTokenが取得できます。普通の使い方は こちらあたり に詳しく載っています。 これを利用することで例えばGoogle Serviceへのアクセス時認証に利用できます。取得したTokenをClientLoginの際のAuthに設定してやればOKです。 と、普通はこれで話が済んでしまうのですが、AccountManagerはAPI Level 5以降じゃないと利用できない。これより古い環境でこのコードを実行するとjava.lang.VerifyErrorが起きてしまいます。 これは後方互換性の問題です。Androidアプリを開発する際に気をつけなければいけないのがこの問題。詳しい対処方法は こちら に掲載されています。これらの対処方法のうち、今回はReflectionを利用することで回避してみました。当然のことながら、Reflectionを使ったからといって古い環境でAccountManagerの機能が使えるようになるわけではありません。実行時のVerifyErrorが回避されるだけです。同等のことを古い環境でやる場合は、 Google Data API のClientLoginなりをHTTPリクエスト送ってやればOKです。Java(Android)向けのライブラリも公開されているのでそれを使っても良いと思います。まぁそれはそれで置いといて。 今回主題のやり方はこちら。 public class AuthenticatorAfterForoyo extends AuthenticatorBase { private static final String ACCOUNT_TYPE_GOOGLE = "com.google"; /** * コンストラクタ * @param context */ public AuthenticatorAfterForoyo(Context context) { super(context); } /** * トークンの取得 * @param account * @param passwd 不使用 * @param service */ publi...

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くらい認めてよ。それでサポ...