なにがでるか

2009/10/17にver.1.0.0をリリースして以来、2年ちょっとの期間で94回のリリースを行ったSmartTraining。ver.6.8.1。たぶん、今年はこれが最後のリリースになると思うので、まとめてこれまでのことを振り返ってみます。去年は振り返ってなかったので今回2年分まとめて。 ver.1.0.0(2009/10/17)のスクリーンキャプチャ。 トップ画面(ver.1.0.0) 計測画面(ver.1.0.0) 設定画面(ver.1.0.0) とにかく、「入門書読みながら初めて作りました」的な雰囲気が満載ですね。元々、Androidで動く万歩計が欲しかったのと、GPSデータの取り扱いの練習用に作ってみようということで作り始めたアプリでした。最初はServiceの使い方も手探り(つい最近のバージョンでようやく正しい使い方を知ったのですが)で、画面を閉じると計測も止まってしまう作りでした。ボタンや画面テーマも標準のものをそのまま使った貧相なもの。アイコンの作り方を知らなかったので、画面上に画像リソースは皆無。ただ、画面は殺風景ですが、基本的な画面遷移や構成は今と変わっていません。MapViewによる地図表示とGoogle Calendarにデータを保存するという機能が最初からありました。 確か、最初に作ろうと思ってから初期バージョンをリリースするまで3ヶ月ほどかかったと記憶しています。たぶん、今これと同じ機能を作ったら1日あれば余裕で作れます。というか、コードを書くことより、どういう画面遷移にしたら使いやすいか？、どういう機能があったら楽しいか？という点を考えることに時間を多く割いていました。あと、たった一個のアプリケーションアイコンがどうしても作れなくて結局嫁さんに作ってもらいました。 江川さんの「 Google Androidプログラミング入門 」片手にひたすら真似するところからスタート。この本には本当にお世話になりました。 そしてVer.6.8.1(2011/12/30)のスクリーンキャプチャ。 トップ画面(ver.6.8.1) 計測画面(ver6.8.1) 設定画面(ver.6.8.1) ラリー画面(ver6.8.1) だいぶ賑やかになりました。アプリを作っていて途...

ユーザの認証情報をAccountManagerに変更した時から、時々「Fusion Tablesへのアップロードに失敗する」という報告を受けるようになりました。 手元にある端末で確認してみると、4台中1台だけがどうしてもうまくアップロードできません。エラーはcreate table時に401。 その後、原因がわからないまま1ヶ月程度過ぎた頃、またアップロードを試してみると、先日うまくアップロード出来ていた他の端末もことごとくエラーcreate table時に401が出ていることを確認。 なんだろうねぇ。何気にと思いググって情報がみたら見つかりました。 http://d.hatena.ne.jp/yellow_73/20110819 まさにこれ。この問題です。 端末に保存されているtokenの賞味期限が切れているっぽい。 401が発生したらAccountManager#invalidateAuthToken()を呼んでauthtokenを破棄した上でもう一回最初から認証のやり直しをすることでうまくアップロード出来るようになりました。 Google DocsやGoogle Calendarにも似たような仕組みで認証かけてデータアップロードしているのに、こちらではそんな状況に陥ったことがない。なんでだろう？Fusion Tablesはtokenの賞味期限が他サービスよりもかなり短くせっていされているのか？と思いました。実際のところわかりませんが。 「 AccountManagerのgetAuthToken()をReflectionでヤッてみた 」で書いたとおり、私のアプリは1.6もサポートしているので、AccountManagerを普通に使うことができない。というわけで、これまたReflectionの登場。前回の記事読めばReflectionのパターンはわかりますよね。ということで省略。

久々に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年前に初期バージョンをリリースした当時から頭の中にあったデータの種類的にはほぼ全て対応し終えました。次は本格的にクラウド対応しようと思います。この対応が完了すると、データのソースがクラウド上に移行できるようになるので、端末を変えてもデータが引き継がれます。バックアップ機能の替わりにもなります...