アーカイブ : 2011年 5月

FlashBuilder 4.5 のコードアシストをFlashDevelopライクにする設定

いつも使うエディタがFlashDevelopとFDTだったんですが、winもmacもよく使うのでこのさいFlashBuilderに乗り換えました。

コードアシストの方法が分からなかったんで、メモ。

メニューの[ウィンドウ→設定]から環境設定ダイアログを開いて以下のようにするとOK。

AIR for iOS のipaファイルの構造とインストール時のディレクトリ構造について

AIR for iOSでパッケージングしたipaファイルの構造

AIR for iOSでパッケージングしてできたipaファイルはzipファイルになっています。パッケージングしたファイルの中にswfは含まれていません。

ほとんどのファイルがiOS向けにコンバートされているので解凍したところであまり内容はよくわかりません。ipaファイルを直接どうこうするという機会はないと思うので参考程度に御覧ください。

アプリインストール時のデバイス内のディレクトリ構造について

ipaファイルはデバイスにインストールされると、まずアプリ固有の任意のIDが割り振られ、このIDの名前のディレクトリ(サンドボックス)が作成されます。

このサンドボックス内ではアプリの本体ファイルといくつかのディレクトリが作成されています。

  • Documents … ユーザー用のデータの保管場所
  • Library… アプリ用データの保管場所
  • appidディレクトリ…ipaファイルを展開したディレクトリ
  • temp…作業用ディレクトリ(File.createTempDirectory()で参照できます)

ユニークIDがふられたディレクトリは一般的に外からアクセスできないようになっているのでこのユニークIDがふられたディレクトリならアプリで作成したデータは基本的にどこにおいても安全と思われます。ただiTunesのバックアップの対象がDocuments,Libraryの2つのディレクトリが対象になっているのでユーザー用DBなど記憶させておきたいデータはこの2つのディレクトリに置いたほうがよさそうです。ShareObjectもLibrary配下にあるのでバックアップの対象です。

AIR for iOS のFileクラスで参照できる領域

AIR for iOSでもファイルを参照することができます。参照できる場所はアプリケーション固有に割り当てられた領域(サンドボックス)と写真やビデオが保存されているメディアライブラリになります。(AIR2.6での話)

Fileクラスのプロパティに対応したデバイス上のパス

File.applicationDirectory

/var/mobile/Applications/[uniqueID]/[filename].app

アプリ本体のバンドルになっているのでいじらないほうがいい。

File.applicationStorageDirectory

/var/mobile/Applications/[uniqueID]/Library/Application Support/[appID]/Local Store/

Libraryディレクトリがアプリケーションの設定ファイルなど突っ込んでおくディレクトリ。iTunesバックアップ対象ディレクトリ。

File.desktopDirectory

/var/mobile/Applications/[uniqueID]/Desktop/

モバイルではあまり関係ないディレクトリ。

File.documentsDirectory

/var/mobile/Applications/[uniqueID]/Documents/

ドキュメントやアプリケーションデータを保存するディレクトリ。このディレクトリにあるコンテンツは、ユーザーとのファイルシェアが行える。iTunesバックアップ対象ディレクトリ。

File.userDirectory

/var/mobile/Applications/[uniqueID]/

このディレクトリがアプリに用意されたサンドボックスのルートになっている。

File.createTempDirectory()

/var/mobile/Applications/[uniqueID]/tmp/FlashTmp0/

テンポラリディレクトリは複数作ることができ作成するごとにディレクトリ名の最後の数字がインクリメントされていきます。名前のとおり作業用の一時的なディレクトリのため作業が終わったら自分で掃除してあげたほうがよさそうです。長時間放置された場合はOSが消してくれるそうです。iTunesバックアップ対象外です。

AIR for Androidのメモリ使用量確認方法

※この記事は参考程度におねがいします。自分もいまいち理解できてません。詳しい方の説明or参考URL希望。。。。。。

写真や画像などを含むアプリを作った場合のメモリの使用量がとても気になるところです。特にAIR Runtimeを使ったアプリを作る場合はそれだけで多くのメモリを消費します。さらに画像や動画を読み込むと使用するメモリは増大するのでモバイル開発においてはこの部分が肝になるかと思います。

メモリの使用量の確認方法は幾つかあって、

  • ActionScriptでSystem.privateMemoryを参照する方法
  • メモリ監視アプリによる方法
  • コマンドライン($procrank)から確認する方法

SDKに含まれているコマンド$procrankで参照するメモリが一番確実なのではないかと個人的に思ったりしています。。。。
時間経過でみるならメモリ使用量の増減をみるならStatsライブラリを少し改造してSystem.privateMemoryを見ればいいのかなと。。

ActionScriptでSystem.privateMemoryを参照する方法

flash.systemパッケージにあるSystemクラスのプロパティでメモリの使用量を確認することができます。AIR for Androidでメモリの使用量を確認したい場合はSystem.privateMemoryを参照します。

System.totalMemory ・・・AIR Runtimeがアプリに割り当てているメモリ
System.privateMemory・・・アプリが固有に占有するメモリ領域
System.freeMemory・・・totalMemoryのうち使われていないメモリ領域

import flash.events.Event;
import flash.system.System;

addEventListener(Event.ENTER_FRAME,enterFrameHandler);

function enterFrameHandler(e:Event){
	trace("MEMORY STATE (Mbyte)\n")
	//trace("System.totalMemory",System.totalMemory/1024/1024+"\n");
	trace("System.privateMemory",System.privateMemory/1024/1024+"\n");
	//trace("System.freeMemory",System.freeMemory/1024/1024+"\n");
}

ここで取得できるメモリの使用量は実際にAndroidSDKから見るメモリの使用量や、メモリ監視アプリとは一致していません。メモリ監視アプリによっても定義しているメモリの種類やキャプチャタイミングによって値が異なる場合があるため、目安として参照する必要があると思います。

StatsライブラリはSystem.totalMemoryを見ています。

メモリ監視アプリによる方法

メモリ監視用のアプリはたくさんリリースされていて代表的なアプリとしては

さくっと確認する分にはお手軽でいいかと思います。

コマンドライン($procrank)から確認する方法

USB接続した端末のメモリ使用量をDOSコマンドで確認する方法もあります。

windowsの場合はコマンドプロンプトを起動して、

adb shell と入力します。プロンプトが#に変わるのでそこで

procrank と入力します。

VSS  (virtual set size)…… 仮想メモリ
RSS  (Resident set size)……物理メモリの消費量
PSS  (proportional set size)…… プロセスが実質的に所有しているメモリ
USS  (unique set size) ……ひとつのプロセスが占有しているメモリ

プロセスに割り当てられているメモリはPSSを参照すればいいようです。

雑感

メモリの使用量の確認方法をリストアップしてみましたが、仮に内容が空のアプリをインストールして上記のそれぞれの方法でメモリを確認したところ、下のように全く異なる結果が返ってきます。今のところAIR runtimeがどういう仕組みで動いているかよくわからないのでとりあえず目安程度に参考にしていただければ幸いです。

System.privateMemory 11.1Mbyete
watchdog 18.0Mbyte
procrank 12.2Mbyte

playbook用のアプリをBlackBerry App Worldにリリースしました。

初めて使うFlashBuilder4.5でplaybook用のお絵かきアプリを作ってみました。

 

sketchPAD

主な機能は

  • undo/redo 10回
  • 書き味がなめらか
  • カスタムカラーパレット

playbookのアプリ市場がどんなものか定点観測するためにリリースしてみました。

 

FlashBuilder4.5でのPlaybookアプリケーションにおける注意点について

この記事はFlashBuilder 4.5.1のリリースによって必要なくなりました!!!

 

まだ発売もされていない端末のアプリをつくろうなんて奇特な方はいらっしゃらないかもしれませんがとりあえずplaybookをゲットしたのでこちらもちょっとづつ更新していこうと思います。

まず既にFlashBuilder4.5ではAIR2.6での開発になっているため、ベースがAIR2.5のplaybookの開発はデフォルトの設定だとできません。準備作業としてplaybookが2.6対応になるまで強引に開発ができるようにパッチを用意してくれているのでこれ(playbook_override.zip)を用意します。いまのところ、こんなややこしいことになってますが、いずれかのタイミングでアップデートされることと思います。

開発における注意点

新しくプロジェクトを作成したら以下の作業を行います。メニューの「プロジェクト→プロパティ」を開きます。

1,ActionScriptコンパイラーの設定

プロジェクトのプロパティパネルから[ActionScriptコンパイラーの項目を選択します。]

追加コンパイラー引数のテキストフィールドに「-swf-version=10」を追記します。

 

2,ActionScriptビルドパッケージの設定

同じプロパティ画面で左側のメニューから[ActionScript ビルドのパッケージ]から[BlackBerry Tablet OS]を選択します。

チェックボックス[プラットフォーム固有ライブラリをライブラリパスに追加]にチェックが入った状態にします。

下の詳細タブをクリックして[その他のパッケージ作成オプション]を[-forceAirVersion 2.5]と入力します。

 

3,ActionScriptビルドパスの設定

次に下の段の[ActionScriptビルドパス]を選択し、[SWCの追加]ボタンをクリックして最初にダウンロードしておいたplaybook_override.swcを追加します。

以上が現状のFlashBuilder4.5でplaybookアプリ作るときの注意点になります。

元記事はこちら

AIR for AndroidのSharedObjectについて

AIR for Androidで利用できるSharedObjectはブラウザのものと少し異なります。

ブラウザではsharedObjectで保存できる容量がユーザーの定めたある一定量の容量で制限されていました。AIR for Androidではここらへんの記述については特にコメントされていませんが、AIR for AndroidのSharedObjectはブラウザのように決められたディレクトリにドメインごとに保存されるのではなく、アプリ固有のストレージの中に実体ファイルが生成されるような形になっています。このアプリ固有のストレージはの容量については特に制限はなく(でも少なければ少ないほうが望ましい)いままでの数キロバイトといった使い方からもう少し拡張できると思います。

以下のようなテストを行いました。

1920 x 1200pxのjpegデータ(ファイルサイズは1Mb)をBitmapDataとしてリンケージさせておき、このBitmapData.getVector()をそのままSharedObject.dataにどこまで入るかを試しました。

var bmpd:BitmapData = new MyBitmap();//リンケージしたビットマップ
var so:SharedObject = SharedObject.getLocal("sharedtest");

so.data.vec1 = bmpd.getVector(new Rectangle(0,0,1920,1200));
so.data.vec2 = bmpd.getVector(new Rectangle(0,0,1920,1200));
so.data.vec3 = bmpd.getVector(new Rectangle(0,0,1920,1200));

1920*1200の画像をgetVectorにすると約7.8MbのSharedObjectファイルが生成されます。
これを繰り返してどれくらいまで保存できるかを確認してみました。

結果は3回目の保存で約26.37Mbまでは保存することができました。

ただメモリの問題さえ解決出来れば無制限に保存できるような気がしました。3回目のビットマップデータをflush()した際にアプリの使用しているメモリが80Mbyteを超え、アプリが強制終了してしまいました。SharedObjectにデータをつっこんだタイミングでメモリの使用量が大きく増えていたのでここらへんが解決出来れば大きなデータも行けるんじゃないかと思います。ただ自分のテスト方法が適切かどうかもわからないので不適切な部分があれば指摘いただけると幸いです。

メモリを消費しない程度にある程度の大きさのSharedObjectは利用できそうな感じです。※一般的なアプリのメモリの使用量は約10~20Mb以内なので今回のテストはとても特殊なケースです。ここらへんは実際に作ってみてテストするしかなさそうです。。

ちなみに豆知識ですが以下の場合にSharedObjectは消去されます。

  • FlashやFlashBuilderでのPublishした場合
  • アプリケーションの管理から「データの消去」ボタンを押したとき。

AIR for Androidでパッケージしたapkファイルの構造について

AIR for AndroidではAIR Runtimeで動作するように一般的なjavaとは異なる形でパッケージングされています。ここではAIR for Androidで実際にパッケージされたapkの構造と、デバイスにインストールされた時の構造に分けて説明したいと思います。

AIR for Androidでパッケージされたapkファイルの構造

AIR for Androidではパブリッシュボタンを押すとandroidデバイスへのインストールファイル(apkファイル)を自動的に作成してくれます。

この処理はADTと呼ばれるコマンドがandroidへインストール可能なファイルへmy-app.xmlと署名ファイルと書き出されたswfファイルを使って自動的にパッケージングをおこなっています。パッケージングされたapkファイルの中身は↓のような構造になっています。

大切そうなところだけピックアップすると、

/AndroidManifest.xml

これはAIRforAndroidで自動生成されるアプリケーション定義ファイル(application.xml)を元にADTコマンドが一般的なandroidアプリで使用されるマニフェストファイルに作り直したものです。

このxmlはandroidmarketでのフィルタリングやデバイスのインストール時の機能制限などを行う際に利用されます。AIR for Androidではあらかじめandroid2.2以上のデバイスへインストールが可能なように設定されています。

また、ファイル形式がxmlとなっていますがapkにパッケージングされた時点でデバイスのパフォーマンスを節約するためにあらかじめパースされたバイナリになっています。なのでテキストエディタでみても読むことはできません。すでにapk化されたマニフェストを見たいなという場合はapktoolというツールでもとのxmlファイルにデコードが可能です。このファイルはapkにビルドされる際に圧縮の先頭に配置されています。

/assets/app.swf

これはAIR2.6SDKでパブリッシュされたswfファイルです。AIRとなっていますが実際パッケージングされるのはswfファイルです。ただ普通のWEB上で使われているswfでも動きますが、AIR2.6でビルドされていないので専用APIへのアクセスはできません。このswfを差し替えさえすればWEB上のゲームコンテンツなどをアプリとしてパッケージすることなども可能です(お勧めできませんが可能という意味です。モバイル用のチューニングは必須)

コマンドラインからビルドする場合はこちらを参照。

/assets

このディレクトリには上記のswf以外にもパブリッシュ設定上で追加したswf内で使用する画像、サウンド、バイナリなどが格納されています。このディレクトリに含めたファイルは直接ファイル名を入れることで参照できます。このディレクトリに保存されたものはデバイスの/data/appから参照するのであまりにもここに含めるファイルサイズが大きくなるときはアプリをSDカードへ保存できるようにアプリケーション定義ファイルを変更してあげたほうがいいかもしれません。

(例) var loader:Loader = new Loader(new URLRequest(“hello.png”));

(例) sound.load(“test.mp3”)

※ここで含めるファイルの中にアプリケーション定義ファイルが含まれていますが、定義ファイルは/assets/META-INF/AIR/に移動されています。

 

 

デバイス上に展開されたapkファイルの構造

apkファイルはデバイスにインストールされるとそのままapkが指定ディレクトリにコピーされるだけでなく、展開されてキャッシュディレクトリや様々な作業用ファイルが作成されます。実際に作成されたファイルやディレクトリの仕組みについて説明します。

 

デバイスにapkがインストールされるとapk本体が/data/app/applicationID.apkに配置されます。

さらに作業領域として/data/data/applicationIDが確保されます。この領域には他のアプリからアクセスができないのでセキュアなディレクトリになっています。

この作業領域は[lib][cache][files][appid]のディレクトリが作成され、このディレクトリのうちAIR for Androidでアクセス可能なディレクトリは[appid]になります。このディレクトリへはFileクラスやSharedObjectクラスから行えるようになっています。

File.applicationStorageDirectory

/data/data/air.appid/appid/LocalStore/

SharedObject

/data/data/air.appid/appid/LocaStore/#SharedObjects/appname.swf/appname.sol

 

アプリケーションの設定

デバイスに展開されたアプリケーションはデバイスの設定から移動や削除することが可能になっています。

デバイスの「設定」→「アプリケーション」→「アプリケーションの管理」→「myapp(アプリの名前)」

主に影響を及ぼすコマンドは「データを消去」「SDカードに移動」「キャッシュを消去」の3つです。AIR for Androidで作成したアプリはこのボタンを押したときどうなるの?と疑問になると思うので実際にボタンを押したときに消去される領域を確認してみました。

「データを消去」

/data/data/air.appid/cache

/data/data/air.appid/files

/data/data/air.appid/appid

の3つが消去されます。つまりインストール後に生成されたFile.applicationStorageDirectoryやSharedObjectもすべて消えてしまいます。

「キャッシュを消去」

/data/data/air.appid/cache/

以下のファイル及びディレクトリが削除されます。File/SharedObjectはそのまま残ります。AIR for Androidにおいてはあまり影響はありません。

「SDカードに移動」

/data/app/air.appid が暗号化されてSDカード(/mnt/secure/asec/,/mnt/asec/)に保存されます。(※/mnt/sdcardではありません。ここらへんの暗号化の仕組みはちょっとよくわかってません。。)

/data/data/air.appid/はそのまま端末上に残るのでインストール後に生成したファイルは意図的にSDカードへ保存しない限り、端末上に残ったままで移動できません。