FlashDevelop 4の最新版にアップデート後、AIR3.2 SDKをダウンロードしてきてFlex SDKに上書きすればOKです。
FlashDevelop 4でAir Mobileプロジェクトを作成するとバッチファイルができあがるのでそれを編集すればAndroidやIOS端末で実機検証ができます。

デフォルトでは　goto desktop　になっていてこれだとadtでデスクトップ上で起動しますので、これをコメントアウトして　goto android-debug　のコメントアウトを外してやります。

ただ私の場合PathにAndroidのadbを追加してしまっていた関係でコンパイル後、うまく実機で起動してくれませんでした。
同様の症状でお悩みの方は、バッチファイルの 「adb」　で始まる箇所を全て 「call adb 」　に書き換えてやると正常に動くようになりますよ。インストールディレクトリ->Projects内に元のバッチファイルがあるのでこちらを書き換えちゃいましょう。

AIR 3.2からは、Stage3Dにも対応したとのことで、早速こちらも試してみました。
なぜかデスクトップ起動では表示されませんでしたが、端末側で起動したところうまく動いてくれました。素敵です。

スマホ向けのゲーム開発のおおまかな選択肢としては、Native , HTML5 , AIR , Unity 3Dなどでしょうか。
パフォーマンスについてはNativeが最もよい事は間違いないのですが、ワンソースで複数OSに書き出せるのは大きなメリットです。

つい最近 AdobeがAdobe Flash Player Premium Features for Gamingというライセンスを発表しました。
これは、Stage3DとdomainMemoryという機能を同時に使用し、5万ドルを超える収益をあげるコンテンツを対象としたもののようで、一時はネットでも騒ぎ？？になっていたようです。

Stage3D単体の利用でライセンス料がかかるのかと一瞬あせりましたが、どうやらこのdomainMemoryと同時に使用した場合のみのようです。

このdomainMemoryは、メモリアクセス絡みのもののようで、Alchemyを使用した場合や、Unity 3Dからswf書き出しを行った場合に必然的に利用されるもののようです。

とはいえスマホ向けにUnity使うなら各デバイス向けに書き出せばよいので、あえてswfにする必要もないですね。
Alchemyはパフォーマンスアップにも繋がるので非常に興味があるのですが、下手に使えませんね。
主にweb向けのソーシャルゲームが該当するようになるのかもしれません。

HTML5でのゲーム開発はどうなんでしょうね？Flash liteよりは全然いいと思いますがある程度限界があるような気もします。

国内の各ソーシャル会社さんもAIR SDKを提供しているようですので、今後のAIRの普及には期待したいです。

そんなわけで、無理やりAIRっていいね的な結論に結び付けようとしてしまいましたが、本音は、「もう各端末ごとに検証なんかやりたくねえよ・・・」でした。

http://lfg-net.com/android/is01/ics-on-is01-android-4-0-4/
この辺を参考にしました。

GPUドライバーはQualcommサイトからダウンロードできますが、アカウント作るのが面倒な人は、xda　からもダウンロードできます。

で、何度かトライしたのですが、画面真っ暗で起動せずドライバーの問題なのかなと思ってたのですが、Gingerbreadインストール時の解説を参考に

flash_image recovery /sdcard/ubi.img

ってところを

flash_image recovery_wr /sdcard/ubi.img

に書き換えてみたら見事起動しました。

GPU対応前バージョンのIcecream Sandwitch もいれてたんですが、あまりにももっさりなので、使い物にならなかったのですが、このバージョンはまともに動きますね。素敵です。

Air for Android開発にも使えるかどうかやってみようと思います。

http://sourceforge.jp/magazine/11/11/17/0456235

これはAndroid等モバイル向けFlash Playerの開発終了とも関連して

http://blogs.adobe.com/conversations/2011/11/flash-focus.html

HTML5でのwebアプリ開発が今後のメインになっていく事を踏まえての事のようですね。
スマホ等モバイル向けAIR実行環境は引き続きサポートされるとの事。

ジョブズご存命の頃必死になってFlash Playerの普及に尽力していた事もあってコストがかかりすぎたんでしょうかねえ。。
でもおかげで、Flex frameworkも相当軽くなりました。ソーシャルゲームのUI開発等に使用すると非常に保守性が高くて便利です。

FlexのMXMLはView上にカスタムクラスをぼこぼこのっけていくタイプ、一方HTMLは、ViewのDomを直接書き換えて操作するタイプなのでxml+scriptですが、若干スタイルが違いますね。

とは言えPC向けFlash Playerは、まだまだ健在です。Stage3Dが追加されGPUでの3D等の処理も行えるようになり（ショックウェーブでもできてましたが）3DのMMORPGなんかもブラウザ上で実現できるようになりました。WebGLが普及すればこの辺もどうなるか分かりませんが。

Flash vs HTML5 なんてのがずっと話題になってたんですが、いまいちしっくりこないなあと思っていたんですが、HTML5ってのはjavascriptやsvgなんかも含んだ定義になっていると考えるとまだ問題を孕んでる感は否めないです。

個人的にはクライアントサイドの「静的言語or動的言語」は、EcmaScript 4th Edition (AS3)の放棄によってすでに片がついてしまったという事になるのであればFlashを擁したくなってしまいます。

EcmaScript 4th EditionについてはAdobe同様Googleも支持していました。
Googleは　Flash vs HTML5 抗争のさなかhtml5の普及促進をしつつFlash擁護をしているような状態で、ChromeにFlash Playerを入れてしまったり、Appleと違い、Android端末にもFlash Playerを載せる事に積極的でした。
もちろんhtml5はまだ仕様策定が完了していなかったので、各ブラウザごとに実装が異なり実用性に乏しかったという面もあるかもしれませんが、実のところFlash云々ではなく、保守性の高い静的型付け言語を大規模開発で利用できるメリットを残しておきたかったのかもしれませんね。

Googleが先日dartを発表した裏には、Googleの内部文書

http://markmail.org/message/uro3jtoitlmq6x7t

で言われているようにjavascriptのパフォーマンス上の問題と共に、静的型付け言語の開発効率や保守性についての利便性があるようにも思えます。

クライアント側で本来のパフォーマンスを発揮するにはブラウザがエンジンを実装する必要がありますが、google以外のブラウザでは当面はjavascriptに変換して使用するという利用方法になってしまいます。つまりjqueryなどのフレームワークと同様の扱いになるわけで、それを利用するメリットとなるとスピード等でなく開発効率保守性の高さという部分以外ありません。

シンプルなHello Worldもjavascriptに変換すると17259行にもなってしまう（笑）という事で早速槍玉にあげられてます。
https://gist.github.com/1277224

とは言えFlexなんかもそうですが、大規模開発でコード量が増えるとフレームワークの余剰コードはだんだん相殺されていきますからその分別の大きなメリットがあれば問題ないだろうとは思います。

googleもいろんなサービスやらgoogle waveやらを中途半端にやめてきてますから、この手の新しいものについて懐疑的な人が多いのではないかと思います。
dartを成功させるには、各ブラウザベンダーへの働きかけよりも、javascript変換での利用をまず促す必要があり、そのためには、開発効率や保守性の高さをアピールするのが一番の近道だと思います。

google app engineはもともとpythonでしたが、その後Javaになり、gwtが利用できるようになりました。
gwtというのは、Javaで書いてコンパイルするとjavascriptのコードに変換されるというもので、丁度今のdartと似たような役割なのかなと思います。
gwtの利用者がどのくらいいるのかは知りませんが、これを利用するメリットはやはり保守性の高さではないでしょうか。
（Javaに関してはAndroidでのOracleからの訴訟もあり、使用するのを避けたいという思惑もあったのかもしれません。）

dartの言語仕様やハイプやらにはあまり興味ありませんが、クライアント向けに静的型付け言語が利用できるのが、個人的には一番のメリットだったりします。

あとsvgに関しては、cssの仕様とだぶるところがたくさんある上にそれらの仕様に整合性がとれてない部分があったり、ブラウザの対応もまちまち・・・
この辺はMicrosoftがいろいろ言及してたと思うけど確かに正論を言ってたような。しかし過去が拭い去れない・・・

まあこれら企業は標準化のフォーマット策定にも関っているから、最終的にいいものが残るような形になっていってほしいですね。

で、なんかハードコアな家電マニアの間ではもう当たり前のようなんですが、このDLNAってのがすごいですね。ＰＣにサーバソフト入れると自宅ネットワークで映画や音楽をシェアできちゃうんですね。

Tversity とかPS3Media Serverとか試してみましたが、ファイル形式によって読めたり読めなかったり一長一短あるのかな？

あとBraviaだとMedia Remoteってアプリ入れるとAndroid携帯がリモコンになるｗ
これで死にぞこないのSH-10B　（ IS01もどき )も廃物利用できそうです。
YouTubeの検索もし易くなります。でもrootとってChanogen modでバージョンアップしたAndroidだからかよくバグりますｗ
あとこのアプリ、横画面に対応してくれないもんかなあ。

AndroidでもDLNA使えるソフトがあったんでこれは音楽再生用に使ってます。
とりあえずシャッフルに対応してるupnplayっての入れてます。

Googleって静的型付けも動的型付けもできる言語が好きだなあ。

ECMA系統のAS3って型の指定が特殊だから他言語と同時開発する時は
dartみたいな仕様の方が　「あ、やっべえ型後ろに書くんだっけｗ」が
防げていいかも。

一番やりたかったのがVNCサーバ化だったんですが、marketにあった”droid VNC server BETA”とやらは、エラー吐いて動きませんでした。

で探してみたらgoogle codeで “fastdroid-vnc“とかいうのを発見。
こちらはみごとに動きましたよ！d(￣ ￣)

クライアントはRealVNCのViewerを使ってるんですが、これって横画面表示できないのかな(´～｀；
タッチイベントもとれないし、キー入力もなんか駄目っぽいし使いづらい部分もありますが、この辺はご愛嬌ってことで。

ベータ版時代の情報見てFlash DevelopでちょこっとAndroidアプリ作ろうと思ったんですがいろいろ仕様が変わってるようでなかなかコンパイル通らなかったｗ
Flash Developにはまだ4.5のintrinsicsが追加されてないのでコード補完は今のところ使えませんが以下のようにすればコンパイルは通りました。

クラス名が変更されてるようです。（他にもいろいろあるかも）
[Beta] MobileApplication -> [Release] ViewNavigatorApplication
[Beta] TabbedMobileApplication -> [Release] TabbedViewNavigatorApplication

コンパイラオプション( frameworks/airmobile-config.xml を使用するようです　）
+configname=airmobile

AIR設定xml [ application.xml　] ( AIR 2.6じゃないと駄目っぽい )
application xmlns=”http://ns.adobe.com/air/application/2.5″
-> application xmlns=”http://ns.adobe.com/air/application/2.6″

これで一応コンパイルは通るようですが、実機で動くかは未確認。

ViewクラスってのがAndroidのActivityに該当するような感じでpushとかpopとかでView間を渡り歩いてついでにパラメータ渡したりできます。

でかいモデルデータ格納はPersistenceManagerっていういかにもなネーミングのクラスがあってそれを使って格納したり取り出したりしていくようです。名前の割りにはこのクラスはSQLiteにデータを保存するわけではなく、FlashらしくLocalSharedObjectに保存するようです。

またView起動時はバックボタンで戻った場合でもviewActivateっていうイベントが発行されるようなのでAndroidより設計が楽そうです。ただAndroidみたいにintentが使えないので非アクティブなViewのデータを書き変えたりできないっぽいです。

モバイル用のクラスはmobilecomponents.swcってのにまとめられてます。

まだあんまり触ってないのでもうちょっといろいろやってみようと思います。

[ 補足 ] Flash Develop 4 アルファ版を使うとコード補完にも対応するみたいです。

銀行の窓口に問い合わせても、端末から口座情報がなくなってるので行員の人は多分探し出せません。（親切な銀行の場合は知りません）

www.missingmoney.com/なんていういかにもな名前のサイトがあります。
ここに自分の名前を入れて検索すると多分見つかります。
見つかったら、そのままクレームするっていうボタンを押して処理してもいいのかもしれませんが、念のため、その州のホームページ( 州名.gov ってやつ )に行きます。
きっとホームページのどこかに、Unclaimed property とかっていうリンクがあるはずなので、そこに行ってもう一回検索すると同じ情報が見つかるはずです。
あとはクレームするっていうような内容のボタンを押して必要情報記入後、書類をダウンロードして必要な身分証明書等を揃えて郵送します。 このときNotary public っていうのがあるんですが、これは日本の公証役場や米国大使館で対応してもらえるようです。(高いけど・・・）

というわけで、大切なジャパンマネーを取り戻しましょうｗ
また、上のサイトや州のサイト行くと個人情報が、名前+住所つきでさらされてしまってますので、個人情報さらさないためにもクレーム入れといた方がいいと思います。日本人名がなんか多かったしw

FacebookやTwitterを実名でやってる人が増えたってのもあるけど米国での個人情報の取り扱いのポリシー的なものは一体どうなってんだろうか？

Facebook app that can edit and share fxg files.
fx editor

Direct Download