GrandNature

Hibernate Validatorで調べると、日本語ではなぜかこのサイトが一番上に出てきます。不思議ですが、せっかくなので自前のValidatorを作る方法を載せておきます。とても簡単です。

　ちなみにHibernate Validatorを使ったバリデーションは、org.hibernate.validator.ClassValidatorなどを使って明示的に実行すれば、エンティティに限らずどんなJavaBeanでも使えます。対象のクラスのことをHibernateが知っている必要はありません。

まずアノテーションから

@Documented
@ValidatorClass(StringDateValidator.class)
@Target({METHOD, FIELD})
@Retention(RUNTIME)
public @interface StringDate {
　　String message() default "{errors.date}";
　　String pattern() default "yyyyMMdd";
}

実装クラスはこんな感じです。

public class StringDateValidator implements Validator, Serializable {
　　private static final long serialVersionUID = -7262522203009002581L;
　　private String pattern;
　　public void initialize(StringDate parameters) {
　　　　pattern = parameters.pattern();
　　}
　　public boolean isValid(Object value) {
　　　if ( value == null ) return true;
　　　if (!(value instanceof String)) return false;
　　　String str = (String) value;
　　　if(str.length()==0) return true;
　　　SimpleDateFormat sdf = new SimpleDateFormat(pattern);
　　　sdf.setLenient(false);
　　　try {
　　　　sdf.parse(str);
　　　} catch (ParseException e) {
　　　　return false;
　　　}
　　　return true;
　　}
}

こんな感じでアノテーションと実装のセットを作るだけで使えます。楽チンですね。

色々と話題になっているAndroid 0.9 SDK beta ですが、Android Developers Blogの“Some information on APIs removed in the Android 0.9 SDK beta”を、日本語にしたものを参考までに載せます。

Android 0.9 SDK betaから削除されたAPIについて　2008/8/25 Dan Morrill

今週の初めに、我々はAndroid SDKのベータ版をリリースしました。以下の（前回の）投稿では、Android1.0に向けていくつかのAPIを削除しなければならなかったこと、そしてその結果として、それらのAPIは0.9 beta SDKにも含まれていないし、1.0互換のSDKにも含まれないであろうことについて触れました。今回は、何故そのようにしたのか、その理由について少し説明したいと思います。

・GTalkService

「XMPPService（当初はそう呼んでいました）」が初回のearly-look版SDKに含まれたことは、とてもエキサイティングなことでした。しかしながら、セキュリティをレビューするチームに評価を依頼したところ、彼らはすぐに気付きました。GTalkServiceは、エキサイティングであるのと同じくらい、いくつかの基本的なセキュリティ上の問題を抱えているということに。我々のセキュリティ研究者の一人であるRich Canningsは、この点について以下のように述べています。

GTalkServiceに初めて触れたとき、私はとてもエキサイティングな気持ちになりましたが、それと同じくらい怖い気持ちにもなりました。開発者としては、シンプルなインタフェースでGoogle Talkの友達（以下GTalk friends）との間でメッセージを送ることができる機能が提供されていることに興味を持ちました。メッセージは受信側のデバイスでは扱いが容易な標準のIntentとして取り扱うことが出来ます。なんてシンプルで美しいことでしょうか。しかし残念なことに、Tin Foil Hatをかぶった人（ヤヴァイ人）としてみたときには、このことはそれほど単純なことではないと認識しました。

我々は、以下に述べる理由により、GTalkServiceのデータメッセージングの機能を延期することに決めました。

1. GTalk friendsに複数の意図を持たせてしまうことについて
   GTalk friendsの目的（意図）は、GTalkServiceによって実現しようとしていることと異なります。あなたのGTalk Friendsは、いつでもIMを使ってあなたとコンタクトを取ることが出来ます。彼らはあなたのメルアドを知ることができますし、あなたの本名も知ることが出来るかもしれません。しかし、GTalk Friendsについての考え方は、必ずしもAndroidアプリケーションによってインタラクトしたい人々に対する考え方と合致しているとは言えないでしょう。例を挙げます。例えば、GTalkServiceを使った、とてもクールなモバイルの、大規模多人数参加型オンラインロールプレイングゲームがあると想像してみて下さい。あなたは、一緒にプレイするために、すべてのプレイヤーをあなたのGTalk Friendsに加える必要があるでしょう。そして、別のあるときに、あなたはWEBかデスクトップPCでGTalkにログインしたとします。あなたはたくさんの新しい「friends」がいることに気付くでしょう。あなたは彼らとチャットをしたいわけではないでしょう。そしてさらに悪いことに、彼らにあなたのメルアドや本名を知られたくないでしょう。Androidユーザーは、他のAndroidユーザーと、匿名で、かつ（特にゲームのシナリオのような）短い間だけインタラクトしたいのだと我々は気付きました。残念ながら、インスタントメッセージングがこのことに対する良い手段ではないと思います。
   
2. Intentの送信元を検証することについて
   Intentは、デバイス内でメッセージを送信するように設計されました。Intentサブシステムは、同じデバイスからIntentが生成され送られたときのみIntentの送信元を確実に解決することが出来ます。異なるデバイスからIntentが送られてきたときは、Intentサブシステムは、どのようなアプリがそのIntentを送ったのかを解決できません。このことは様々な問題を生み出す可能性があります。当初は、リモートのアプリケーションは任意のインテントを送信することが出来ました。このことはあなたのGTalk Friendsが、あなた自身と殆ど同じくらいあなたのデバイスを制御できたということです。この問題が解決されなければ、我々はリクエストの送信元となるアプリの身元を信頼することが出来ないだろうと判断しました。我々はそのユーザーの身元を信頼することが出来るだけです。つまり、あなたの友達のデバイスにインストールされている「悪い」アプリが、あなたのデバイス上の「よい」アプリにメッセージを送り、害をなすことが出来たということです。結局、Intentはローカルユースのために設計されており、RPCの伝達手段としては役に立たないものであると結論付けました。
   
3. セキュリティ面でのあまりに多くの負担を開発者に強いていることについて
   当初の設計では、GTalkServiceはセキュリティ面での欠陥を除去することや、ユーザーとのリレーションの管理をおこなうことをアプリ開発者に委ね、多くの負担を強いていました。GTalkServiceを使ったアプリには、すべてのGalk Friendsからアクセス可能です。そしてアプリに欠陥があれば、悪意を持った「friend」や、自動化されたマルウェアに対して恰好の標的となってしまいます。脆弱なアプリを保護したり、マルウェアの繁殖を防ぐことのできる自動化の仕組みは存在します。しかしこれらのテクノロジーの開発は最初のAndroidハンドセットを提供するまでには間に合いませんでした。
   

我々は、本当にこのサービスを提供したかったんです。しかし最終的に、Androidチームは、ユーザーを危険にさらしたり、将来提供されるよりセキュアな機能との互換性を弱めるのではなく、APIを取り除くことに決めました。我々はこのような機能が信じられないほど便利だということを十分承知しています。だから、いずれ開発者の方々にはたくさんの新たな扉を開くつもりです。最初のデバイスを提供した後の我々の最優先事項は、デバイス間（あるいはデバイスとサーバー間）の高速で、信頼でき、開発者やユーザーを保護できるRPCメカニズムを開発することです。

最後に、いずれにせよGTalkServiceはGoogleによって「価値が付けられた」サービスなので、全てのAndroidデバイスで動作することは保証していたわけではないということに私は言及したいと思います。つまり、GTalkServiceは決してAndroidのコア機能ではなかったということです。結果として、この変更は、Androidの将来のバージョンのコアの一部となる新しいシステムを我々が構築する可能性を開いたと言えます。

・Bluetooth API

Androidの1.0バージョンと、最初のデバイスはBluetoothをサポートする予定です。たとえばAndroidはBluetoothハンドセットをサポートするでしょう。early-look版のSDKでは、Bluetoothの基本機能は不完全なドラフト版のAPIとして開発者に晒されていました。しかし残念なことにこのAPIは1.0のリリースからは削除せざるを得なくなりました。その理由を知るために、私はNick Pellyとコンタクトを取りました。Nick Pellyはこの機能に対する責務があるAndroidエンジニアのうちの一人です。彼は以下のように語りました。

　理由は、我々に検討する時間が無くなってしまった事です。Android Bluetooth APIは順調に進捗していましたが、SDKにコミットするまでにはいくつか整理する必要があります。Bluetooth APIを1.0 SDKに組み込むためには長い時間を必要とするということを心に留めておいて下さい。

　APIの抱える問題の例を挙げます。クライアント側のコードでは、非同期でのコールバックを受けるためにIBluetoothDeviceCallbackオブジェクトを回す必要があります。しかしIBluetoothDeviceCallbackは内部的なインタフェースなはずです。新たなコールバックをIBluetoothDeviceCallback.aidlに加えた瞬間クライアントコードは破壊されてしまいます。これは将来的な運用に耐えるものではありません。

　さらに慎重を期すことになった要因としては、最近発表されたbluez 4.xシリーズでは新たにAPIが追加されているという点です。Androidとbluezのインタフェースに似ている点があることからも想像がつくでしょうが、Android Bluetoothでは、GAPとSDPのためにbluezを利用しています。bluez 4.xの変更によって、我々は将来的にAndroid Bluetooth APIをどう構築するかを慎重に考える必要に迫られています。また、インタフェースを一旦決定してしまったら、我々はそれをずっとサポートしなければならないということを考えて下さい。

たくさん変更が入るだろうとわかっていながら、破綻したAPIを提供するよりは、それを含めないことを我々は選択しました。我々は、いつか必ずBluetooth APIをサポートするつもりです。しかしそれがいつになるのか、正確なことは言えません。以下は含むべきいくつかの便利な機能の一例です。

• GAPとSDP機能とのバインド
• RFCOMMとSCOソケットとのアクセス
• JavaでのL2CAPソケットのサポート（これは検討段階です）
• 我々のハンドセットとハンズフリープロファイルとのAPI

個人的な発言として、Nickは付け加えています。「私はちゃんとしたサードパーティのアプリやゲームがBluetoothを使って動くのを見ることが何よりも大好きです。私は、Bluetoothは多くのモバイルプラットフォームでもっと十分に活用されてしかるべきだと思います。そして開発者コミュニティがAndroidを使って何をするかについてとても興味を持っています。」

私は、今回のAPIの削除については非常にがっかりしました。特にGTalkServiceによって提供されるP2Pの機能を楽しみにしていました。しかし、いつでもユーザーのセキュリティとプライバシーは最優先に考えなければなりません。いかなる場合でも、我々はこれらの関心事とバランスを取れた素晴らしいAPIを作るために開発者コミュニティとともに活動していきます。

最近、Android Developers Blogにビッグニュースがよく載ります。“Android Market: a user-driven content distribution system”を、日本語にしたものを参考までに載せます。訳はそれほど正確ではありませんので、オリジナルの方もご覧下さい。オリジナルにはスクリーンショットも載っています。さて、このことがAndroidをどの方向へ導くことになるのでしょうか。

Android Market:ユーザー主導のコンテンツ配布システム　2008/8/28 Eric Chu

　開発者の方々と話をしていると、アプリケーションをどのような方法でユーザーの元に届けるのかと言うことが、しょっちゅう話題になります。なので、今日Android Marketの初期構想について皆さんにお伝えすることが出来て嬉しいです。Android Marketはオープンなコンテンツ配布システムです。Android Marketは、Androidが搭載されたデバイス上で動作する様々なコンテンツを、エンドユーザーが探したり、購入したり、ダウンロードやインストールしたりすることを支援します。コンセプトは、インフラや検索に関するGoogleのノウハウを有効活用して、ユーザーとあなたのような開発者が作成したコンテンツとをつなぐことです。とてもわかりやすいでしょう？

　開発者は、Googleによって提供されるオープンなサービスを使うことで、コンテンツに対してフィードバックを受けたりYouTubeと同じような評価システムを設けることができるようになる予定です。開発者はオープンで妨げの無い環境でコンテンツを公開できるようにするべきだと我々は感じています。だから「store」ではなく「market」と名付けることにしました。YouTubeと同じように、簡単な3つのステップを経るだけで、マーケットプレイスにコンテンツを公開することが出来ます。3つのステップとは、まず取引主（merchant）として登録します。そしてアップロードして説明文を書き、それを公開するという感じです。また、ビジネスをどうドライブしたらよいのかや、最終的には公開しているものをどう改善すればいいのかについての手助けとなる便利なダッシュボードや解析ツールを開発者に対して提供したいとも考えています。

　また、あなたたちが我々のパートナーとして、最初のAndroidハンドセットのリリースを迎えられるように、いくつかの初期構想を共有して、あなたたちが計画を立てる手助けをしたいとも思っていました。最初のハンドセットでは、Android Marketのベータ版を利用できると思っておいて下さい。他にもいくつか決めていることがあるのですが、少なくともフリー（無料）のアプリケーションはサポートします。Android Marketの運用を開始してから間もないうちに、有料のコンテンツのダウンロードもサポートするつもりです、また、バージョン管理や、複数のデバイスプロファイルのサポート、解析ツールなどのような機能を提供するつもりです。以下に、セキュリティ関連の機能や操作手順を説明したいくつかのスクリーンショットを載せています。

　マーケットプレイスが新たに登場したことで、Androidのエコシステムはさらに強固なものになります。今回のサポートや、今までに拝見したとても素晴らしいコンテンツが、私に信じられないほどのエネルギーを与えてくれています。Android Marketが公開されたら、もう少し詳細な情報をお知らせできると思います。今後数ヶ月以内には、多くの皆さんとともに活動できるようになるでしょう、そうなることを私は楽しみにしています。

Android Developer Challenge(ADC)の最終結果が発表されました（ここ）。めでたく$275,000を獲得した上位10作品の概要を以下に示します。いいなあ。私も次回は何か応募したいと思います。作{ら|れ}ないと何も語っちゃいけないような気がするので。

■cab4me
Konrad Huebner, Henning Boeger
どこにいてもクリックひとつでタクシーを呼べるアプリ。GPS,cell basedで現在位置を把握。コンタクトリストと連携し、現在位置でピックアップ可能なタクシー会社の連絡先を表示。

■CompareEverywhere
Jeffrey Sharkey
目の前にある商品の販売価格が妥当かどうか、バーコードをスキャンするだけでわかるアプリ。カメラ機能を使いバーコードをスキャンすると、その商品を扱っている店での販売価格が一覧で表示され、比較できる。GPSを使って最寄のお店を知ることも可能。Mapで場所もわかる。

■Ecorio
Jeff Kao, Gary Pong, Robert Lam, Taneem Talukdar
地図上で行程を入力すると、その行程での二酸化炭素排出量を正確に知ることが出来るアプリ。GPS、Location、WEB使用。次の3つの機能がある。Reduce：公共の乗物を利用するなどして排出量を削減する提案をしてくれる。／Inspire：排出量を削減するために行った試みを他人とシェアできる／Offset：二酸化炭素排出量削減プロジェクトに出資（二酸化炭素を排出することに対してお金を払う。）

■GoCart
Rylan Barnes
開発者曰く、オンラインストアと現実の店でのショッピングの間にある隙間を埋めるアプリだとのこと。カメラを使い商品のバーコードをスキャンすると、インターネット上のオンラインストアや、近所のお店などから最安値を検索できる（GPS利用）。ウィッシュリスト機能がある。OpenSocial APIを使っており、リストをソーシャルネットワークのページで友達とシェアできる。

■Life360
Chris Hulls, Dilpreet Singh, Luis Carvalho, Phuong Nguyen, Steve Potell
隣人との近所付合いを支援するための多チャンネルメッセージングシステム（火事があった時に家族が無事か確かめたり、犬が逃げた時に捜索に協力してもらったり）。GPSもMAPも使っている。家族の位置を常に把握でき、緊急時の医療情報等が確認可能。事故で衝突したりすると、加速度センサーでそのことを自動的に検知し家族へ通知。困っていることを近くにいる人に通知して助けを請う機能もある。

■Locale
Carter Jernigan, Clare Bayley, Jasper Lin, Christina Wright
"場所"に対して、意味を持たせることが出来るアプリ。Map上で"場所"を予め設定しておくと、自分の現在位置がその"場所"内に入った時に、端末の設定を変えることが出来る。例えば、"仕事場"に入った時は、着信音を鳴らさずにバイブにするなど。

■PicSay
Eric Wijngaard
端末で写真を撮って、吹き出しやタイトル、説明などを素早く添えることが出来るアプリ（絵がしゃべってる感じ）。色補正やエフェクトをかけることができたり、友達や家族とBLOGやWEBを通して画像をシェア出来る仕組みを提供する。Location APIで、位置も取得可能。

■Softrace
Staffan Kjellberg, Thomas Kjellberg
各プレイヤーが端末を持ち、実際のコースを自分で走って競争するレースゲーム。Location APIで位置情報を取得し、リアルタイムに順位がわかる。位置はMapに出る。

■TuneWiki
TuneWiki Inc.
曲やPVなどを再生しながら、同期して歌詞（翻訳されたものも可）を表示するアプリ。音楽の情報は友達とシェアできる。GPSを使って、近所の人が聞いている曲がわかったり、その場所（国、地域）でのヒットチャートを見ることが出来たりする。OpenSocialやGoogle Mapsと連携しており、Android端末ではない人とも共有できる。

■Wertago
Kelvin Cheung,Teresa Ko, Peter Ree, Robert Sarvis, Douglas Young
夜の街で遊ぶことが好きな人のためのアプリ。ソーシャルネットワークの友達と、どの場所が今アツいとかの情報を交換したり、夜遊びの計画を練ったりすることができる。これもLocationとGPS、ソーシャルネットワーク。