なにがでるか

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と同じ高さにする。 ・その他よく使用するボタン配置は使い勝手を優先して位置を変更しない。 だいたい以上のような感じになります。 次回はもう少し具体的に実装面で考慮すべき点をまとめようと思います。

画像閲覧アプリBeautyAlbumをハニコムTablet対応してみました。 今回から数回に渡って、Phone向けのアプリをPhone対応を残しつつハニコムTablet対応する手順と気にしなくてはいけない点をまとめてみます。 結論から言うと、 Google I/O 2011公式アプリ がベストプラクティスなのでそちらを参照して真似るのが一番良いと思います。 なので、あまり細かい実装の話はしません。 さらに、 ここ とか ここ 見たほうが良いと思います。 この場では、「私のアプリの場合こうしました」という具体例を示します。 また、絶対こうしなきゃいけないわけではありませんので、ご自分のアプリの性格をよく考え、どういう対応をするのか（またはしないのか）を考えてくださいね。 というわけで、まずは対応する前の元のアプリの機能を簡単に紹介します。 アプリはAndroid Marketから ダウンロード できます。 サムネイル表示画面で画像を選択すると画像が拡大表示され、その画像をお気に入りに登録したり、他のアプリに共有したりすることができるといういたってシンプルなものです。 【サムネイル画面】 ・ネットワーク上から画像のサムネイルをダウンロードしてGridViewに表示します。 ・サムネイルダウンロード中は画面右上のタイトルバー上にリング型のProgressBarを表示します。 ・画面下部に他のユーザのランキング表示と自分のお気に入り表示の切り替えボタンを配置してあります。 ・Menuキーを押すことでAboutダイアログを表示します。 【詳細画面】 ・サムネイルを選択すると画面遷移して高解像度の画像をダウンロードして表示します。 ・画像のダウンロード中はサムネイル画面同様タイトルバー上にリング型のProgressBarを表示します。 ・画面下部に他のユーザがお気に入り登録した回数と自分のお気に入りマーク(☆)を配置してあります。 ・画面下部に画像の共有、ギャラリーアプリ起動、リスト上で次の画像、前の画像を表示する機能を呼び出すボタンが配置してあります。 ◆UIの基本方針 次の方針でPhone向け画面設計を行っています。 ・よく使用する機能は画面上にボタンを配置して呼び出すようにする。 ・画面上のボタンは押下しやすいように画面下部に固めて表示する。 ・Menuキーには滅多に使用...

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 .

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にしとくとわりと綺麗に敷き詰められるよ！