WindowsでのAndroid開発環境構築メモ

WindowsでAndroid環境構築をしてみたのでそのメモです。

こういうのは時期によって手順やノウハウが変わってくるので、私もよく最新の体験談を参考にするのですが、自分でも提供してみようと思います。さらっと。

開発環境は、Eclipse + ADT Plugin + Android SDK + JDK で出来ている。

この4つ入れて、EclipseでADT Pluginの設定すれば終わり。

※Android SDK Managerからのダウンロードはものすごく遅いことがあるので余裕を見ておきましょう(Proxy環境だと一晩かかりました)

1.JDKをインストール

     Javaの開発環境

     http://www.oracle.com/technetwork/java/javase/downloads/index.html

     インストーラつきでらくらく

2.Android SDKをインストール

     Androidの開発環境、JDKが必要。ここだけコメント多いのでわかると思いますがだめだめです。

     http://developer.android.com/sdk/index.html

     インストール時、JDKが認識されないというくだらないバグあり(rev10の時から)。なぜ放置しているのか。

     JDKが無いと言われたら、一度Backで戻って再度進むと回避できます。

     インストール後、Start SDK Managerを起動するかと聞かれるので起動すると、パッケージが更新される。

いきなり更新を始めるので、接続エラー出る場合(プロキシ環境の人など)はいったん中断し、Settingからプロキシ設定と、Force https://～をチェックする。

windows版なんだからプロキシ設定くらいie設定から読み取るべきではないかと思う。

更新は結構時間がかかる。というかダウンロードありえないくらい遅い。

          http://dl-ssl.google.com/android/repository/repository.xml

          これの中身を検索してURLを抽出し、http://dl-ssl.google.com/android/repository/〜から直接ダウンロードしたzipファイルを、AndroidSDKインストールフォルダのtempに置く。そしてインストールするとダウンロード済みとして扱ってくれる。

3.Ecllipseをインストール

     統合開発環境(IDE)。バージョンいろいろあるがとりあえず新しめの 日本語版Helios を使用してみた。

     pleiades ultimate http://mergedoc.sourceforge.jp/index.html#/pleiades_distros3.6.html

     起動するとワークスペースを置く場所を聞いてくる。

4.ADT Pluginをインストール

     EclipseでAndroid SDKを使えるようにするためのプラグイン。

     Eclipseの新規ソフトウェアインストールダイアログ(ヘルプメニューにある)にて、下記URLを追加

          https://dl-ssl.google.com/android/eclipse/

     開発ツール(Developer Tools)をすべてインストール

5.EclipseにAndroid SDKの場所を設定する

     設定(Preferences) > AndroidにてAndroid SDKのフォルダを指定

     設定 > 一般(General) > Workspace でエンコードを UTF-8 にしておく
     環境変数PATHにAndroid SDKのtoolsおよびplatform-toolsを追加する

以上で基本的なインストールは完了です。(たぶん。これ書いてる時点でまだダウンロード終わってないので追記するかもしれないです)

追伸
この手順で完了してました!

YouTubeに初動画アップ

Sound StageというMacAppStoreで販売しているアプリの操作説明ムービーを作るソフトが使いやすかったので、練習動画をアップしてみました。

サンプル動画 ひまわりぐりぐり

動いているのは、置くだけでマルチタッチでぐりぐり動かせるクラスのテストプロジェクトです。
ただこれだけのアプリですけど、実機で、特にiPadでいじってると楽しいんですよ。
指についてくる動きをするだけで楽しいと感じるのが興味深いです。

iOSメモリのお作法

本稿は、2011/5/28(土)に開催された、第4回iPhoneアプリ開発合宿in府中にて発表した内容です。
お作法という偉そうな題名にしていますが、ごく基本的な内容です。iOSの公式ドキュメントに書いてある内容をまとめたものになっています。

スライド 「iOSメモリのお作法(改訂版)」


良いアプリとは?
良いアプリの条件は数々ありますが、内容の前に重要なのが落ちない事です。可用性が低いアプリはいくら良いものを持っていても評価が低くなってしまい、レビューが荒れる原因にもなりかねません(^^;)。かなり勿体無いです。本稿は、アプリがなぜ落ちるのか、またiOSでのメモリの作法を理解することで、落ちないアプリに近づいていただくことを目的としています。

アプリはなぜ落ちるのか?

アプリが落ちる原因についてはいくつか考えられます。

iOSアプリの状態遷移図(改訂版)

以前書いた、iOSアプリの状態遷移図を書きなおしてみました。

ロジック的には変わってないです。少しは見やすくなったかな。

iOS4以降で実装されたマルチタスキング対応アプリの状態遷移をまとめてみました。

iOSアプリの状態遷移

iOS4.0からアプリのマルチタスキングが導入され、アプリはバックグラウンドという状態を持てるようになりました。それ以前にはアプリの状態というのは起動中(アクティブ)かそうでないかぐらいの区別しかなかったものが、これによってぐぐっと複雑になり、アプリケーションガイドを一度見たくらいではたぶん完全には理解できなくなったのではないでしょうか。(ガイドにはちょっと嘘も書いてあります)

アプリケーションガイドによると、アプリの状態というのは下記5種類があるそうです。

・非実行

・非アクティブ

・アクティブ

・バックグラウンド

・一時停止(サスペンド)

フォアグラウンドっていう状態はないみたいですね。たしかApplicationDelegateにapplicationWillEnterForegroundっていうのがあったはずですが、あれはフォアグラウンド状態に遷移するときに呼ばれるんじゃないんでしょうか。

そうなんです。フォアグラウンドっていう状態はないんです。このへん、自分でもよくわからなくなったので、あちこち調べて理解したのですが、最近人に聞かれる機会があったので図にしてみました。

IOS4以降のアプリ状態遷移図

ログ入れて実機(iPhone4)で調べたので実際の動作と同じになっていると思います。(間違いあったらご指摘お願いします)

図中、起動系は赤、終了系は青の線と色分けしています。

先程のフォアグラウンドの件、これがフォアグラウンドだという明確な記述は見つけられませんでしたが、たぶんACTIVEかINACTIVEかのどちらかにいる時をフォアグラウンドといってるっぽいですね。

ローカル通知はどう受け取るか

どういうときに状態遷移を理解していると便利かという事例として、時刻がくると発報するローカル通知を使ったアプリを作っている時に、通知イベントの動作で困ったことがありましたのでそれを紹介します。

通常、ローカル通知イベントが発生するとアラートウィンドウが出ますが、アプリが動いている(わざとあいまいな表記をしています)時に発生したローカル通知イベントは、アラートウィンドウを出さずにApplicationDelegateに通知されます。アプリからは、アラートウィンドウが出たかどうかを知る手段がないんです。

そこでログを入れて調べていますと

• アラートウィンドウが出るパターン (メソッド名は一部省略しています)

EnterForeground → Notify通知 → BecomeActive

• アラートウィンドウが出ないパターン

BecomeActive → Notify通知

となっていました。どうやらNotify通知を受け取るのがapplicationDidBecomeActiveの前か後かによって判別できそうです。フラグをBecomeActive時にYES、ResignActive時にNOになるフラグを作って、フラグがYESの時は自力でアラートウィンドウを出すという対策を施しました。

でも、すべての場合についてこれで良いかどうか確信が持てません。こういう時はテストして調べることになるのですが、すべての状態を網羅しないと完全とは言えません。

このような場合に状態遷移図を見てテストケースを決めるわけです。

今回の場合は、メールなどのアラートを出していたりするときのNotify通知のテストが漏れていることがわかりました。(ちゃんと動きました)

参考になれば幸いです。

Facebookにページを作りました

Facebook勉強中です。
とりあえずページを作ってみました。よろしくお願いします！

ゆうぞらプロジェクト

ついでにここのテンプレートいじってShareボタンといいね!ボタンを各投稿の下↓につけてみました。(こちらを参考にさせていただきました)

OpenGL勉強会まとめ(2) OpenGLアプリの最小構成

OpenGLはプラットフォーム非依存
コノルさんの勉強会ではiPhoneでのOpenGL ESアプリを作ることを目標に、基本的な描画、テクスチャ、バンプマッピング、マルチテクスチャまでを勉強しました。

このブログはおさらいという意味で、勉強会のソースをアリの目でもう一度追学習してみようと考えています。

OpenGL自体はプラットフォーム非依存で、実際に画面に表示するウィンドウを作るなどという部分は含まれていません。そのあたりを扱う有名なライブラリに、glutなどがありますし、本家でもEGLという、プラットフォーム依存部分のインターフェースを規定しているものもあるようです(iOSでのEAGLViewはEGLのApple実装らしい)。

iOSではglutは使えませんから、私も参考書などにあるソースがそのまま動かなかったりして戸惑いました。逆にEAGLViewは当然他の環境にはありませんので、この記事はiOSでのOpenGL ES1.1をターゲットにしていますが、iPhone独自部分についてはあまり深く追わず、OpenGL ES1.1として一般的な内容になるように心がけてみます。

OpenGL勉強会まとめ(1) OpenGLとは何か

わかりにくいOpenGL
言わずと知れた3D API、OpenGL。巷では、OpenGLはステートマシンだとか、クライアント&サーバー型だとかいう説明がされていますが、それにしても分かり難くないでしょうか。こう書くんだよ、というサンプルをアレンジして使ってみるのですが、それぞれの命令が何に対して働きかけているものなのか、どうも命令が整理されていないように感じるのです。

例えば、頂点配列を定義するのはglVertexPointer、カレントカラーを指定するのはglColor、というAPIがあるのですが、その設定値を読み出すのは両方共glGetというAPIです。さらに読み出す値の型によってインターフェースを分けています。
整数型の値ならば glGetIntegerv
浮動小数点の値ならば glGetFloatv
などと機能的なまとまりでなく、型によってAPIが分かれています。いったいどうしてなのか。私はこれはソフトウェア的な思想ではないように思うのです。

OpenGLはデバイスドライバの成れの果て?
それはOpenGL自体の設計が古い(1992年頃)というのもあるのですが、私はOpenGLを3DグラフィックアクセラレータのLSIのレジスタを抽象化したデバイスドライバのようなものだと捉えています。基本はSGIが使用していた描画回路をもとに標準化されたのではないかと思います。

一般的に、LSIには機能を制御するレジスタ群があり、ここに値を書き込んだり、読み出したりすることで制御を行います。

xxxx番地のbit0に1を書きこむと描画開始、などと決まっています。またレジスタには値を記憶したり、読み出したり、またLSIの処理状態によって勝手に変化するものがあったりします。どれがどういう機能を持つかはLSIのユーザーズマニュアルのレジスタマップを参照しますが、これでは分かりにくいしハードの仕様がちょっと変わっただけでソフトウェアのかなりの部分を変更しなくてはいません。

それでソフトウェアにはドライバというレイヤを設けてこのハードウェアを抽象化して使いやすくするわけです。そのドライバの中でも基本的な機能に、レジスタの読み書きがあります。レジスタにはそのレジスタの機能を表す名前をつけ、その名前を元にレジスタを読み書きするAPIを設けます。
先程のOpenGLのglGetがこの読み込みAPIに当たります。ものすごく低位なレイヤのAPIをそのまま標準化してしまったわけです。

また、レジスタはハードウェアのブロックに直結しているだけあって、ある機能を実現するためのモノがあっちこっちに分散していたりします。○○機能を有効にするために、xxxxレジスタとyyyyレジスタのbitどこそこを1にする、とかです。このへんもOpenGLの手数の多さと似ています。
余談ですがLSIのレジスタはメモリと違い、すべてのレジスタが書き込みできるとは限らず、読み出ししか出来ないものや、あるタイミングで勝手にクリアされたりするものもあります。

OpenGLの付き合い方が分かってきた
そんな目でOpenGLをみてみると、上記の特徴も、

• ステートマシンである 

→ 書き込み値はレジスタに保存されるので、次に書き換えるか、制御の結果書き換わるかするまで変化しない。

• クライアント&サーバー型である

→ ソフトウェアでコマンドを発行(レジスタ書き込み)し描画エンジンが実行する、という意味ではクライアント&サーバといえなくもない。描画LSIな訳ですから少なくとも自発的に動いたりしないわけで。いちいちコマンドで指示してやる必要があるわけです。

というようにしっくりする気がします。

描画命令というよりも、LSIの制御シーケンスを書いていると思えばよいのです。(と言って納得していただけるのは組込み系経験のある人だけかもしれませんが…笑)

これC++のクラスにでもしたくなりますね(笑) そのうちするかもしれません。

これからしばらく、OpenGLについての勉強をかねて、使い方を俯瞰していきたいと思います。

OpenGL勉強会まとめ

OpenGL勉強会まとめ

先日、Conolさん主催のOpenGL勉強会に参加してきました。

自分でも勉強しているんですが、OpenGLって日本語のリファレンスとか少ないです。

「こう書けば、こうなる」的にパターンで覚えて行くのもいいんですけど、昔から仕組みを理解しないと納得がいかないタイプなので、まずは勉強会で使ったAPIを整理して、構造を推測して見ることにします。

Posted from dPad on my iPad ゆうぞら