新機能

提供: Appmethod Topics
移動先: 案内検索

目次

Appmethod 1.14 の新機能

Appmethod への C++ の追加

Appmethod 1.14 で C++ プログラミング言語をサポートするようになりました。

詳細については、「マルチデバイス アプリケーション」を参照してください。

C++ Android では自動参照カウント(ARC)が有効

  • C++ Android では、Object Pascal Android との互換性を保つために自動参照カウント機能(ARC)を使用します。
    ARC の管理はすべて C++ Android コンパイラ内部で処理されるため、C++ Android ARC 環境で作業するためにやり方を変える必要はまったくありません。C++ コードでは、これまでどおり Object Pascal クラス インスタンスのポインタ構文を使用できます。C++ Android コンパイラではこれらのポインタを特殊なポインタとして扱うので、宣言も使用法も変更する必要はありません。
  • 詳細については、「C++ での自動参照カウント」を参照してください。

C++ で 64 ビット Windows 用のパッケージをサポート

C++ では、64 ビット Windows 用パッケージの作成をサポートしています。C++ コンパイラによって Win64 用の .bpl ファイルが生成されます。Appmethod C++ では Mac 用の .dylib ファイルや iOS および Android プラットフォーム用のパッケージは生成されないことに注意してください。これらのプラットフォームの場合は、静的ライブラリを使用できます。

Win32 パッケージと Win64 パッケージの相違点

  • Win64 の場合、PACKAGE と指定されているコード要素が現在のトランスレーション ユニットに定義されていれば、コンパイラではそれらのコード要素をエクスポートします。クラスの場合、メンバでないコード要素が 1 つでも定義されていれば、そのクラスはエクスポートされます。定義が見つからなければ、コンパイラはそのコード要素をインポートされるものとして扱います。この動作は Win32 の場合とは異なります。
  • Win32 と Win64 のどちらの場合も PACKAGE を使用する必要がありますが、Win64 では定義が存在する場合にのみエクスポートします。この要件は、パッケージを使用する側に公開されることになっている変数、関数、クラスに適用されます。

例:

class PACKAGE TTest : public System::TObject {
private:
  int FProp;
  __property int Prop = {read=FProp, write=FProp};
public:
  __fastcall TTest(void);
  __fastcall virtual ~TTest(void);
};
PACKAGE bool GoodieFlag;
PACKAGE void __fastcall SuperFunc(const System::UnicodeString S);

Win64 パッケージの要件

  • パッケージからコンポーネント クラスをエクスポートするには、コンポーネントごとに非インライン メンバが少なくとも 1 つ必ず存在するようにします(これは、 [コンポーネント|コンポーネントの新規作成... で開く[コンポーネントの新規作成]ウィザードで自動的に行われます)。
  • 以前、[パッケージの出力ディレクトリ]を設定して Win32 パッケージを生成した場合は、[ツール|オプション...|環境オプション|C++ オプション|パスとディレクトリページで Win64 プロジェクトの場合のパスを必ず変更して、Win32 パッケージが上書きされないようにします。

モバイル アプリケーションの Object Pascal コンパイラ指令 HPPEMIT

C++ 名前空間宣言のリンクと生成に ${HPPEMIT} 指令を使用できるようになりました。

  • {$HPPEMIT NOUSINGNAMESPACE} を指定すると、"using namespace <ユニット名>;" が生成されなくなります。
  • Android および iOS デバイス ターゲット プラットフォームについては、{$HPPEMIT LINKUNIT}#pragma link の代わりに使用されるようになりました。

詳細については $HPPEMIT を参照してください。

1.14 向けに行われた C++ コンパイラの変更点

宣言には型が必要(Clang ベースの C++ コンパイラの場合のみ)

WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int)
{
  ...
}
上記コードの場合は、次のようなエラーが発生します。
 C++ ではあらゆる宣言に型指定子が必要です
このエラーを修正するには、コードを次のように更新します。
int WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int)
{
  ...
}

オープン配列定義では Data_Size ではなく Data_High を使用

オープン配列定義の第 2 パラメータが配列のサイズから 1 を差し引いたものであることを明確にするために、Data_Size パラメータが Data_High という名前に変更されました。

詳細については、「オープン配列」の「オープン配列のサポート」セクションを参照してください。

C++ の LD リンカでは .map ファイルの生成が無効に

iOS と Android のどちらの場合にも[シンボル ファイル (.map) を生成]オプションが無効になりました。.map ファイルを生成する必要がある場合は、[プロジェクト|オプション...|C++ リンカページの[シンボル ファイル (.map) を生成]を選択します。

定義の検索/参照箇所の検索

Clang ベースの C++ コンパイラBCC64、BCCIOSARM、BCCAARM)で、新しく定義の検索と参照箇所の検索の機能をサポートするようになりました。Appmethod には、コード エディタで識別子を右クリックしたときにコンテキスト メニューで使用できる[検索]コマンド(C++ の場合)が用意されています。これらのコマンドは、識別子の種類に応じて、プログラミング作業の生産性を向上させるさまざまな情報を返します。たとえば、選択した識別子のプロジェクト全体におけるすべての参照箇所、識別子の宣言、基底クラスまたは派生クラス(識別子がクラスを参照している場合)などを取得できます。

この機能については、「1.14 での IDE の変更点」(C++ の参照箇所の検索/定義の検索用の新しいメニュー項目および結果ペイン)で詳しく紹介しています。

詳細については、「定義と参照箇所の検索(C++)」を参照してください。

Object Pascal コンパイラの変更点

コンパイラ指令 $LIBVERSION では、ファイル拡張子(.dll、.dylib、.bpl、.map、.rsm など)のにライブラリ バージョン データが付加されなくなりました。代わりに、ライブラリ バージョン データは $LIBSUFFIX 文字列があればその後およびファイル名の後(ただし、生成された拡張子の)に挿入されます。

これらの指令($LIBPREFIX、$LIBSUFFIX、$LIBVERSION)はすべて [プロジェクト|オプション...|説明ページで設定することができます。

FireMonkey の変更点

サポートされていない Android デバイス アーキテクチャの検出

Appmethod でサポートされていない CPU アーキテクチャのデバイスで FireMonkey アプリケーションを起動すると、アプリケーションはそのデバイスに次のようなエラー メッセージを表示するようになりました。

Application not supported by this device(アプリケーションはこのデバイスではサポートされていません) 

この機能を実装するために、配置マネージャでは、お使いの Android .apk パッケージに 3 つの小さいネイティブコード ライブラリを組み込みます。これらのライブラリは、FireMonkey アプリケーションでサポートされていない次のアーキテクチャ向けに作成されています。

  • ARMv6
  • Intel x86
  • MIPS

これら 3 つのライブラリ内のコードで、上記のエラー メッセージが表示されます。

下図のとおり、これらのネイティブ ライブラリを配置マネージャで確認できます(強調表示されている行を参照)。

DeplyMgrAndroidDetectors.png

重要: Google Play ストアで公開するためにアプリケーションを構築する場合は、配置マネージャでこれらの追加ライブラリのチェック ボックスをオフにすることで、それらを無効にしなければなりません。これにより、これらのライブラリが .apk パッケージに含まれなくなり、アプリケーションのデバイス要件を Google Play ストアで正しく判断できるようになります。

以下に例を示します。

DeployMgrWithDisabledARMEABIlib.png
メモ: Android 4.0.x 搭載のデバイス(一部の Kindle Fire タブレットを含む)では、アプリケーションに互換性がないという誤った通知が表示されるおそれがあります(これは Android 4.0.x ライブラリ ローダーのバグによるものです)。この問題を解決するには、新しいバージョンの Android をデバイスにインストールするか、ARMv6(armeabi)ネイティブ ライブラリを配置対象から削除します。後者の場合は、上図に示したとおり、配置マネージャarmeabi ライブラリのチェック ボックスをオフにします。

サポートされている Android デバイスの一覧については、「アプリケーション開発に対応している Android デバイス」を参照してください。

Mac OS X Lion(10.7)のサポートの終了

Mountain Lion(10.8)のサポートは継続します。また、新しい Mavericks(10.9)がサポートされるようになりました。

詳細については、「FireMonkey プラットフォームに必要な準備」および「Mac OS X のアプリケーション開発」を参照してください。

アプリ内決済サービス

アプリ内決済サービスを利用すると、iOS および Android アプリケーション内でデジタル コンテンツを直接販売することができます。FireMonkey には、TInAppPurchase というコンポーネントが用意されるようになりました。これにより、Google PlayiTunes などのアプリ内決済サービスをたやすくサポートできるようになります。

詳細については、「モバイル アプリケーションへのアプリ内決済機能の追加」を参照してください。

広告サービス

広告サービスを利用すると、iOS および Android アプリケーションで広告を表示して、収入を得ることができます。FireMonkey には、TBannerAd というコンポーネントが用意されるようになりました。これにより、AdMobiAd などの広告サービスをたやすくサポートできるようになります。

詳細については、「モバイル アプリケーションへの広告機能の追加」を参照してください。

Google Glass 用の新しい FireMonkey スタイル

FireMonkey には、Google Glass デバイス用の新しいスタイルが用意されています。このスタイル ファイルは下記のとおりです。

C:\Users\Public\Documents\Embarcadero\Studio\14.0\Styles\Android\GoogleGlass.fsf

GoogleGlass.fsf スタイルは Google Glass のユーザー インターフェイスおよび解像度に最適化されています。

GoogleGlass.fsf を Google Glass アプリケーションに追加するには、 「FireMonkey アプリケーションにカスタム スタイルを追加する」で説明している手順に従います。

詳細については、「Google Glass 向けのアプリケーションの作成」を参照してください。

デスクトップ プラットフォームで GPU キャンバスを有効化可能

GPU キャンバスは、モバイル プラットフォームではデフォルトで使われています。その GPU キャンバスを Windows でも使用できるようになりました。GPU キャンバスを有効にするには、initialization セクションでグローバル変数 FMX.Types.GlobalUseGPUCanvasTrue に設定するだけです。

GPU レンダリングの他に、GPU キャンバスではテキスト レンダリング技術も使用していますが、これはテキストを処理する際に特に役立ちます。

FMX.Grid の変更点

TGrid は、パフォーマンスとスクロール動作を改善するために、内部的にリファクタリングされました。 TGrid では、セルの描画をグリッド列に委譲します。各列では、デフォルトの描画メソッドまたは IDrawableCell インターフェイスを使用して、列のセルを描画できます。

さらに、TGrid からのイベントを使ってカスタム セル描画を処理できるようになりました。 TCustomGrid には、OnDrawColumnCellOnDrawColumnHeader の 2 つの新しい描画イベントがあります。

動作と外見に関するいくつかのプロパティが 1 つのグリッド プロパティ TCustomGrid.Options に集約されています。

その他にも、次のような新しい機能があります。

FireMonkey 列挙型の変更点

列挙型の識別子名にはプレフィックスがない

1.14 では、FireMonkey の列挙型スコープのある列挙型として扱われ、列挙型のメンバとなる識別子名は、プレフィックスを削除して再宣言されています。

たとえば、1.13 では、TVKAutoShowMode は、次のように、vkas プレフィックスを付けて定義されていました。

TVKAutoShowMode = (DefinedBySystem, Never, Always); // 1.13 の場合
TVKAutoShowMode = (DefinedBySystem, Never, Always); // 1.14 の場合

列挙型のメンバとなる識別子にプレフィックスが付いていることで、それら識別子の名前がグローバル スコープ内で一意になりました。FireMonkey におけるスコープのある列挙型の例としては、その他に、TPaintStage などがあります。

DefinedBySystem などの従来のプレフィックス付き識別子が含まれている既存コードでも、エラーなくコンパイルされるはずです。ただし、プレフィックス付き識別子がある場合には、コンパイラから警告が出力され、古い形式の列挙識別子が使用されていることと、それらを正しい名前に置き換えるべきであることを知らせます。

列挙型のメンバ名は列挙型名で修飾される必要あり

ほとんどの FireMonkey ユニットでは、{$SCOPEDENUMS ON} コンパイラ指令が有効になっています(「厳密な型指定の列挙型(C++0x)」も参照)。 {$SCOPEDENUMS ON} コンパイラ指令が有効な場合は、この指令の後で(最も近い {$SCOPEDENUMS OFF} 指令までに)宣言された列挙型に定義されているすべての識別子はグローバル スコープに追加されないことを明示しています。その場合、スコープのある列挙型のメンバを指定するには、その列挙型の型でメンバを限定する必要があります。

たとえば、列挙型 TVKAutoShowMode は、次のように定義されるようになりました。

{$SCOPEDENUMS ON}
...
TVKAutoShowMode = (DefinedBySystem, Never, Always);
...

{$SCOPEDENUMS ON} 指令があるので、TVKAutoShowMode の識別子(DefinedBySystemNeverAlways)は、次のように、列挙型名で修飾されなければなりません。

TVKAutoShowMode.DefinedBySystem

FireMonkey API の新規追加および変更

新規の SelectDirectory 関数

FMX.Dialogs.SelectDirectory が追加されました。

FMX.WebBrowser.TWebBrowser の新規メソッド

  • 今回 FireMonkey では、TWebBrowser コンポーネントに LoadFromStrings メソッドと EvaluateJavaScript メソッドが用意されています。
    • LoadFromStrings では、TWebBrowser コンポーネント内に HTML 文字列コンテンツを表示します。
    • EvaluateJavaScript では、HTML ページにカスタム JavaScript を追加し、それを直ちに実行します。

詳細とサンプルについては、「モバイル チュートリアル:Web ブラウザ コンポーネントを使用する(iOS および Android)」を参照してください。

新規の日付/時刻コントロール

FireMonkey には、アプリケーションの日付/時刻コントロールとなる新しいコンポーネントが次の 2 つ用意されるようになりました。

  • TDateEdit: 日付が格納された編集可能な単一行のテキスト ボックスを表します。TDateEdit コントロールをクリックまたはタップすると、日付を選択できる日付ピッカーが表示されます。
  • TTimeEdit: 指定された時刻が格納された編集可能な単一行のテキスト ボックスを表します。TTimeEdit コントロールをクリックまたはタップすると、時刻を選択できる時刻ピッカーが表示されます。

メモTCalendarEdit は非推奨になりました。TDateEdit を代わりに使用してください。

詳細とサンプルについては、「モバイル チュートリアル:カレンダー コンポーネントを使用して日付を選択する(iOS および Android)」を参照してください。


列挙型 TPixelFormat

FMX.PixelFormats ユニットはリファクタリングされ、現在では FMX.Types の構成要素(新しい FMX.Types.TPixelFormat 列挙型など)になっています。一貫性がありかつ明快になるように、新しい TPixelFormat の列挙値は、FMX.PixelFormats.TPixelFormat に使用されていたものとは異なります。

  • 異なるピクセル形式間の変換を行う関数も FMX.Types に移動しました。それには以下のものがあります。
  • 新しい FMX.Types.TPixelFormat 列挙型は以下のように解釈されます。
    • 列挙型に含まれている文字の順序が、チャネルの物理的な順序になります。
      • "R" は赤チャネルを意味します。
      • "G" は緑チャネルを意味します。
      • "B" は青チャネルを意味します。
      • "L" は輝度チャネルを意味します。
      • "A" はアルファ チャネルを意味します。
    • 末尾に数字がない場合、各成分は 8 ビットになります。
      例: RGB は、赤チャネルが 8 ビット、緑チャネルが 8 ビット、青チャネルが 8 ビットであることを意味します。
    • 末尾に数字がある場合、このビット数は各チャネルに対応します。
      例: RGBA16 は、赤、緑、青、アルファの各チャネルごとに 16 ビット、全体で 64 ビット(16 + 16 + 16 + 16)であることを意味します。
    • ビット数の合計は 8 ビット、16 ビット、32 ビット、64 ビットのいずれかに切り上げられます。
      例: RGB(8 + 8 + 8 = 24)は 32 ビットになります(32 ビットに切り上げられます)。
    • "F" が末尾にある場合は、浮動小数点ピクセル形式になり、そうでない場合は整数形式になります。
      通常、FireMonkey では、すべての整数形式が符号なし整数 "正規化" 形式として扱われると仮定します(つまり、最小および最大の整数値がシェーダで 0.0 ~ 1.0 の範囲の数値にマッピングされます)。
    上記ルールの例外:
    • BGR_565 は 16 ビット形式(青チャネルと赤チャネルに 5 ビットずつ、緑チャネルに 6 ビット)です。
    • BGR5_A1 は 16 ビット形式(赤チャネル、緑チャネル、青チャネルに 5 ビットずつ、アルファ チャネルに 1 ビット)です。
    • BGR10_A2 は 32 ビット形式(赤チャネル、緑チャネル、青チャネルに 10 ビットずつ、アルファ チャネルに 2 ビット)です。
    • RGB10_A2 は上記と同じです(ただし、赤チャネル、緑チャネル、青チャネルの物理的な順序が逆になります)。

TAlphaColorF レコード/構造体

  • System.UITypes.TAlphaColorF は、RGBA の各成分を浮動小数点数として扱う新しい色の型です。
    • オーバーロードされた演算子では、以下のように、通常の演算を使用して色の加算、減算、乗算を行えます。
      FinalColor := (FirstColor + SecondColor) / 2
    • これまで、ピクセル形式の変換は TVector3D に基づいており、それは色として扱われていましたが、現在、変換では TAlphaColorF を使用しています。

ボタン、TListView のテキスト ボタン、ツールバーの TintColor プロパティと IconTintColor プロパティ

  • FireMonkey では、ボタンの濃淡の付け方を決定する TintColor プロパティと IconTintColor プロパティが TButton コンポーネントと TSpeedButton コンポーネントに用意されています。
    • TintColor はボタンの背景色を指定します。
    • IconTintColor は、スタイル付きボタンのボタン アイコンの色を指定します。
  • FireMonkey では、ツールバーの濃淡の付け方を決定する TintColor プロパティが TToolBar コンポーネントに用意されています。
  • FireMonkey では、TListView のテキスト ボタンに濃淡を付けるために使用できる TintColor プロパティが TListItemTextButton クラスに用意されています。

詳細とサンプルについては、以下のチュートリアルを参照してください。

EnumControls では任意の条件でコントロールを省略可能

FMX.Controls.TControl.EnumControls は非推奨になり、同じ名前の新しいバージョンに置き換わりました。コードでは、今後、この新しいバージョンを使用しなければなりません。

  • これまでのリリースでは、TControl.EnumControls 手続きには次の 2 つのパラメータが必要でした。
    • 検索中にコントロールにアクセスしたときに呼び出す無名手続き
    • 非表示コントロールを検索から省くかどうかを決定する論理型引数
    いつでもこの無名メソッドで <Done> パラメータの値を変更して検索を中止することができますし、TControl.EnumControls の呼び出し時に <VisibleOnly> を True に設定して検索時に非表示コントロールの子を省くこともできます。
  • 1.14 では、TControl.EnumControls の新しいバージョンを使用することで、コントロールが表示されているかどうかだけでなく、任意の条件に基づいて、コントロールとそれらの子を検索から省くことができます。
    TControl.EnumControls に必要なパラメータは 1 つだけ、つまり無名関数のみになりました。この関数はコントロールを受け取り、次に何をするか(検索を通常どおり続行する、検索は続行するが受け取ったコントロールの子を省く、検索を終了する、のいずれか)を決定する戻り値を返します。

FMX.TabControl.TTabControl クラスの新規メンバ

FireMonkey では、TTabControl コンポーネントに次の新しいメソッドおよびプロパティが用意されるようになりました。

  • Add: タブ コントロールの末尾に新しいタブを追加します。
  • Insert: 特定の位置に新しいタブを追加します。
  • Delete: タブ コントロールからタブを削除します。
  • Next: 表示されている次のタブをアクティブなタブにします。
  • Previous: 表示されている前のタブをアクティブなタブにします。


RTL の変更点

アプリケーション テザリングを使用したデバイス横断的なアプリケーション間のやり取り

RTL には、アプリケーションが、同じマシンまたはリモート マシンで動作する他のアプリケーションとやり取りできるようになる新しいコンポーネントが用意されるようになりました。アプリケーションでアプリケーション テザリングを使用して以下のことができます。

RTL には、アプリケーション間の接続のアプリケーション テザリングを目的としたパスワード ベースのセキュリティが用意されています。このパスワードベースのシステムを使用して、独自のセキュリティ手順を実装することができます。たとえば、次のようなことが可能になります。

  • アプリケーションどうしが互いを検出したときにそれらのアプリケーションを自動的に接続させ、それをユーザーに意識させない。
  • ユーザーが両方のアプリケーションに手動でパスワードを入力することで、それらのアプリケーションを接続させる。

アプリケーション テザリング機能は特定のトランスポートやプロトコルに依存しません。1.14 の RTL では、同じデバイスで動作するアプリケーションも含め、同じローカル エリア ネットワーク(LAN)上にあるアプリケーション間の Ethernet 接続をサポートしています。アプリケーション テザリング API を使用すれば、新しいトランスポートやプロトコルをサポートする独自のアダプタを実装できます。

TWebBrowser の更新

Windows で使用できる Web ブラウザ(SHDocVw.TWebBrowser)は Internet Explorer の最新版に更新されました。

データベースの変更点

FireDAC の変更点

  • TFDMemTable 設計時向けの機能強化により、バイナリ ファイル、XML ファイル、JSON ファイルからのデータの読み込みとこれらのファイルへのデータの保存が可能になりました。また、設計時に他のデータセットのデータを TFDMemTable に割り当てることもできます。
  • [データ エクスプローラ] [データ エクスプローラ]には、フォームへの FireDAC コンポーネントのドラッグ アンド ドロップや[データ エクスプローラ]での FireDAC 接続の作成などが可能な[FireDAC]ノードが含まれるようになりました。
  • ローカル SQL の改良によるアドホック データセットの取り扱いの向上:
    • TFDCustomLocalSQLTFDLocalSQL で API が変更されています。
    • 単一の TFDLocalSQL で複数のスキーマを処理可能:
      • TObject だけでなく IInterface も DS 接続オブジェクトになれます。
      • DS セーブポイントは int64 にできます。
      • 一時データセットやガベージ データセットの自動的削除
      • カスタム データセット アダプタのレジストリ
  • ストリーミングのリファクタリングと JSON シリアル化形式:
    • 新規の FireDAC.Stan.StorageBin/XML/JSON ユニット。
    • それぞれのシリアル化形式は疎結合型の FireDAC.Stan.StorageXxx ユニットに移動しました。
    • 形式ごとに TFDStanStorageXxxLink コンポーネントが追加されました。
    • XML/JSON の書式設定を制御するために TFDResourceOptions.StorePrettyPrint が追加されました。
    • JSON シリアル化形式が実装され、sfJSON が TFDResourceOptions.DefaultStoreFormat に追加されました。
  • 新規の FireDAC Informix ネイティブ ドライバ:
    • Informix ODBC ドライバをベースにしています。
    • Win32 と Win64 の両方をサポートしています。
  • TFDPhysXxxxDriverLink コンポーネントの使用は任意になりました:
    • FireDAC の設計時コードでは、必要な FireDAC ドライバ実装ユニットが "uses" 句に自動的に追加されます。
    • DBMS クライアント ライブラリをセットアップする必要があるときは TFDPhysXxxxDriverLink コンポーネントを使用します。
    • FireDAC では、SQL Server 2008 テーブルを値とするパラメータをサポートしています。
      • パラメータの種類としては ptInput のみサポートしています(MSSQL の制限)。
      • テーブルを値とするパラメータのデータ型は ftDataSet です。
      • ストアド プロシージャの場合、TFDParam.DataTypeName は任意指定ですが、DML コマンドの場合、TFDParam.DataTypeName は必須です。
  • データセットの自動フィールドと永続フィールドの制御:

FireDAC の Informix 接続定義例

    DriverID=Infx
    Server=ol_informix1170
    Database=sysuser
    User_Name=informix
    Password=mypwd
    MetaDefSchema=informix

FireDAC の SQL Server テーブル タイプとストアド プロシージャ

     create type TVPType as table(Code integer, Name varchar(100), Notes varchar(max))
     go
     create table TVPTab(Code integer, Name varchar(100), Notes varchar(max))
     go
     create procedure TVPProc(@Items TVPType readonly)
     as
       delete from TVPTab;
       insert into TVPTab (Code, Name, Notes)
       select Code, Name, Notes
       from @Items;
     go

Object Pascal での SQL Server TVP の使用(FireDAC の場合)

     // プロシージャ メタデータの自動的な取得とセットアップ
     FDStoredProc1.StoredProcName := 'TVPProc';
     FDStoredProc1.Prepare;
     FDStoredProc1.Params[1].AsDataSet.AppendRecord([1, 'str1', 'long value 1']);
     FDStoredProc1.Params[1].AsDataSet.AppendRecord([2, 'str2', 'long value 2']);
     FDStoredProc1.Params[1].AsDataSet.AppendRecord([3, 'str3', 'long value 3']);
     FDStoredProc1.ExecProc;

     // プロシージャの手動セットアップ
     FDStoredProc1.FetchOptions.Items := FDStoredProc1.FetchOptions.Items - [fiMeta];
     FDStoredProc1.StoredProcName := 'TVPProc';
     FDStoredProc1.Params.Clear;
     FDStoredProc1.Params.Add('@RETURN_VALUE', ftInteger, -1, ptResult);
     oDS := TFDMemTable.Create(nil);
     oDS.FieldDefs.Add('Code', ftInteger);
     oDS.FieldDefs.Add('Name', ftString);
     oDS.FieldDefs.Add('Notes', ftMemo);
     with FDStoredProc1.Params.Add('@Items', ftDataSet, -1, ptInput) do begin
       DataTypeName := 'TVPType';
            AsDataSet := oDS;
          end;
     FDStoredProc1.Params[1].AsDataSet.AppendRecord([1, 'str1', 'long value 1']);
     FDStoredProc1.Params[1].AsDataSet.AppendRecord([2, 'str2', 'long value 2']);
     FDStoredProc1.Params[1].AsDataSet.AppendRecord([3, 'str3', 'long value 3']);
     FDStoredProc1.ExecProc;

     // SQL クエリの実行:
     FDQuery1.SQL.Text := 'insert into TVPTab (Code, Name, Notes) select Code, Name, Notes from :t';
     oDS := TFDMemTable.Create(nil);
     oDS.FieldDefs.Add('Code', ftInteger);
     oDS.FieldDefs.Add('Name', ftString);
     oDS.FieldDefs.Add('Notes', ftMemo);
     with FDQuery1.Params[0] do begin
       DataTypeName := 'TVPType';
       AsDataSet := oDS;
     end;
     FDQuery1.Params[0].AsDataSet.AppendRecord([1, 'str1', 'long value 1']);
     FDQuery1.Params[0].AsDataSet.AppendRecord([2, 'str2', 'long value 2']);
     FDQuery1.Params[0].AsDataSet.AppendRecord([3, 'str3', 'long value 3']);
     FDQuery1.ExecSQL;

iOS および Android のプッシュ通知

REST BaaS(Backend as a Service)フレームワークにより、以下のために、モバイル アプリケーションで BaaS プロバイダ Kinvey または Parse を使用できます。

  • オブジェクトの作成、取得、更新、削除
  • ユーザーの登録、ログイン、取得、更新、削除
  • ファイルやストリームのアップロード、ダウンロード、削除
  • オブジェクトおよびユーザーの問い合わせ
  • プッシュ通知の送信
  • デバイスでのプッシュ通知の登録および受信

REST.Backend の API ユニットにより、Kinvey または Parse の REST API メソッドを実行できるようになります。これらのユニットでは、Kinvey および Parse の Web サイトに記載された REST API に直接対応するメソッドが宣言されています。これらのユニットを使用すると、 ParseKinvey のどちらかで REST API エンドポイントを呼び出すコードを作成できます。

メモ:
  • REST.Backend の API ユニットを使って書いたコードは、KinveyParse のどちらかに固有のものとなります。たとえば、REST.Backend.KinveyProviderREST.Backend.ParseProvider のどちらかを使用することになるでしょう。
  • 当社の BaaS フレームワークは当社の REST API フレームワークをベースにしています。Android でプッシュ通知を有効にするには、プッシュ通知を受信するための Google クラウド メッセージング(GCM)サポートが必要です。Kinvey の REST API では Google クラウド メッセージングをサポートしていますが、Parse の REST API では現在 Google クラウド メッセージングをサポートしていません。
    • Android の場合は Kinvey を使用する必要があります。
    • iOS の場合は、Parse と Kinvey のどちらでも使用できます。

REST.Backend のコンポーネントでは、一般的すなわち抽象的な形で BaaS サービスをサポートしています。これらのコンポーネントを使って書いたコードは、Kinvey または Parse に固有のコードではありません。たとえば、TBackendStorage コンポーネントを使用してオブジェクトを作成する場合は、Kinvey オブジェクトを作成しようと Parse オブジェクトを作成しようと、コードは同じです。

アプリケーションには、クラウド サービスの接続情報が記述されているプロバイダ コンポーネント(TKinveyProviderTParseProvider など)が必要です。プロバイダ コンポーネントをサービス コンポーネントに接続するには、TBackendStorage.Provider などの "Provider" プロパティを設定します。

プッシュ通知を受信するには、メッセージング サービス(APS または GCM)、デバイス、クラウド サービス(Kinvey または Parse)、Appmethod アプリケーションをセットアップする必要があります。

モバイル アプリケーションでのリモート通知のセットアップおよび使用の手順については、「モバイル チュートリアル:リモート通知を使用する(iOS および Android)」を参照してください。

Apache サーバー サポートが追加

DataSnap と WebBroker では、下記ウィザードでの Apache モジュールの作成をサポートするようになりました。

1.14 向けに行われた IDE の変更点

Google Glass のデザイン デバイスがフォーム デザイナに追加

モバイル フォーム デザイナには、下図のように、Google Glass 設計時デバイスが用意されるようになりました。

GoogleGlassDesignTimeDevice.png

詳細については、「Google Glass 向けのアプリケーションの作成」を参照してください。

IDE の新規アイコン

製品全体のアイコンが更新されました。

たとえば、IDE の[プロジェクト マネージャ]などのページでプロジェクト グループを表すアイコンは ProjGroup.bmp から ProjGroupNew.png に変わりました。

ドキュメントの一部にアイコンがまだ更新されていないものがあることに注意してください。

配置マネージャの新規オプション

  • 新規の[上書き]オプションにより、配置しないファイルを選択することで、特にターゲット デバイス上のファイルの上書きを避けることができます。[上書き]オプションはデフォルトでは[常に行う]に設定されています。このオプションを[常に行わない]に変更するには、配置マネージャのツールバー メニューにある新規の[上書き]ChangeOverwriteValueforSelectedItems.png)アイコンをクリックします。
  • 新規の[追加したファイルを保持する]オプションにより、選択したプラットフォームのデフォルト オプションに構成を戻してからプロジェクトに手動で追加したファイルをすべて保持することができます。[追加したファイルを保持する]オプションはデフォルトで有効になっており、[元に戻す]DMgrRevert.png)アイコンをクリックすることで、この値を変更できます。[アクションを指定してください]ダイアログ ボックスが開き、そこで[追加したファイルを保持する]オプションを選択またはクリアすることができます。
Keepaddedfiles.png

Android プラットフォームの[SDK マネージャ]における変更点

  • Android SDK バージョンのプロパティは 3 つの異なるタブ[SDK]、[NDK]、[Java]に整理されるようになりました。SDKNDKJava に関係するフィールドはそれぞれ対応するタブにまとめられています。そのため、たとえば、SDK バージョンを追加または変更しやすくなっています。
  • [NDK]タブの 2 つの新規フィールド(下記)では、2 つのパーソナリティの NDK ライブラリ パスを指定できます。
    • [Appmethod C++ NDK ライブラリ パス]
    • [Object Pascal NDK ライブラリ パス]
    このどちらかのパスの参照([...])ボタンをクリックすると、パスの参照、追加、管理に使用できる[ディレクトリ]ダイアログ ボックスが表示されます。

NDKLibraryPaths.png

パス名が変更

Appmethod のインストール パス(Program Files (x86) 内)とドキュメント パス(/Users/Documents 内)の名前が、次のように少し変わりました。

  • インストール パス($BDS) 環境変数):
    • 1.13: C:\Program Files (x86)\Embarcadero\Appmethod\13.0
    • 1.14: C:\Program Files (x86)\Embarcadero\Studio\14.0
  • InterBase redist パス($IBREDISTDIR) 環境変数):
    • 1.13: C:\Users\Public\Documents\InterBase\redist\InterBaseXE3
    • 1.14: C:\Users\Public\Documents\Embarcadero\InterBase\redist\InterBaseXE3
  • ドキュメント パス(Samples、Styles、Platform SDKs の各フォルダが含まれている):
    • 1.13: C:\Users\Public\Documents\Embarcadero\Appmethod\13.0\
    • 1.14: C:\Users\Public\Documents\Embarcadero\Studio\14.0\

1.14 ヘルプ全体を通して、これらの正しい新規パスが使用されます。

C++ の参照箇所の検索/定義の検索用の新しいメニュー項目および結果ペイン

C++ インデクサ機能により、C++ の参照箇所の検索/定義の検索が可能になります。C++ インデックス作成は当社の Clang ベース C++ コンパイラ(64 ビット Windows、iOS、Android ターゲット プラットフォーム用のコンパイラ)でサポートされています。

C++ インデックス作成を有効にするには、下記でアクセスできる['定義と参照箇所' のインデックス ファイル]オプションを有効にします。

  • 現在のプロジェクトの場合は、 [プロジェクト|オプション...|プロジェクト プロパティを選択します。
  • 新しく生成するプロジェクトの場合は、[ツール|オプション...|環境オプション|C++ オプション|プロジェクト プロパティを選択します。

インデックス作成後、コード エディタのコンテキスト メニュー[C++ 検索]のメニュー コマンドが使用できるようになります。

コード エディタの新しいコンテキスト メニュー コマンドは以下のとおりです。

C++ インデクサ機能の 4 つの新しい結果ペインには、以下のコマンドによってアクセスできます。

1.14 での[プロジェクト|オプション...]の変更点

UseMSBuildExternally.png

モバイル アプリケーションの新規の[向き]ページ Number1.png

これまで[アプリケーション]ページにあった[向き]オプションは別個のページに変わりました。新しい[向き]ページにアクセスするには、 [プロジェクト|オプション...|アプリケーション|向き]を選択します。

[Object Pascal コンパイラ]での新規オプション Number2.png

[Object Pascal コンパイラ]ページの新しい[外部で MSBuild を使用してコンパイル]オプションをオンにすると、MSBuild を使って IDE の外部でビルドされるようにプロジェクトが設定されます。このオプションはデフォルトでは[False]になっています。このオプションを有効にするには、[プロジェクト|オプション...|Object Pascal コンパイラ]を選択します。

この新しいオプションにより、アプリケーションとライブラリで構成される非常に大規模なプロジェクトをビルドする際に発生するおそれがあるメモリ不足の問題が解決されます。

Android の[バージョン情報]ページの新規キー

[バージョン情報]ページの新しい hardwareAccelerated キー/値ペアにより、アプリケーション全体のハードウェア アクセラレーションが有効になります。このキー/値ペアの設定により、AndroidManifest.xml ファイルの <application> タグに hardwareAccelerated 属性が追加されます。値はデフォルトでは True です。

HardwareAccelerated.png

[バージョン情報]ページにアクセスするには、[プロジェクト|オプション...|バージョン情報を選択します。

C++ リンカの新規オプション

  • すべてのモバイル プラットフォームの場合:
    • [シンボル ファイル (.map) を生成]: このオプションを指定すると、マップ ファイルが .\<出力フォルダ>\<プロジェクト名>.map に生成されます。
    • [リンク後に一時リンカ ファイル (.lnk) を削除]: このオプションを指定すると、.\<出力フォルダ>\<プロジェクト名>.lnk の一時リンカ ファイルが削除されます。
  • iOS デバイス プラットフォームの場合:
    • [正規表現ライブラリとリンクする]: このオプションを指定すると、正規表現ライブラリとリンクされます。

[C++ リンカ]ページにアクセスするには、[プロジェクト|オプション...|C++ リンカ]を選択します。

[実行]コマンドにモバイル プラットフォーム用の新規パラメータ -cleaninstall を用意

モバイル プロジェクトでの[実行]コマンド([実行][デバッガを使わずに実行]の両方)のデフォルト動作が変わりました。以前に同じパッケージ名でインストールしたアプリケーションが含まれているモバイル デバイスでアプリケーションを実行する場合:

  • これまでは、[実行]コマンドを起動すると、実行可能ファイルそのものに加えて、データ ディレクトリやキャッシュ ディレクトリもアンインストールされていました。
  • 現在では、[実行]コマンドを起動すると、実行可能ファイルのみアンインストールされ、データ ディレクトリやキャッシュ ディレクトリはモバイル プラットフォームにそのまま残されます。

ただし、従来の動作を使用する(モバイル デバイスでアプリケーションを実行したとき、既存のデータ ディレクトリやキャッシュ ディレクトリも削除する)ように指定することもできます。それには、[実行|実行時引数を選択し、次のパラメータを追加します。

-cleaninstall

詳細については、下記トピックの「データとキャッシュのフォルダを空の状態にしてアプリケーションを実行する」セクションを参照してください。

また、特定のプロジェクトのプラットフォーム構成を変更する場合も、[実行|実行時引数を選択して -cleaninstall パラメータを設定した方がよいでしょう。そうでないと、エラーが発生するおそれがあります。

iOS と OS X の資格リストの変更点

iOS の[資格リスト]ページが修正されました。[資格リスト]ページには、[プロジェクト|オプション...|資格リストでアクセスできます。

iOS の[資格リスト]ページの件とは別に、iOS と OS X の資格ファイルを手動で編集できるようになりました。iOS または Mac OS X ターゲット プラットフォーム向けのアプリケーションを初めて作成すると、<Entitlement.TemplateiOS.xml> または <Entitlement.TemplateOSX32.xml> テンプレートがプロジェクト フォルダに追加されます。すべてのプロジェクトに適用される資格キーを、出発点としてあらかじめ定義しておくこともできます。

詳細については、「資格リストのカスタマイズ」を参照してください。

1.14 での Windows API の変更点

1.14 で DirectX 11 をサポート

Winapi が拡張され、Object Pascal アプリケーションから DirectX 11 API にアクセスできるようにする以下の新しいユニットが追加されました。

  • Winapi.D3D11
  • Winapi.D3D11sdklayers
  • Winapi.D3D11Shader
  • Winapi.D3DCommon

DirectX を使用するうえでの参考としては、『DirectX Graphics and Gaming(DirectX グラフィックスとゲーム)』ガイド(英語版)を参照してください。

1.14 で OpenGL 4.3 までをサポート

新しいユニット "Winapi.OpenGLext" により、OpenGL バージョン 1.2 ~ 4.3 がサポートされます。最新の OpenGL 機能を使用するには、このユニットを uses 句に追加し、InitOpenGLext を次のように呼び出します。

InitOpenGLext;

OpenGL 1.1 に対応できるようにするユニット "Winapi.OpenGL" は更新され、OpenGL 1.1 API を完全にサポートするようになりました。

OpenGL を使用するうえでの参考としては、以下を参照してください。

ライブラリのリファクタリング

ヘルプの新機能

関連項目