Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Jaramillo※本記事は正式版の情報に基づいて更新されています注意:この記事は、複数の密度に対応するオーサリングのサポート、ViewMenuコンポーネント、USBデバッグなど、プレビューリリース以降に追加された新しいモバイルアプリケーション開発機能が含まれるように更新されています。Builderを初めてリリースして以来、様々な種類のプラットフォームに対応したリッチアプリケーションの開発に役立つ生産的な方法の提供を大きな目標にしてきました。OS、Linuxで動作するアプリケーションを構築できるようになりました。Builderは、タッチスクリーン式のスマートフォンやタブレット向けの開発にも対応します。2.6ランタイムを利用しながら、デスクトップ向けの開発と同じ手軽さで、モバイル向けのActionScriptアプリケーションとFlexアプリケーションを開発でき、同様の品質も維持します。Androidプラットフォームに対応したモバイル向けのFlexアプリケーションを構築できます。iOSの両方に対応したモバイル向けのActionScriptアプリケーションを構築することもできます。4.5のリリース後すぐに、iOS向けのFlexアプリケーションの開発を可能にするアップデートをリリースする予定です。Labsからダウンロードできるのは、初期プレビューリリースです。SDKの最終リリースは、5月上旬にダウンロード可能になる予定です。最初のリリースでは、Flexを使用したモバイルデバイス向けの開発に次の3つの要素が含まれます。AIRランタイムを使用して、スタンドアロンインストールのアプリケーションを開発することを想定しています。ハードウェアの「戻る」ボタンやメニューボタンの押下の処理、ローカルストレージへのアクセスなど、FlexはAIRが各モバイルプラットフォームで提供する統合性を最大限に活用します。デベロッパーは、モバイルデバイスに対応したAIRを利用することで、各プラットフォームのネイティブアプリケーションと同じようにデプロイし、必要に応じて販売も行うことができるアプリケーションを開発できます。Marketで配信することができます。エンドユーザーの端末にAIRランタイムが既にインストールされている場合は、ユーザーはAIRアプリケーションをインストールするだけで済みます。反対に、まだAIRランタイムがインストールされていない場合は、AIRアプリケーションを最初に起動したときにAIRランタイムのダウンロードとインストールを促す指示がユーザーに提示されます。AIRデベロッパーセンターを参照してください。Playerに対してもFlexベースの開発を対応させることを目指しています。SDKは堅牢で生産的なフレームワークを提供し、アプリケーションのUI開発やサーバーサイドのデータへのアクセスを実現します。Flexには、組み込みのUIコンポーネント、データアクセスコンポーネント、データバインディング、宣言型言語であるMXMLを使用したUI開発、ダイナミックレイアウト、拡張可能なコンポーネントアーキテクチャなど、豊富な機能が搭載されています。SDKのモバイル機能は、こうしたFlexの主要機能を2つの形で取り入れています。1つは、従来のコンポーネントおよびそのスキンを、タッチスクリーン式のデバイス上でそのまま利用できるように最適化および機能拡張したことです。1つは、スマートフォンに特化した共通のアプリケーションデザインパターンを内蔵した新しいコンポーネントの追加です。SDKを使用したモバイルアプリケーションの開発」で説明します。Builder統合開発環境の4.5リリースは、モバイル向けの開発におけるデザイン、構築、デバッグのための生産的なワークフローを実現します。4.5のモバイル機能は、ActionScriptやFlexをベースにしたモバイルアプリケーションの開発を、デスクトップアプリケーションやWebアプリケーションの開発と同じくらい簡単にすることを目的にしています。4.5を使用したモバイル向け開発ワークフローの合理化」を参照してください。Builderによるデザイン/開発の統合ワークフローの威力をモバイル向けの開発にも反映させることを目指しています。モバイルアプリケーションのデザインと開発に関する留意点タッチスクリーン式のモバイルデバイス用に開発されたアプリケーションには、デスクトップアプリケーションやWebアプリケーションと異なる点がいくつか存在します。タッチ入力で簡単に操作できるようにするためには、一般的に、デスクトップ向けアプリケーションよりも広い範囲のヒット領域が必要です。モバイルデバイス画面のピクセル密度はデスクトップモニターよりも高密度なので、特にこの点は重要です。スクロールなどのアクションに対するインタラクションパターンは、タッチスクリーン式のデバイスでは異なります。画面領域が限られているので、スマートフォンのような小型デバイスで実行するアプリケーションが一度に画面に表示できるUIはほんのわずかです。そのため、デスクトップアプリケーションとは違う形でデザインすることが必要です。UIデザインでは、デバイスごとに変わる画面解像度とピクセル密度の違いを考慮する必要があります。モバイルデバイスの性能は着実に向上しているものの、そのCPUおよびGPUのパフォーマンスは依然としてデスクトップにははるかに及びません。モバイルデバイスで使用できるメモリは限られているので、アプリケーションのメモリ使用量を節約するように気を配ることが必要です。OSによってはいつでもアプリケーションが終了または再起動される可能性があることに注意する必要があります。結果的に、モバイルデバイス向けアプリケーションの開発は、デスクトップアプリケーションを取り出して、様々な画面サイズに合わせて「スケールダウン」させればよいということではありません。アドビが目標としてきたのは、モバイル向けプロジェクトとデスクトップ向けプロジェクトの間で基本的なモデルおよびデータアクセスコードを共有し、開発作業の無駄を最小限に抑えることであり、またデベロッパーがそれぞれのフォームファクターに合わせたユーザーインターフェイスを簡単に構築できるようにすることです。SDKの主要機能を拡張し、モバイル用のデザインパターンや実装パターンに合わせて最適化されたスキンおよびコンポーネントを提供しています。4.5では、いくつかの段階を経て、様々なFlexコアコンポーネントがタッチスクリーン式のデバイス上で正常に動作するかどうかを確認しています。Button、CheckBox、TextInputといったシンプルなコンポーネントに関して、タッチ入力に適したサイズに調整されたスキンを含むモバイルテーマが提供されています。4で導入されたSparkコンポーネントアーキテクチャの柔軟性を利用することによって、コアコンポーネントのコードを修正することなく実現できました。提供されているモバイルスキンはActionScriptで作成されており、最適なパフォーマンスを実現します(これについては後述のパフォーマンスに関する節でも説明します)。4.5に搭載されているモバイルスキンの例を紹介しています。4.5に搭載されているモバイルコンポーネントスキンの例ScrollerやListといったより複雑なコンポーネントについては、タッチ操作によるスクロールができるようにコアコンポーネントに機能が追加されており、スクロールの最後ではバウンスエフェクトとプルエフェクトを使用できます。タッチ操作によるスクロールは、ScrollerおよびListで新しいinteractionModeスタイルをtouchに設定すると有効になります。モバイルテーマを使用する場合は、該当するすべてのコンポーネントでこのスタイルが自動的に設定されているので、タッチ操作を有効にするための作業は必要ありません。モバイルテーマの最初のバージョンでは、すべての従来のSparkコンポーネント向けにタッチ操作対応スキンは用意されていません。4.5でモバイルに対応しているコンポーネントを紹介しています。今後のリリースではさらに多くのコンポーネントが追加される予定です。4.5に搭載されているモバイル対応のコンポーネント標準的なモバイルアプリケーションの構造モバイルデバイスで正常に動作させるために、コアコンポーネントのスキンを作成したり、コアコンポーネントを拡張したりしただけではありません。4.5では新しいアプリケーションコンポーネントのセットも提供されます。これらのコンポーネントは、タッチスクリーン式スマートフォン用の標準デザインパターンを導入したアプリケーションを簡単に構築できるように設計されています。画面領域が限られているので、一般的にこうしたデバイスのアプリケーションは連続したビューの組み合わせで構成されています。それぞれのビューは1つのデータリストまたは1つのデータアイテムの詳細情報を表示します。ユーザーは、データアイテムやその他のコントロールをタップしてビュー間の切り替えを行い、戻る場合は画面のUIまたはハードウェアの「戻る」ボタンを使用します。画面のUIやメニューからその他のアクションを実行できます。図2は、このアプリケーションデザインパターンを示しています。タッチスクリーン式スマートフォン向けの標準的なアプリケーション構造Flexではこうしたパターンをサポートするため、次のコンポーネントが追加されました。ViewViewコンポーネントは、単一のUI画面を表示します。一般的には、ViewをベースにしてカスタムのMXMLコンポーネントまたはActionScriptコンポーネントを作成し、コンテンツ内に表示させたいコンポーネントを追加します。ショッピングカートのアプリケーションの場合には、対象となるアイテムとカテゴリのリストを表示するホームビューを提供することが考えられます。そこから、あるカテゴリをタップして、そのカテゴリ内のアイテムを表示する製品リストビューに移動します。次に、ある製品をタップして、その製品の情報を表示する製品詳細ビューに移動します。この場合、それぞれのViewには、該当するビューで表示されるデータを指定したdataプロパティが使用されています。ユーザーがアプリケーションを操作している間、Viewは相互にデータを受け渡します。dataプロパティを使用することによって、ViewNavigatorおよびViewNavigatorApplicationが、メモリにデータを保存したり、アプリケーションの実行後にデータを維持したりできるようになります(これについては後で説明します)。縦横方向に画面を回転させた場合、デフォルト設定によってViewは適切な縦横比に自動的に調整されます。このため、標準的なFlexレイアウトマネージャーを使用する場合は、デベロッパーサイドで細かく設定しなくても、アプリケーションの縦横比が自動的に変化します。詳細に制御したい場合は、Flexのステートメカニズムを利用して、縦方向ステートと横方向ステートの設定を行い、それぞれのステートでViewがどのように表示されるかを正確に指定できます。ActionBarActionBarは、アプリケーションの各Viewの上部に表示される標準的なヘッダーコンポーネントです。通常、タイトル部分と、現在のビューの更新や新しいアイテムの作成といったアクションを実行する1つ以上のボタンがあります。アプリケーション全体で維持されるコントロールをActionBarに追加したり、ビューごとにActionBarをカスタマイズしたりできます。アプリケーションのホーム画面のActionBarに検索ボックスを配置したりすることが可能です。ViewMenuViewMenuは、ユーザーがデバイス上のメニューボタンを押すと画面の下部に表示される標準コントロールです。任意のビューで、メニューアイテムのセットを含むviewMenuItemsプロパティを追加できます。それぞれのメニューアイテムでは、アイコン、ラベル、およびクリックハンドラーを指定します。ViewMenuは、それ自体の表示と非表示を管理し、メニューアイテムを適切にレイアウトします。ViewNavigatorViewNavigatorは、スタックベースの履歴メカニズムを使用して、アプリケーションのActionBarおよびViewのセットを管理します。アプリケーションが起動すると、ViewNavigatorはfirstViewプロパティで指定したビューを表示します。次に、リストアイテムをタップするなどユーザーの操作に反応して新しいビューに切り替える場合にはpushView()を呼び出し、前のビューに戻る場合にはpopView()を呼び出します。Flexでは、ユーザーがアプリケーションを操作している間にコンテキストを維持できるように、最適化されたビュートランジションがそのまま使用できるようになっています。ViewNavigatorのデフォルトでは、メモリを節約するために、一度に1つのビューしかメモリに保存されません。表示済みのビューのデータはスタックに保存されるので、ユーザーが前のビューに戻っても適切なデータが再表示されます。標準的なViewNavigatorに加えて、TabbedViewNavigatorも提供されています。TabbedViewNavigatorを使用すると、下部のタブをタップして異なるビューのスタック間を切り替えることができます。ViewNavigatorApplicationViewNavigatorApplicationは、こうした機能をすべて1つにまとめた便利なアプリケーションクラスです。ViewNavigatorApplicationをベースにアプリケーションを構築すると、自動的にViewNavigatorがビューの管理を行います。タブ付きアプリケーションには、類似のアプリケーションクラスであるTabbedViewNavigatorApplicationを使用できます。ViewNavigatorApplicationはハードウェアの「戻る」ボタンのデフォルトビヘイビアーを提供し、ViewNavigatorのpopView()メソッドにそれをマッピングします。デバイスの縦横比が変わった場合には、ViewNavigatorと現在のビューにその情報を受け渡して処理します。ViewNavigatorApplicationには、アプリケーションの終了時にそのビューステートとデータを保存する機能が搭載されています。このため、次にアプリケーションが起動したときに、前回と同じビューと閲覧履歴を復元できます。これによって、ユーザーにアプリケーションの中断をまったく意識させることがありません。OSがいつでもアプリケーションを中断または終了させる可能性があるので、モバイルデバイスでは特にこの点は重要になります。Applicationクラスを使用して一からアプリケーションを開発したり、Viewナビゲーションパターンを使わずに主なモバイルコンポーネントとスキンを活用したりしてもかまいません。タブレットアプリケーションを開発している場合は、小さなビューでアプリケーション全体を構築する必要はありません。タブレットは利用できる画面領域が広く、タブレットアプリケーションでは画面切り替えをそれほど必要としないからです。Applicationで開発したいと考える人もいるでしょう。その場合でも、モバイル用に最適化されたコンポーネントとスキンの利点を活かすために、モバイルテーマを使用してください。SDKは単一のフレームワークでモバイルとデスクトップ両方のユースケースに対応しているので、モバイルアプリケーションを開発するときにFlexの機能をすべて使用できます。モバイルデバイスにはパフォーマンスの制約があるので、モバイル向けのFlexアプリケーションを開発する際に注意しなければならない機能や、まったく使用しないほうがよい機能があります。ここで、覚えておくと便利なベストプラクティスを紹介しましょう。アイテムレンダラーを作成する場合は、MXMLではなくActionScriptを使用します。スクロールリストはパフォーマンスに大きく左右されるので、できる限り効率的なアイテムレンダラーを作成することが重要です。モバイルプロジェクト向けにアイテムレンダラーを作成しやすくするため、FlexではLabelItemRendererクラスとIconItemRendererクラスを導入しています。これらのアイテムレンダラーはActionScriptで作成し、IconItemRendererは1つか2つのテキストアイテムの他、左側にオプションのアイコンまたは画像、右側にオプションの装飾アイテムを表示するように構成できます。この方法がニーズに合わない場合は、代わりにこれらのクラスをサブクラス化して、ActionScriptでコントロールを追加したり、レイアウトしたりできます。可能であれば、コンポーネントスキンには、MXMLとランタイムMXMLグラフィックスではなく、ActionScriptとコンパイルされたFXGグラフィックスまたはビットマップを使用してください。アイテムレンダラーと同様、最善の方法はコンポーネントスキンを軽量化することです。Flexのモバイルテーマで提供されているスキンはすべて、ActionScriptで直接作成されたもので、サブクラス化してFXGグラフィックスの置き換えやレイアウトの変更に使用することもできます。いっても、MXMLスキンが抱えるパフォーマンスの課題は、アイテムレンダラーの場合ほど深刻ではないので、アプリケーションの様々な部分でMXMLスキンを多少使用しても、パフォーマンスに大きな影響を与えることはありません。チャートはモバイルプロジェクトでも使用できますが、その他のMXコンポーネントはサポートされていません。モバイルプロジェクトでMXコンポーネントを使うことはお勧めしません。代わりにSparkコンポーネントを使用してください。チャートコンポーネントだけは例外です。このコンポーネントはモバイルプロジェクトでも使用できますが、一度にたくさんのデータを表示したりアニメーション化したりしないように注意してください。通常、テキストには、RichTextおよびRichTextEditableではなく、SparkのLabel、TextInput、TextAreaを使用します。ほとんどのUIテキストには、パフォーマンスを最大化するためにTextFieldベースのテキストを使用することをお勧めします。SDKのモバイルスキンおよびアイテムレンダラーはこのガイドラインに従っています。リッチコンテンツの表示が必要なケースでは、TLFベースのRichTextを使用できますが、モバイルプロジェクトで使用するUIエレメントに使用することは推奨しません。複数のピクセル密度へのモバイルアプリケーションの適合モバイルデバイスは、画面の小さなスマートフォンから画面の大きなタブレットまで様々なフォームファクターで提供されます。画面のサイズと縦横比の単純な変動は、Flexで提供されている標準ダイナミックレイアウトコンポーネントを使って簡単に処理できます。ピクセル密度、つまり画面1インチあたりのピクセル数もデバイスごとに異なります。ピクセル密度が異なると、ユーザーインターフェイスに表示される個々のエレメントのサイズが変化します。その他の条件がすべて同じであれば、あるピクセルサイズのコントロールは、ピクセル密度が高いデバイス上では物理的に小さく表示されます。タッチスクリーン式のインターフェイスではコントロールを指で操作できるように十分に大きくする必要があるので、このことは特に問題になります。4.5には、複数の密度に対応したアプリケーションの開発に役立つ新機能がいくつか備わっています。デベロッパーは、アプリケーションでapplicationDPIプロパティを設定することによってアプリケーションのターゲットDPIを指定できます。この設定が明示的に行われている場合、デベロッパーは、スキンとレイアウトを所定のDPIのデバイス上で実行しているものとして設定する必要があります。実行時に、デバイスのDPIが指定したターゲットDPIとは異なる場合、Flexによってアプリケーション全体のサイズが自動的に調整され、アプリケーションとそのコントロールのおおよその物理的なサイズが維持されます。DPIのデバイス上ではアプリケーションが自動的に1.5xに拡大されます。この機能を使用しない場合は、実行時にカスタムスキンとビューレイアウトを異なるピクセル密度に適切に適合させる必要があります。自動サイズ変更を使用する場合には、applicationDPIを、サポートする必要がある最低のDPIに設定し、それよりもDPIが高いデバイス上でアプリケーションを拡大できるようにすることを推奨します。これは、ベクトルアートワークを縮小するのではなく拡大する方が、見栄えが良くなり配置が一貫したものになる傾向があるためです。ビットマップの場合は、後述するマルチDPIビットマップサポートを利用する必要があります。DPI対応モバイルスキン。4.5に付属のモバイルテーマに含まれている組み込みスキンは、異なるDPIに自動的に適合します。自動サイズ変更を使用している場合、指定したapplicationDPIに合わせて組み込みスキンが自動的に設定され、自動サイズ変更機能によって拡大されます。自動サイズ変更を使用していない場合、スキンはデバイスの実際のランタイムDPIに適合します。組み込みスキンの動作方法を調べることで、独自のカスタムスキンを作成するときに同じパターンに従うことができます。マルチDPIビットマップ。アプリケーションにビットマップアートワークを使用する場合、サイズ変更による影響を避けるため、異なるDPI用に複数の解像度で各ビットマップを用意する必要があります。そのために、MultiDPIBitmapSourceクラスを利用すると、所定の画像について異なるDPIで使用する異なるビットマップファイルを指定できます。このクラスは、BitmapImageやImageコンポーネントなど、画像を表示するコンポーネントのsourceプロパティとして、またはButtonのiconプロパティとして渡すことができます。モバイルスキンと同様、これらのビットマップはフレームワークによって適切に処理され、自動サイズ変更を使用しているかどうかにかかわらず所定のデバイスのDPIに対して常に適切な解像度のビットマップが表示されるようになります。DPI別のCSSルール。4.5はCSSの@media構文をサポートしており、所定のDPIにのみ適用するCSSルールを指定できます。組み込みスキンはこれを利用して、異なるDPIにフォントサイズと余白を適合させます。この構文を使ってプラットフォーム別のCSSルールを指定することもできます。密度に対応したアプリケーションの作成について詳しくは、[複数の密度に対応したアプリケーションの作成に関するADCの記事へのリンク]を参照してください。カメラなど、モバイルデバイス上のAIRで利用可能なAPIを直接活用できることも覚えておいてください。した機能の中にはFlexコンポーネントとして提供されていないものもありますが、ActionScriptを使うと直接簡単に利用できます。モバイルデバイス上のAIRで提供されているAPIを使用した開発について詳しくは、AIRモバイルドキュメントを参照してください。4.5は、従来のActionScriptおよびFlexの開発ワークフローをモバイル向け開発にも対応するように拡張し、プロジェクト作成から完成したアプリケーションのパッケージ化までをサポートします。4.5は、ActionScriptモバイルプロジェクトとFlexモバイルプロジェクトという2種類の新しいプロジェクトタイプを導入しています。ActionScriptモバイルプロジェクトを作成すると、完全に白紙の状態からスタートし純粋なActionScriptコードでアプリケーションを開発できます。Builderの機能も利用できます。4.5リリースは、Androidのモバイル向けFlexプロジェクトの構築、およびAndroidとiOSの両方のモバイル向けActionScriptプロジェクトの構築をサポートしています。4.5リリースの提供後すぐに、iOS用のFlex開発を可能にするアップデートを提供する予定です。デスクトップ/Webアプリケーションやモバイルアプリケーションなど、マルチスクリーン対応のアプリケーションを作成する場合、一般的なプロジェクト構造は、デスクトップまたはWebのUIを開発する通常のFlexプロジェクトまたはActionScriptプロジェクト、モバイルのUIを開発するモバイル向けFlexプロジェクトまたはActionScriptプロジェクト、そして2つのアプリケーション間で共有するモデルやデータアクセスコードを含むライブラリプロジェクトで構成されます。ビューの設計モバイル向けFlexプロジェクトで使用するデザインモードは2つの方法で拡張されています。デザインツールバー(図3を参照)には、異なる画面サイズや縦横比でビューのコンテンツがどのように表示されるかをプレビューできるコントロールが追加されました。Configurations(デバイス設定)を選択し、様々なデバイス設定を自分で追加できます。モバイルデバイスの設定用に提供されているデザインモードのコントロール次に、デザインモードは前述の標準的なビューナビゲーション構造と連携するようになりました。ViewNavigatorApplicationをベースにしたプロジェクトでViewを編集する場合、全体的なアプリケーション構造に沿ってViewのコンテンツが表示されます。Viewの上部にActionBarがあり、ActionBarにはそのViewに対応したコンテンツが配置されています。特定のView向けにActionBarをカスタマイズする場合、他のコンテナと同じようにActionBarにコントロールをドラッグ&ドロップします。図4は、ActionBarの右端にあるactionContentエリアにボタンをドロップしているところです。デザインモードでActionBarにボタンをドロップするところまた、デザインモードは、アプリケーションでピクセル密度のエフェクトを正しくプレビューします。DPI用に設定されたプレビューデバイスを選択した場合、デザインモードはアプリケーションを1.5xに拡大して表示します。デスクトップ上でもデバイス上でもできるアプリケーションの実行とデバッグアプリケーションのテストやデバッグを行う場合には、2つの選択肢があります。Launcher(ADL)を使用して、デスクトップ上でアプリケーションを起動し、デバッグします。厳密に行いたいときには、実際のデバイス上で直接アプリケーションを起動し、デバッグします。Builderのすべてのデバッグ機能を使用できます。デバイス上で実行またはデバッグする場合、注意しなければならない重要な点がいくつかあります。アプリケーションがデータにアクセスする場合、WiFiまたは携帯電話ネットワーク経由でデバイスからアクセスできるサーバーにデータサービスを必ずデプロイする必要があります。デスクトップ上でローカルホストに対してアプリケーションをテストしている場合、デバイスの「ローカルホスト」はそのデバイス自体となるので、デバイス上では動作しません。4.5の最終リリースは、WiFi経由でのデバッグのみをサポートしていたプレビューリリースとは異なり、Androidデバイス上で直接的なUSB経由でのデバッグをサポートしています。実際のiOSデバイス上でActionScriptモバイルプロジェクトを実行、デバッグ、またはデプロイするには、Appleからプロビジョニングプロファイルおよび証明書を入手する必要があります。iTunesを使用しているデバイス上で手動でアプリケーションをデプロイし、そのデバイス自体で起動する必要があります。プロファイリングは、現在デバイスに対応していません。デスクトップ限定の機能です。デプロイメントに合わせたアプリケーションのパッケージ化アプリケーションが完成し配信準備が整ったら、デスクトップアプリケーションやWebアプリケーションをデプロイするときと同じように、エクスポート/リリースビルドのプロセスを使用します。Builderが.airファイルではなくネイティブインストーラーとしてビルドをパッケージ化する点です。Androidの場合は、ネイティブのAndroidアプリケーションパッケージと同じような.apkファイルを生成します。これにより、上述のように、各プラットフォームのネイティブアプリケーションと同じ方法で、AIRベースのアプリケーションを配信したり、販売したりできるようになります。Builderがモバイル向けの開発に対応できるようになりました。プレビュー版なのですべての機能が搭載されているわけではありません。最終版では、より多くの機能が導入される予定です。SDKを使って魅力的なモバイルアプリケーションを構築してみてください。以下は、製品をすぐに使い始める上で役立つリソースです。製品に関するご質問やフィードバックもお寄せください。Licenseのもと提供しています。JaramilloはFlex製品ラインの製品デザインを統括しています(場合によってはコードを記述することもあります)。1.0のエンジニアとしてMacromediaに入社し、その後、数バージョンにわたって製品デザインと製品開発のリーダを務めてきました。ContributeのデザインおよびUI開発でもリーダを務めるとともに、Macromedia製品の統一UIのデザインにも携わってきました。余暇は、愛娘の写真を多すぎるほど撮影して過ごすとともに、ジャズピアノの演奏を楽しんでいます。something*を参照してください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。