なにがでるか

ググれカス plug-in for twicca 1.1 リリースしました

2012-01-14T05:05:00.000+09:00

ググれカス plug-in for twicca の新バージョン1.1をリリースしました。今回のバージョンでは、以下を修正しています。

- 英語リソース追加
- 日本語単語抽出ロジック変更
- バグ修正

思いつきの小ネタだったので、日本語での利用しか想定していませんでしたが、非日本語圏でも使えそうなのでとりあえず英語リソースと英語での紹介文を追加してみました。その他の言語については把握しきれないので放置の方向で。ちなみに、英語向けの紹介文はこんな感じ。英語ユーザーじゃないのでこういう表現が妥当かよくわからないけど。

----
ggrks plug-in enables to search the words in tweet .
This plug-in is for twicca.
ggrks means "You should search the word in google before ask other. fuckin' novice!".
----

あと、他の修正は微調整ということで。
その他としては、「ggrks」、「ググれカス」あたりでも検索に引っかかるように紹介文を変更してみたり。

もちろん私はググれカスだなんて思ったことはないですよ。
あくまでネタですから。

ググれカス plug-in for twicca 公開

2012-01-09T02:05:00.001+09:00

新年明けましておめでとうございます。正月はTVを全く観ていないせいか、正月気分には浸れませんでしたが、表題の件、公開しました。

twiccaで表示されているツイートの内容から単語を抽出し、ググるためのプラグインです。似たようなモノはありそうですが、まぁ、いいでしょう。
TL上のネットジャンキーのスラングがわけわかめー！という状況で使えるかもしれません。でも、わけわかめなスラングが単語として抽出できるかはわかりません。

◆使い方
わけわかめなツイートを選択して、メニュー上から「ググれカス」を選択。

単語抽出されるまでしばし待つ。抽出されたら検索したい単語を選択する。

ググる。

以上。

◆仕組み
1. twiccaからTweetの文字列を受け取る。
2. 形態素解析とキーフレーズ抽出により単語抽出を行う。
3. 抽出した単語を一覧表示。
4. 選択された単語をググる。
単純ですね。

難点は2.をWebサービスを利用して行っているので、
・数秒待たされる。なんて致命的。
・特に乱れた日本語の場合、思ったとおりに単語抽出してくれないことがある。なぁんて致命的。
って感じです。

ま、ネタなんで許してやってください。

そういうわけで、本年も小ネタで行きますが、よろしくお願いいたします。

2年ちょっとを振り返って

2011-12-31T23:49:00.000+09:00

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)

だいぶ賑やかになりました。アプリを作っていて途中で気づいたのですが、GPS万歩計アプリはいろいろな技術要素の練習台としてはとても良い題材だったと思います。
・位置情報やMapViewの取り扱い
・方位センサーと連動して回転する地図
・Serviceによるバックグラウンド処理
・タイマー、AlarmManagerの利用
・Notificationによる音声・振動・画面通知
・AccountManagerやGoogle Data APIs(Calendar、Fusion tables、Docs)との連携
・AWSとの連携
・他アプリ(特にTwitter)との連携
・Felica連携(串かつ経由)
・Mixi voiceやFacebookなどのSNSとの連携
・音声合成サービスとの連携
・加速度、方位センサーの利用
・ANT+対応の外部センサーの利用
・カスタムViewによるグラフ描画
・QuickAction
・LibAndroTranslationによる翻訳サービス
・画面テーマ
・有料アプリ
・広告

本質的に不要なものもあるかもしれませんが、自分としてはそんなことはどうでもよくて、全てのモチベーションは「その機能を使ってみたいから取り込んでみる」でした。結果、全体的にちぐはぐになったと思います。行き当たりばったりで追加した機能ばかりなので当然です。練習用に作ったアプリなのでそれで問題ありません。

中でもラリー機能は、特に思い出深い機能です。子どもがもうすぐ産まれる、というタイミングでこの機能を思いついて、ラリーのコースデータを作っている途中で産まれました。車で1時間以上かかる病院に毎日のように通ってから帰ってきてからデータを夜中まで作る、という繰り返しでした。眠い中ひたすらGoogle Earthの画面上をクリックしてコースデータをチマチマ作っていて肘が痛かったことを覚えています。

たぶん、アプリを作って公開されている方は皆さん感じていると思いますが、ユーザさんからのフィードバックが最も大きな収穫物だったと思います。時にはけちょんけちょんに叩かれることもありますが、現実世界でそこまでダメ出しされる機会というのはそうそうありません。ダメなところは時間をかけて真摯に改善していくことで必ず良い評価を得られると感じています。

それと、いったん世間に公開してユーザさんがつくと、そのアプリは開発者個人のものだけではなく、ユーザさんのもの、という扱いをされることも認識しました。ユーザが望まないことは開発者といえども自由にはならないのだと。

私の場合、Androidアプリを作成する作業に割り当てることのできる時間は、仕事を終えて、家に帰ってきて、家の事柄全てを終えた後のほんの僅かな自由時間だけです。たぶん1日平均30分もないと思います。本職ではあまりコードを書く機会はなく、見積もり、営業への同行、PLなどが主な仕事です。コードを書いていないとだんだんと見積もりの精度や技術的な難易度に対する勘が鈍くなり、自信を持って捌けなくなる場面が多いと感じています。アプリを作り始めてから、少なくともAndroid関連の案件であれば（判断が正しいかどうかはともかく）自信を持って捌けるようになったと思います。

まだまだやりたい事がたくさん溜まっています。現在のところ30項目ほどあります。十分時間が取れないのでなかなか消化できません。それどころか、どんどん増えていきます。

2011年の1年間に限っていうと、年間の目標としては、
1.ダウンロード数：25万
2.女子ウケ
3.日本以外でのユーザを増やす
でした。
1.については目標まであと8000というところまで来ましたが、残念ながら達成できそうにありません。2.はピンクの画面を作ってみましたということで頑張ってみました。達成できたかどうかは指標がないのでわかりませんが、某電話会社の女性向けスマホキャンペーン用パンフレットに何度も掲載していただいたので、広告制作側の方からは一応認識していただいたのではないかと勝手に思っています。3.については完全に失敗でした。たぶん、海外には日本国内よりも優れたサービスがあるからだろうと思っています。

2012年の目標としては、
・データのクラウドへの移行
です。単に自分がやった事が無いからやってみたいと、それだけのことです。実現したらかなり便利になると思いますが、そんなことはどうでもいいです。

ところで、元々このアプリは自分で使うために作り始めたのですが、実はもう自分はデバッグ以外では使っていません。元々陸上部で短距離をやっていたので長距離は性に合わないのです。

そんなわけで、今後もチマチマ作り続けていくつもりです。飽きたら他のネタやります。

AccountManagerから取得したauthtokenを使用するとFusion Tablesへのアップロードに失敗する件

2011-12-28T15:30:00.000+09:00

ユーザの認証情報を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のパターンはわかりますよね。ということで省略。

地味だけど重要な変更

2011-11-27T23:46:00.001+09:00

久々に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

・広告モジュールが動作するために必要としています。

android.permission.ACCESS_NETWORK_STATE

・データの送信および、広告モジュールが動作するために必要としています。

android.permission.INTERNET

・定期通知のために必要としています。

android.permission.VIBRATE

・画面OFF時にCPUがスリープしないようにするために必要としています。

android.permission.WAKE_LOCK

・バックアップデータをSDカードに出力するために必要としています。

android.permission.WRITE_EXTERNAL_STORAGE

・ANTデバイスを制御するために必要としています。ANTデバイスをサポートする端末でのみ有効です。

com.dsi.ant.permission.ANT_ADMIN

com.dsi.ant.permission.ANT

----

・Android 2.1以降でサービスをフォアグラウンドに設定

これまで、計測中に動作するサービスはService.setForeground()を使用していました。これって、APILevel4までしか有効じゃなかったんです。Level5以降はService.startForeground()なるものが用意されていましたが、Reflectionを使わないと1apkで複数のバージョンに対応できなかったので、面倒臭がって対応していませんでした。今回、Reflectionを使ってService.startForeground()に対応しました。やり方はここに書いてある通り。これで、画面がバックグラウンドにまわったら落ちやすい、とかいう現象が解消されるのではないかと期待しています。期待しているだけで、絶対大丈夫とは言いませんし、自分の場合、落ちやすい現象を再現できないので気休めだと思っています。

・Android 2.1以降で端末のGoogleアカウントと連動
APILevel5以降で使用可能になったAccountManager対応をしました。AccountManagerを利用することで、ユーザは以下のメリットを受けることが出来ます。
・アカウントとパスワードをこのアプリケーションのためだけに再入力が不要になる。
・このアプリケーションがアカウントとパスワード情報をどこかに送信しているのではないかという不安を解消できる。

ちなみにLevel4以前ではAccountManagerが利用できないので既存の動作と同じです。両方のバージョンに対応するのは面倒なので、早くLevel4以前の端末には爆発して欲しいです。っていうかもう対応しちゃったんでどうでもいいです。

・Android 2.1以降で過去に端末内に保存したGoogleパスワードの削除

もうこのアプリケーションでは保存する必要がなくなったので自動的に消します。

あと、どこにも記載していませんが、こっそりminSDKVersionを3から4に変更しました。さようならLevel3。たぶん、影響を受けるユーザのほとんどはHTC myTouch3Gかと思われます。でも、大丈夫。最近のAndroid MarketはマルチAPK機能をサポートしているのでLevel3の端末からでも旧バージョンのSmartTrainingはインストールできるはずです。マルチAPKマンセー。

AccountManagerのgetAuthToken()をReflectionでヤッてみた

2011-11-20T01:33:00.000+09:00

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
  */
 public void getAuthToken(String acc, String passwd, String service)
 {
  try {
   // AccountManagerクラス取得
   Class accountManager = Class.forName("android.accounts.AccountManager");

   // Accountクラス取得
   Class account = Class.forName("android.accounts.Account");

   // AccountManagerCallbackのクラス取得
   Class accountManagerCallback = Class.forName("android.accounts.AccountManagerCallback");
   
   InvocationHandler handler = new MyInvocationHandler();
   
   @SuppressWarnings("rawtypes")
   Class[] proxyInterfaces = new Class[] { accountManagerCallback };
   Object accountManagerCallbackInstance = Proxy.newProxyInstance(
     accountManagerCallback.getClassLoader(), 
     proxyInterfaces, 
     handler);

   if ( accountManagerCallbackInstance == null )
   {
    Log.w(Define.TAG, "accountManagerCallbackInstance is null");
    return;
   }
   
   // getメソッド
   Method get = accountManager.getMethod("get", Context.class);
   if ( get == null )
   {
    Log.w(Define.TAG, "get is null");
    return;
   }
   // AccountManagerクラスインスタンス取得
   Object accountManagerInstance = (Object)get.invoke(accountManager, context);
   if ( accountManagerInstance == null )
   {
    Log.w(Define.TAG, "accountManagerInstance is null");
    return;
   }
   
   // AccountManager.getAuthToken()メソッド
   Method getAuthToken = null;
   Method[] accountManagerMethods = accountManager.getMethods();
   for ( int i = 0; i < accountManagerMethods.length; i++ )
   {
    Method method = accountManagerMethods[i];
    if ( method.getName().equals("getAuthToken") )
    {
     // 引数の数とタイプが一致する関数を取得
     // TODO もうちょっとスマートな解決方法はないものか？
     // APILevel4以前の環境では引数の型特定にAccountだのAccountManagerCallbackだのを利用できないため、
     // こんな無様な方法で関数を取得している。
     Class[] types = method.getParameterTypes();
     if ( types.length != 6 )
      break;
     if ( !types[0].getName().equals("android.accounts.Account") )
      break;
     if ( !types[1].getName().equals("java.lang.String") )
      break;
     if ( !types[2].getName().equals("android.os.Bundle") )
      break;
     if ( !types[3].getName().equals("android.app.Activity") )
      break;
     if ( !types[4].getName().equals("android.accounts.AccountManagerCallback") )
      break;
     if ( !types[5].getName().equals("android.os.Handler") )
      break;
     //Log.d("TAG", "Found getAuthToken() method");
     getAuthToken = method;
    }
   }
   if ( getAuthToken == null )
   {
    Log.w(Define.TAG, "getAuthToken is null");
    return;
   }
   
   // AccountManager.getAccountsByType()メソッド取得
   Method getAccountsByType = accountManager.getMethod("getAccountsByType", String.class);
   if ( getAccountsByType == null )
   {
    Log.w(Define.TAG, "getAccountsByType is null");
    return;
   }
   
   // Accountクラスインスタンス取得
   Object[] accountObject = (Object[])getAccountsByType.invoke(accountManagerInstance, ACCOUNT_TYPE_GOOGLE);

   java.lang.reflect.Field name = account.getField("name");
   if ( name == null )
   {
    Log.w(Define.TAG, "name is null");
    return;
   }
   
   for ( Object ac : accountObject )
   {
    if ( name.get(ac).toString().equals(acc) )
    {
     //Log.d(Define.TAG, "getAuthToken.invoke() name : " + name.get(ac).toString());
     getAuthToken.invoke(
      accountManagerInstance, 
      ac, 
      service, 
      null,
      context,
      accountManagerCallbackInstance,
      null);
     return;
    }
   }
  } catch (ClassNotFoundException e) {
   e.printStackTrace();
  } catch (SecurityException e) {
   e.printStackTrace();
  } catch (NoSuchMethodException e) {
   e.printStackTrace();
  } catch (IllegalArgumentException e) {
   e.printStackTrace();
  } catch (IllegalAccessException e) {
   e.printStackTrace();
  } catch (InvocationTargetException e) {
   e.printStackTrace();
  } catch (NoSuchFieldException e) {
   e.printStackTrace();
  }
 }
}

class MyInvocationHandler implements InvocationHandler {
 @Override
 public Object invoke(Object proxy, Method method, Object[] args)
   throws Throwable {
  try {
   //Log.d(Define.TAG, "MyInvocationHandler#invoke() method : " + method.getName() + ", args.length : " + args.length);
   if ( method.getName().equals("run") && args.length == 1)
   {
    Class accountManagerFeature = Class.forName("android.accounts.AccountManagerFuture");
    Method getResult = accountManagerFeature.getMethod("getResult", null);
    if ( getResult == null )
     return null;
    Bundle bundle = (Bundle)getResult.invoke(args[0], null);
    String token = bundle.getString("authtoken");
    listener.onGotToken(token);
   }
  } catch (ClassNotFoundException e) {
   e.printStackTrace();
  }
  return null;
 }
}

InvocationHandlerとかProxy.newProxyInstance()とか初めて使ったでござる。
こんなのあったら何でもアリじゃねぇ？

いじょ。

AppLog対応しました

2011-10-04T18:29:00.001+09:00

2011/10/10　日本Androidの会10月定例会での発表内容を見た後で追記。

非常に残念な発表内容でした。
Androidの可能性そのものが潰されている気持ちでいっぱいです。
下記の内容を撤回します。

----
SmartTrainingでAppLog対応しました。
Twitterでもいろんな意味で盛り上がって（炎上？）いたり。 AppLogを検出するツールがでたり。
実際使ってみなきゃ意見を言ってもねぇ。ってことで、使ってみての感想です。

◆機能面

ログ送信確認画面の表示タイミングが不定。

サービス開始時に確認画面が表示されるわけではない。

どのアプリにAppLogが組み込まれているかわからない。

ユーザとのインターフェイスとして送信確認画面しかないので、このタイミングでどのアプリ経由でAppLogが動いているのかがわからない。

一度許可したら後で拒否するための方法がある。

Marketから「AppLog Opt-in」をインストールして拒否設定に変更できる。後付けで作ったのでこういう状態。いずれSDKに組み込んだほうが良さそう。

◆それぞれのメリット・デメリット

開発者

メリット

月額報酬 or 収集したログのいずれかが貰える。まだ導入して間も無いので何ももらえてないけど、ログを使って新しい視点で今後の開発に活用していければいいな、と。これまでこういうサービスはなかったので貴重だと思う。（似たような情報はGoogleも収集しているはずだけど、Android端末に関する情報は提供されていないはず）ただ、実際何にどう使えるかは未知（データを見てないので）。

デメリット

ちゃんとユーザに説明しないと拒否反応に合う。
当初、Marketの更新情報に「微調整」と書いたことで不評を買ってしまいました。まぁ、ユーザ観点でみたら気持ちいいものではないので、面倒くさがらずにちゃんと「AppLog入ってます」って書くべきだったか。反省してコメント修正しました。

ユーザ

メリット

直接的には無い。間接的にはあるかもしれないが、結局開発者次第か。

デメリット

気持ち悪いと感じられる人には気持ち悪く感じられる。

◆感情面

「ログを取ってもいい？」って聞かれるだけで無条件で拒否反応を示す人は確実にいる。それは理解できる。

◆その他

AppLogサービス紹介サイトに英語版を追加して欲しい。英語圏のユーザに対しても説明が必要。（欲を言うならそれ以外の言語も）
まだこのサービスは始まったばかりで、今後どうなるかはわからないが、新しい試み。

AppLogはリスクをとって新しいビジネスモデルを模索してチャレンジしている。
応援したい。

Android向けリク美女カレンダー非公式クライアント「RKBJ」リリースしました

2011-09-23T07:41:00.008+09:00

リク美女カレンダーがイイので、非公式にAndroid向けクライアント作りました。
ダウンロードはこちらからどうぞ。

アイコン他、レイアウト等、各種リソースは他アプリの使い回しという雑な仕様だけどいいじゃないか。
リク美女が見れればそれでいい。
RKBJはリク美女カレンダーを応援しています。

技術的には、
・TagsoupでHTMLパース
・CalendarViewをライブラリ化して利用
・最初からFragmentを使って実装
ってあたりが自分にとって新しい点です。

今時は必要な部品が全部揃っているので楽ですね。
設計＋実装＋試験で工数は7人時くらいでした。
たぶんまだ動作がこなれていないかも。
まぁ、いいか。

あと、使ってみてCalendarViewにサムネイル画像を埋め込みたいな。
「もえちゃん何日だっけ。。。」とかなる。
そのうち対応します。

ANT+なセンサー対応4つ目

2011-09-19T22:14:00.004+09:00

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

オープンコーラ事始め

2011-09-15T19:18:00.005+09:00

@LuckOfWiseさんが開催されていたオープンコーラが楽しそうだったので、いろいろと調べていたら材料が高い高い。全部揃えると送料込みで2万円なんだとか。
などとTwitterに投げていたら@LuckOfWiseさんから材料譲りますよ、とのありがたいお言葉が。
じゃ、遠慮なく、ということで送って頂きました。
※オープンコーラについて詳しくはググレカス。

必要な材料はだいたい揃っているようです。
しかも、ご丁寧にスポイトまで厳重に包装していただいてます。全てのオイルは丁寧に個包装されており、きっと、大変だっただろう、と思われます。

というわけで、まずは箱を空けて今回はおしまい。
ちなみに、会社に着払いで送って頂いたら、勝手に会社のほうで送料を立て替えておいてくれたらしく、このままほっとこうかと密かに考えているわけはないです。

Mixi Voiceに対応してみました

2011-08-27T07:09:00.007+09:00

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くらい認めてよ。それでサポートやってんだからさ。

いっぱい文句言ってごめんなさい。
というわけでやっつけ仕事のソースです。

まずは、Mixi投稿だけをするカラのActivity。こいつをService側からStartActivity()してやればいい。いや、カラじゃないか。




public class SendMixiVoiceActivity extends Activity implements CallbackListener {



    private static final int CODE_MIXI_VOICE = 0;

    public static final String KEY_MESSAGE = "key_message";

    private MixiVoiceManager mvm;

    private String message;

    private Context context;

    /**

      * 画面生成時処理

      */

    @Override

    public void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        // 引数取得

        Bundle extras = getIntent().getExtras();

        message = extras.getString(KEY_MESSAGE);

        // 初期化

        context = this;

        mvm = new MixiVoiceManager(context){

            @Override

            public void onFinishSend() {

                finish();

            }

        };



        if ( !mvm.isAuthorized() )

        {

            // セッションなし：認証開始

	    mvm.authorize(

	        this, 

	        new String[] {"w_voice"},

                CODE_MIXI_VOICE, 

	        this);

        }

        else

        {

            mvm.send(message);

        }

    }

    @Override

    public void onComplete(Bundle values) {

        mvm.send(message);

    }

    @Override

    public void onCancel() {

        finish();

    }

    @Override

    public void onFatal(ErrorInfo e) {

        finish();

    }

    @Override

    public void onError(ErrorInfo e) {

        finish();

    }



    @Override

    public void onActivityResult(int requestCode, int resultCode, Intent data) {

        super.onActivityResult(requestCode, resultCode, data);

        mvm.authorizeCallback(requestCode, resultCode, data);

    }



    // 呼ばれる保証のないonDestroy()で後始末処理しても意味ないんじゃない？onPause()でやったらいいんジャマイカ。

    @Override

    public void onDestroy() {

        mvm.close(this);

        super.onDestroy();

    }

}

次はMixi投稿を管理する自作のMixiVoiceManager（Activity側に処理いれてしまえば別にこんなの作んなくてもいい。）


public abstract class MixiVoiceManager {



	private MixiContainer mContainer;

	private Context context;



	public abstract void onFinishSend();

	

	/**

	 * コンストラクタ

	 * @param context

	 */

	public MixiVoiceManager(Context context)

	{

		this.context = context;



		Config config = new Config();

		config.clientId = "Mixi Developer Centerに登録したID";

		config.selector = Config.GRAPH_API;



		mContainer = MixiContainerFactory.getContainer(config);

		if ( mContainer == null )

			onFinishSend();

			

		if ( !mContainer.init((ContextWrapper)context))

			onFinishSend();

	}



	/**

	 * 認証処理

	 * @param activity

	 * @param permissions

	 * @param activityCode

	 * @param listener

	 */

	public void authorize(Activity activity, String[] permissions, int activityCode, CallbackListener listener)

	{

		mContainer.authorize(activity, permissions, activityCode, listener);

	}



	/**

	 * Voice投稿

	 * @param voice

	 */

	public void send(String voice)

	{

		Map params = new HashMap();

		params.put("status", voice);

		mContainer.send("/voice/statuses/update", HttpMethod.POST, params, new CallbackListener(){



			@Override

			public void onComplete(Bundle values) {

				Toast.makeText(context, R.string.message_success_send_mixi_voice, Toast.LENGTH_LONG).show();

				onFinishSend();

			}



			@Override

			public void onCancel() {

				onFinishSend();

			}



			@Override

			public void onFatal(ErrorInfo e) {

				Toast.makeText(context, R.string.message_fail_send_mixi_voice, Toast.LENGTH_LONG).show();

				onFinishSend();

			}



			@Override

			public void onError(ErrorInfo e) {

				Toast.makeText(context, R.string.message_fail_send_mixi_voice, Toast.LENGTH_LONG).show();

				onFinishSend();

			}});

	}



	/**

	 * 認証状態チェック

	 * @return

	 */

	public boolean isAuthorized()

	{

		return mContainer.isAuthorized();

	}



	public void authorizeCallback(int requestCode, int resultCode, Intent data)

	{

		mContainer.authorizeCallback(requestCode, resultCode, data);

	}



	public void close(Context context)

	{

		mContainer.close((ContextWrapper) context);

	}

}

そんな感じ。

さようならFacebook

2011-08-20T16:05:00.007+09:00

以前、SmartTrainingからFacebookのウォールに投稿する機能に関して書きました。
面倒、面倒と文句を言いつつもちゃんと投稿することができて「Facebookに対応してよかったこと」などというフォローの投稿も書きました。
しかし、今こう思っています。「さようならFacebook」

理由：
2011/7/12をもってアプリ側が生成した文字列をウォール投稿用のテキストボックスに自動設定することを不可にしたから。
情報ソース

[何か書く...]の下のEditTextにアプリから文字列を設定できなくなった。

文字はめんどくさがらずに全部手で入力しろ、だってさ！バカじゃねぇの？どうしてそんなに閉鎖的なのよ？何のためにデベロッパにハッシュキー登録だの面倒な手続きでアプリ登録させてアプリの認証をやってるのよ？Facebookへのアプリからのアクセスを信頼するためじゃないの？何がTwitterやFourSquareと並んで新しいタイプのIT企業だ。ただ閉鎖的なだけじゃないか。こういう意味ではGoogleの「何でもオールオッケー！でも後で問題があったら消すからね」的なスタンスの方が付き合いやすくて周囲に様々な可能性を提供してくれているんだなぁ、と思います（まぁ、いろいろ批判はあるみたいだけど）。それにしてもFacebook、ユーザーが何億いるか知らないけど小さい！本当に小さいね！

もういいよ、さようならFacebook！

ハニコム対応戦略　〜その3〜　やったことざざっと

2011-07-23T05:46:00.003+09:00

前回はどんな感じで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.v4.app.FragmentActivity　→　Activity継承のクラスはFragmentActivity継承に切り替える。
　android.support.v4.app.FragmentManager
　android.support.v4.app.FragmentTransaction
　
5.Phone/Tabletでの画面レイアウトの切り替え
　PhoneとTabletで画面レイアウトを切り替えるために利用できる簡単な方法はLayout xmlをフォルダで分けることです。
　例えばこんな感じ
　　res/layout/main_activity.xml ・・・・・・ Phone用Activity
　　res/layout-land-v11/main_activity.xml・・・Tablet横向き用Activity
　トップ画面はランチャーから呼び出されるActivityがひとつなので、レイアウトで切り替える感じ。
　
6.Phone/TabletでstartActivity()するActivityクラスの切り替え
　PhoneとTabletで呼び出すActivityをそれぞれ実装してstartActivity()のタイミングで呼び出すActivityを切り替えることができます。
　例えばこんな感じ


　Intent intent;
　if ( UIUtils.isHoneycomb() )
　　intent = new Intent(getActivity(), ForTabletActivity.class);
　else
　　Intent intent = new Intent(getActivity(), ForPhoneActivity.class);
　getActivity().startActivity(intent);

　
※UIUtilsについてはGoogle I/O 2011公式アプリ参照のこと。

7.FragmentとActivity間のやりとり
こんな感じでActivity側にコールバックを実装する。


 public interface PhotoListEventsCallback {
  public void onThumbnailSelected(PhotoData photo);
  public void onThumbnailSelected(List list, int position);
  public void onNextImage();
  public void onPrevImage();
  public void onChangeFavorite(FavoriteDataList favorites);
  public void onStartProgress();
  public void onStopProgress();
 }

ハニコム対応戦略　〜その2〜　Tablet対応する際の機能マッピング戦略

2011-07-21T23:04:00.006+09:00

前回はハニコム対応したアプリケーションの基本機能を紹介しました。
今回はTablet対応した際にPhone上で実現していた機能をどういう風にTablet上で表現するかを説明していきます。

まずは実際に対応を完了したアプリの画面を見ながら結果的にどうなったのかを説明していきます。

◆Tablet用画面
・画面を左右2分割して左側にサムネイル用のGridView、右側に選択した画像の高解像度表示を行います。
・画面上部にはActionBarを配置して、左上にはアプリケーションロゴと名称。右上には各機能呼び出し用のボタンを表示します。
・画面下部にはサムネイルの切り替え（ランキング／お気に入り）ボタンと、全ユーザのお気に入り登録回数とお気に入り登録ボタン（☆）を表示します。
・画面右下にリング型のProgressBarを配置して、サムネイル更新中または高解像度画像ダウンロード中はProgressBarを表示します。

フレーム表示だとこんな感じ

◆Phone用画面
基本的には対応前と変わりませんが、以下の点が変わります。
・タイトルバーの代わりに、ActionBarっぽい感じで独自レイアウトのバーを画面上部に表示します。
・詳細画面でアプリロゴを選択するとホーム画面(サムネイル画面)に戻ります。
サムネイル画面

サムネイル画面フレーム

詳細画面

詳細画面フレーム

☆基本戦略
◆Tablet画面
・サムネイル画面と画像表示画面をひとつの画面に固めることで画面遷移をなくす。
・画面下部に配置していたボタンのうち、よく操作するものをActionBar内に配置する。

◆Phone画面
・Tablet画面と画面デザインを合わせるため、タイトルバーに相当するバーの高さをTabletのActionBarと同じ高さにする。
・その他よく使用するボタン配置は使い勝手を優先して位置を変更しない。

だいたい以上のような感じになります。
次回はもう少し具体的に実装面で考慮すべき点をまとめようと思います。

ハニコム対応戦略　〜その1〜　今回対応するアプリ

2011-07-21T22:36:00.008+09:00

画像閲覧アプリBeautyAlbumをハニコムTablet対応してみました。
今回から数回に渡って、Phone向けのアプリをPhone対応を残しつつハニコムTablet対応する手順と気にしなくてはいけない点をまとめてみます。
結論から言うと、Google I/O 2011公式アプリがベストプラクティスなのでそちらを参照して真似るのが一番良いと思います。
なので、あまり細かい実装の話はしません。
さらに、こことかここ見たほうが良いと思います。
この場では、「私のアプリの場合こうしました」という具体例を示します。
また、絶対こうしなきゃいけないわけではありませんので、ご自分のアプリの性格をよく考え、どういう対応をするのか（またはしないのか）を考えてくださいね。

というわけで、まずは対応する前の元のアプリの機能を簡単に紹介します。

アプリはAndroid Marketからダウンロードできます。
サムネイル表示画面で画像を選択すると画像が拡大表示され、その画像をお気に入りに登録したり、他のアプリに共有したりすることができるといういたってシンプルなものです。

【サムネイル画面】
・ネットワーク上から画像のサムネイルをダウンロードしてGridViewに表示します。
・サムネイルダウンロード中は画面右上のタイトルバー上にリング型のProgressBarを表示します。
・画面下部に他のユーザのランキング表示と自分のお気に入り表示の切り替えボタンを配置してあります。
・Menuキーを押すことでAboutダイアログを表示します。

【詳細画面】
・サムネイルを選択すると画面遷移して高解像度の画像をダウンロードして表示します。
・画像のダウンロード中はサムネイル画面同様タイトルバー上にリング型のProgressBarを表示します。
・画面下部に他のユーザがお気に入り登録した回数と自分のお気に入りマーク(☆)を配置してあります。
・画面下部に画像の共有、ギャラリーアプリ起動、リスト上で次の画像、前の画像を表示する機能を呼び出すボタンが配置してあります。

◆UIの基本方針
次の方針でPhone向け画面設計を行っています。
・よく使用する機能は画面上にボタンを配置して呼び出すようにする。
・画面上のボタンは押下しやすいように画面下部に固めて表示する。
・Menuキーには滅多に使用することのない機能(About表示)を割り当てる。
・ProgressBarは全画面共通でタイトルバーに表示するようにする。

アプリケーションの機能的には以上です。
それでは次回以降、Tablet対応する際のUIの設計変更の考え方を説明していきます。

Mario with Widget

2011-07-11T19:09:00.004+09:00

I have created mario with widget.

* How do I create it?
- Download MuskedWidget from Android Market.
- Change Home application to Launcher Pro.
- Change Home screen numbers to 6.
- Change Home screen row and columns to 10x10.
- Arrange the widget.

I need 16x16 tiles on Home screen.
If it is 16x16, I can create a character on 1 screen!!

See detail.

ウィジェットでマリオ

2011-07-10T04:00:00.013+09:00

Android Bazaar and Conference 2011 Summer 「頑張れ日本、頑張れAndroid」ということでウィジェットでマリオ作ってみました。

☆作り方
・Android Market から MuskedWidgetをダウンロードする。
・ホーム画面上にひたすら色指定したウィジェットを並べる。
いじょ。

☆なんだそりゃ

意味分かんない人向け。
MuskedWidgetはホーム画面上にただの四角いウィジェットを生成するアプリです。
普通はこんな感じ。

色指定できるので、好きなところに好きな色のウィジェットを置いていきます。
普通のAndroidのホーム画面だと4x4しかウィジェットを置くことができませんね。
これじゃ、つまらない。
というわけで、かの有名なLauncher Proの登場。
このホーム画面は、10x10までウィジェットを置ける。
でも、マリオつくろうと思ったら、最低12x14はドットが必要。

足りん。

でもまだあきらめない。
Launcher Proは最大7画面まで拡張できて、ホームキーを押すと、各画面がサムネイル化される。

これだ。

6画面でサムネイル化したら、都合20x30までドットが取れるではないか。
というわけでできたのがこれ。

各ホーム画面の詳細はこちら。

さすがに夜中に600個ウィジェット並べる作業は疲れたよ。
っていうか、Launcher Proのフォーラムに最低16x16は欲しい、とか投稿しとこうかな。
あ、Launcher Proの設定でAuto-fit ItemsをONにしとくとわりと綺麗に敷き詰められるよ！

(Gallery起動的に)ハニコム対応したよｗみたいな

2011-07-04T00:43:00.009+09:00

Honeycomb端末手に入れました。
自分のアプリからGalleryアプリを起動しようとしたら異常終了してたので対応したよ。
FragmentだのActionBarだのはまだまだこの後。
っていうか、何とかしてくれ、このバージョン依存コードｗ
この手がダメならあの手であの手がダメならこっちから攻めてそれでもダメならHTCだろ--!!!みたいな。


// ギャラリー表示
Intent intent = null;
try
{
    // for Hanycomb
    intent = new Intent();
    intent.setClassName("com.android.gallery3d", "com.android.gallery3d.app.Gallery");
    startActivity(intent);
    return;
}
catch(Exception e)
{
    try
    {
        // for Recent device
        intent = new Intent();
        intent.setClassName("com.cooliris.media", "com.cooliris.media.Gallery");
        startActivity(intent);
    }
    catch(ActivityNotFoundException e1)
    {
        try
        {
            // for Other device except HTC
            intent = new Intent(Intent.ACTION_VIEW);
            intent.setData(Uri.parse("content://media/external/images/media"));
            startActivity(intent);
        }
        catch (ActivityNotFoundException e2)
        {
            // for HTC
            intent = new Intent();
            intent.setClassName("com.htc.album", "com.htc.album.AlbumTabSwitchActivity");
            startActivity(intent);
        }
    }
}

デ部9資料

2011-07-03T14:36:00.002+09:00

デ部9でANT+について話しました。
資料です。

MacでAndroid実機が認識されない(EasyTetherが原因)

2011-06-26T22:50:00.003+09:00

Mac歴6ヶ月。
MacでAndroidアプリ開発しようと思って使い始めたのに、どういうわけかDDMSが実機を認識してくれない。
原因がわかったのでメモメモ。

◆原因
EasyTether

◆解決策
KLinkに切り替える。
一度、EasyTetherを使ってしまったMacは以下の手順で設定ファイルを削除する必要があります。
詳しくはKlinkの「Set up your Computer」参照。
> rm /System/Library/Extensions/EasyTetherUSBEthernet.kext
> reboot

◆お断り
本記事は、Androidでテザリング機能が標準搭載されない時代の話です。
まもなくWiFiテザリングが標準搭載される機種が大量に発売されるはずです。
そんな端末を持っていればここでの話でハマる必要もないでしょう。

◆詳細
開発者はEasyTetherを使うな
EasyTetherはとても良くできたアプリだと思います。
Android側でUSBをEnableしておいて接続するだけでネットワーク接続されます。
普通にMacでUSBテザリングするにはベストチョイスかと思います。
でも、Macを使う上ではEasyTetherはUSB接続されたタイミングで、
ネットワーク設定を強制的に書き換えてしまうため、
DDMSで認識されなくなってしまいます。
そんなわけでKlinkを使うことにしました。

おしまい。

ANT+ なセンサーに対応してみました

2011-05-27T12:39:00.005+09:00

ここしばらくANT/ANT+について調べていましたが、ようやくSmartTrainingにANT/ANT+対応機能を乗せてみました。

とりあえずできるのはFoot Podで計測した歩数および距離データをスマトレ側で扱えるようにしたこと。
スマトレの万歩計の精度が悪いとお嘆きのアナタ！本物のセンサーのデータが利用できるようになりましたよ！
っていうか、事実上Xperia arcはスリープ中に万歩計が動かないので、Foot Podを利用すれば大丈夫！みたいな感じです。

自分の理解では、
・ANTは近距離無線の規格。
・ANT+ではプロファイルを定義して一定の種類のセンサーのデータの受け渡しフォーマットを規定。
です。

ANTなセンサーからデータを受け取るには、
・ANT対応のAndroidが必要。
・ANT Radio Serviceのインストールが必要(Marketで見つかるよ)
・ANT API for Androidを扱うアプリケーションを作る。
　ANTセンサーから取得したデータはANT+の仕様に則ってパースする必要がある。
　仕様はThis is antサイトにDeveloper登録することで入手できる。
ってな感じです。

ANT+の仕様はオープンなので仕様書を読めばパースの方法はわかるのですが面倒(オイオイ)。
そんな時は、Wahoo Fitnessが提供する「Wahoo Fitness API」を利用することでパース処理を書かなくてもデータが取得できるようになります。
つっても、デバイスをほぼ直接制御するので接続、切断なんかの概念を理解するのにはやっぱり基本がわかってないと辛い。Wahoo Fitness APIはWahooの中の人にメールしたらくれました。ただし、「Garminのセンサーで動くよ！」って宣伝しないといけないという制約が付いてきちゃいますが。

Garmin以外のセンサーについては、試してないので利用できるかは知りません。
でもANT+はプロファイル含め規定されているので大丈夫なんじゃないかな！たぶん。

あと、ANTなセンサーは電波を発する機械ですので日本国内では総務省が認可したデバイスじゃないといけないらしいです。技適マークってのがついてるヤツ。
Xperia mini x10なんてのも見たけど技適マークないしなぁ。むむむ。

お上に引っ立てられないようにお気をつけて。

IS03とDesire比較(IS03リベンジ編)

2011-04-14T12:51:00.005+09:00

IF03とDesire比較で、Eclair時代のIS03の性能を評価していましたが、この度、IS03がFroyoにバージョンアップしたので、もう一度ベンチマークやってみました。例によって、ザクっと触っただけだから深刻に受け止めないでね。
結果は以下。

◆結果
I：IS03(Eclair)
D：Desire
If：IS03(Froyo)
を意味する。

1.定量的比較
　◇結果
　　※数値がデカイ方が速い。
　　・Linpack(Mflops)
　　　I：6.01
　　　D：38.5
　　　If：37.33
　　・Composite
　　　I：7.06
　　　D：48.7
　　　If：47.71
　　・Fast Fourie Transform
　　　I：4.97
　　　D：30.5
　　　If：30.36
　　・Jacobi Successive Over-relaxation
　　　I：13.3
　　　D：107.8
　　　If：103.69
　　・Monte Carlo integration
　　　I：1.53
　　　D：8.43
　　　If：8.04
　　・Sparse matrix multiply
　　　I：6.84
　　　D：38.1
　　　If：38.08
　　・dense LU matrix factorization
　　　I：8.67
　　　D：58.7
　　　If：58.39
　　・Draw canvas
　　　I：27.0
　　　D：60.6
　　　If：28.80
　　・Draw Circle
　　　I：29.0
　　　D：58.3
　　　If：29.84
　　・Draw Cube
　　　I：27.3
　　　D：46.3
　　　If：28.45
　　・OpenGL Blending
　　　I：28.3
　　　D：47.6
　　　If：29.38
　　・OpenGL Fog
　　　I：28.5
　　　D：47.5
　　　If：29.41
　　・Flying Teapot
　　　I：28.9
　　　D：19.3
　　　If：19.05

2.定量的比較
面倒なのでざっくり感触だけ。
んー、なんか少しレスポンスは良くなったかな？
でも、Desireほどじゃない気はする。

◆まとめ
演算系(DrawXX,OpenGLXX以外)はDesire並に高速化された。
描画系(DrawXX,OpenGLXX)はあんまり変わらない。
感覚的にはレスポンスよくなったかも。Desireほどじゃないけど。

Google Apps Device Policyはじめました(冷やし中華風に)

2011-04-12T23:16:00.010+09:00

企業ユースではイマイチセキュリティ面で弱い、とされているAndroid。（ここでいう「セキュリティ」とは端末紛失時のデータ漏洩への対策という意味ね。ウイルス対策とかの話はここでは無関係）
そんなAndroidのセキュリティ強化ソリューションの一つであるGoogle Apps Device Policy試してみました。
詳しくはこちら。
以上！

とかいうのはアレなので実際に使うまでに必要なことと出来ることをまとめてみます。

■必要な準備
☆管理者がすべき準備
・ドメインの管理権限を持っている必要がある。
・ドメイン内DNSにCNAMEレコードを追加できる、または、ドメイン内のWebサーバにコンテンツを追加することができる。
・Google Appsに自ドメインを登録して利用開始する必要がある。ドメイン登録の際、ドメイン管理権限を持っていることを証明するため、上記CNAMEレコードの追加またはWebサーバにコンテンツを追加することを求められる。
・Google AppsのEditionをBusinessまたはEducationにアップグレードする必要がある。Businessにアップグレードするためには、年間1アカウントあたり50ドルかかる。
・Editionアップグレード時にクレジットカードの入力を求められる。(1ヶ月間の評価期間中は請求されない。それまでキャンセル可能。)
・モバイルサービスの設定で端末の設定を行う必要がある。
　端末の設定はいわゆるセキュリティポリシーの設定です。詳しくは「できること」参照。
・Google Appsに各ユーザーのアカウントを登録する必要がある。

☆各ユーザーがすべき準備
・管理者が登録したアカウントでGoogleに一度ログインする。
・Android2.2以上を持っている必要がある。
・Android端末にGoogle Apps Device Policyというアプリをインストールする必要がある。Android Marketからダウンロード可能。
・Google Appsに登録したアカウントをGoogle Apps Device Policy設定時に選ぶ。

■なにが起こるか
・端末がGoogle Syncすることで、管理者が設定したセキュリティポリシーが端末に強制適用されます。

■できること
セキュリティポリシーの設定画面イメージは以下。

Androidだと緑色の小さいアイコンがある奴だけが利用出来る。
・端末へのパスワード設定をユーザーに要求
・パスワードの安全度を2段階(普通、強)から選択可能。
・パスワード最少文字数
・自動的に端末をロックするまでの時間
・誤ったパスワードを入力された際に端末をワイプするまでの回数
・ユーザを指定して任意のタイミングでリモートワイプ
・Android3.0だと端末内データの暗号化が利用可能
・ほかにもGoogle Apps Lookupとかが利用出来るみたい。
・My Deviceを利用すると紛失した端末の場所を地図上に表示したり、電話をかけたりすることができる。

■感想
・BlackBerry Enterprise Serverのセキュリティポリシー設定数が500項目近いことと比較すると機能的な充実度は圧倒的にBlackBerryの方が高いが、Androidだと最低限パスワードの強制適用とリモートワイプはできる。細かい設定したってどうせ使いこなせないんだったら、これで十分でしょ。みたいに思えなくもない。オレ、IT管理者じゃないから適当なこと言ってるけどｗ
・ドメイン登録あたりはちょっと面倒だけど、そこさえ通過すれば、何もサーバだのハードウェアだのを準備する必要がない。DNS立てられればそれでOK。思い立ったその日に環境を整えることができる。恐ろしいほど手軽に利用開始できる。ちょっとしたセキュリティ対策ソリューション用のサーバを構築するのと比べたら雲泥の差だ。
・自動的にGmailだのGoogleカレンダーだのがグループウェア的に利用出来るし、当然Androidとも何の違和感もなく連携する。うちの会社もこれ使えばいいのに。って本気で思う。きっとわけのわかんないウンコみたいな某リモートWebメールなんかより不正アクセスに対する強度は確実に高いし、死ぬほど見やすくて、メールの処理能力がハンパなく高い。
・パスワード強制されるのがウザイ。これだけでAndroid端末使うモチベーションが半減する。（まぁ、ある程度しょうがないんだろうけどｗ）

そんなかんじ。

翻訳リソースキター！

2011-04-11T12:52:00.009+09:00

ちょっと前にSmartTrainingにlibandrotranslationを組み込んで、英語、日本語以外もまともに対応していこう、と思っていました。

libandrotranslationについて詳しくはこちら。

誰からも何も来なかったらそれはそれでネタにしようと思っていましたが、ついに対応から1ヶ月？ようやく初めての翻訳リソースが来ました！
来た言語_国は、「pt_BR」。。。何それ、、、初めて見た。
調べてみたらそれは、ptはポルトガル語、BRはたぶんブラジルじゃない？
ブラジルといえばこれっていうか、遠すぎてよくわかんない、アツい、サッカー、鉄鉱石、くらいしか。
でもGraças, Graças。開始ボタンだけポルトガル語らしい。

SmartTrainingはジーコを応援しています。

Xperia Arcで画面レイアウトが崩れる時ー！崩れる時ー！（いつもここから風に）

2011-04-11T11:29:00.004+09:00

Xperia Arc上でSmartTrainingを起動すると画面が崩れるという問い合わせがあったので対応してみました。
実機を持っていないので、強力な協力者(ええ、ダジャレですがなにか)にも支援いただきました。感謝。

■原因
AndroidManifest.xmlの記述がanyDensity=falseになっていた。

■対応
AndroidManifest.xmlの記述をanyDensity=trueに変更した。いじょ。

■副作用
MapView上のOverlayItemのサイズが解像度に依存してしまう。
→dimens.xmlでdp指定したサイズを読み込んで描画することで対応。

■経緯
詳しくは協力者のるるるさんのブログ参照。
Twitterで呼びかけたところ、るるるさんにご協力いただくことになりました。何度も何度もインストールとキャプチャ繰り返していただき本当にありがとうございました。

開発者視点で書くと、
・ヒアリングした状況
　・画面レイアウトが崩れる。
　・トップ画面だけ崩れる(他画面もほぼ同じ作りなのに)。
　・一度崩れた画面でも画面遷移で戻ると直る。
・試したこと
　・一部の文字のサイズ指定がdpになっていたので、sp指定に変更。
　　→変化なし。
　・SingleLine=trueのオプションを追加
　　→ボタン文字列が2行に渡ることは無くなった。でも字がデカイまま。
　・文字のサイズ指定そのものを小さくするように変更。
　　→確かに小さくはなったが、許せん。
　・「Xperia Arc 画面崩れ」でググると、Spare PartsのCompatibility ModeをOFFにすると直るとの情報。
　　→画面の表示のズレを解消するアプリ「Spare Parts」
　　→現象が発生しなくなることを確認。ってことはアプリ側の設定が古いバージョン向けになってるのね。というところにたどり着きました。

元々、SmartTrainingのAndroidManifest.xmlはこうなっていました。
＜uses-sdk android:minSdkVersion="3" /＞
＜supports-screens
android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:anyDensity="false" /＞
古いアプリなので、今時、minSdkが3となっています。そして、できるだけ広い範囲のデバイスで動作して欲しいのでsupprots-screensも書いてあります。
anyDensityがfalseだとシステム側がいい塩梅で適当にやってくれるので楽～。だったのですが、Xperia Arcさんは「昔のことなんて覚えてねぇぜ(いや、時々忘れちゃうぜ、が正しいか)」とばかりにこの設定を無視してくれるので、画面が崩れます。
というわけで、こいつをtrueにして対応だん。

、、、としてリリースしたのですが、MapView上のOverlayItem(このアプリでいうと、ラリー画面の吹出しみたいなやつが該当します)が解像度に応じてサイズが大幅に変わる、という現象に気付いてしまいました。（ええ、テストしていませんがなにか）

原因は簡単で、OverlayItemの描画をコード上で生々しく数値で座標指定していたのに、anyDensity=trueになってしまったから。例えて言うなら、農業保護政策がいきなり撤廃されて、それまで国外からの安い農産物が大量に輸入されるのが防がれていたのが、なくなっちゃった状況です。しょうがないね、ということで、dimen.xmlにdp指定で座標を定義してそれを読み込むことで解決。
→答えはぜんぶここに書いてありました。「Y.A.M の雑記帳 Android multi screen 対応」さすがです。