Embarcadero FireMonkeyでのモバイルアプリケーション開発（FMX 6）

同じコードを何度も書くことを好む人はいませんが、モバイルアプリケーションを一度に複数のプラットフォームに実装する必要がある場合は、これを行う必要があります。 残念なことに、会社のプログラマーは、それぞれの場合、さまざまなツール、スキル、アプローチを使用する必要があります。 もちろん、アプリケーションを転送するときには、少なくともプログラミング言語を変更する必要はないという要望があります。



そのため、今回はモバイルアプリケーションの開発の難しさを考えて、古代ロシアの夢に挑戦する誘惑に抵抗することはできませんでした。 少しきしみながら、「ストーブ」が先に行ったとしましょう。



そのため、ご存知のように、モバイルアプリケーションのクロスプラットフォーム開発で使用されるいくつかのアプローチがあります。 これらのソリューションにはそれぞれ欠点があり、場合によっては、以下の出版物のいずれかで提示するさまざまなアプローチの比較分析があります。 ここでは、そのような楽器の1つにのみ焦点を当てます。この楽器は、多くのユニークな機能を備えていますが、聴衆には多少無視されています。



FireMonkeyは、悪名高いEmbarcadero社の製品です。 FireMonkeyはRAD Studio開発環境の一部です。 基盤となるFMXエンジンは、当社の同胞がかつて開発したものであり、ユーザーインターフェイスを構築するためのクロスプラットフォームフレームワークであるFlashまたはWPFに似ています。 同時に、前述の製品と同様に、FMXはベクターグラフィックスとハードウェアアクセラレーションを使用します。 製品はほんの数年前に登場しましたが、この間に5つのアップデートがリリースされました。 私はこの製品が悪名高いDelphi .NETの運命に苦しむことはないと信じたい。



アプリケーションはマシンコードに直接コンパイルされ、これはこのソリューションの主な特徴の1つです。 こうした驚くべき状況に関連して、エンバカデロは理論的にはネイティブアプリケーションレベルでの全体的なパフォーマンスを約束します。 FireMonkeyでは、DelphiおよびC ++ Builderで構築されているため、PascalおよびC ++でアプリケーションロジックを実装できます。 同じFireMonkey（FM）アプリケーションコードをコンパイルして、Windows、iOS、Androidで動作させることができます。 この領域には多数のプログラマーがいたため、C ++で開発を行う機会に惹かれました。 したがって、操作性をテストするためにインストールされたのは、RAD Studio XE6のC ++ Builderバージョンでしたが、Delphiエディションは、使用されているプログラミング言語以外の違いはないはずです。

アプリケーションの組み立て

コンパイラの作成の背後にある乱流の中で、製造業者はFireMonkeyにx86およびARMv7用のネイティブC ++コンパイラを装備しました。 これにより、開発環境が実行されているコンピューターで直接コンパイルできます。 C ++またはPascalでプログラミングし、出力で必要なARMマシンコードを取得する機会を提供するのは、独自のコンパイラの存在です。 ただし、アプリケーションの構築（リンク）、署名、デバイスでの実行、およびデバッグには、モバイルプラットフォームの開発ツール（SDK）の元のツールが引き続き使用されます。 したがって、開始する前に、次の手順を実行する必要があります。

iOS	Android
Macを持っている	---
iOS開発者プログラムにサインアップする	Android Developerにサインアップする
証明書を取得する（開発者、プロビジョニング）	アプリケーション署名キーを生成する
iOS SDKをダウンロードしてインストールする	Android SDKとNDKをダウンロードしてインストールする
MacにPAServerをダウンロードしてインストールする	---
RAD StudioとPAServer間の接続を構成する	---

RAD StudioとAndroidツールキットの両方がPC上で動作するため、Androidの開発に必要な身体の動きはiOSの場合よりもわずかに少なくなります。 iOSアプリケーションをビルドするには、Mac OSが必要です（AppleのみがSDKをリリースするため）。 したがって、アプリケーション開発がPC上で行われる場合、何らかの方法で通信する必要があります。 下の図から、付属のEmbarcadero PAServer（プラットフォームアシスタントサーバー）を使用して、iOSアプリケーションがPCを介してどのようにアセンブルされるかを確認できます。

例

FireMonkeyテストの一環として、単純なアプリケーション（Hello worldレベル）を開発しました。この例では、提案された技術の操作性を確認したいと考えていました。



以下は、Windows用のこのアプリケーションのバージョンのスクリーンショットと、簡単な操作でダイナミクスを確認できる短いビデオです。









このアプリケーションには、ほとんどコードが含まれていません。 それにもかかわらず、私たちは私たちがやったことを正確に教えます。



このケースでは、パフォーマンスだけでなく、さまざまなプラットフォームでのユーザーインターフェイスの変化に関心がありましたが、それは「日常」という意味です。 つまり、ユーザーは1秒あたりの浮動小数点演算の数を気にしませんが、アプリケーションがそのアクションにどれだけソフトかつ迅速に応答するかを気にします。



このアプリケーションはいくつかの標準コントロールで構成されており、ユーザーアクションハンドラーのペアが含まれています。 画面の上部には「ねじれ」があり、これを動かすと、写真を左に回転できます。 テストのこの部分は、FMXが2次元グラフィックスを描画する能力をテストするため、またはラスター操作を実行するために必要でした。



少し下にある進行状況バーには、ホイールが設定されている角度の現在の値が表示されます。 UIスレッドの相互作用を確認し、さまざまなプラットフォームでこの要素のスタイルを確認する必要があります。



ホイールターンハンドラー：

//--------------------------------------------------------------------------- void __fastcall TForm1::DialAngleChange(TObject *Sender) { // Every time the angle dialer is spinned, assign // its current value to the Image control... imgLogo->RotationAngle = 360 - DialAngle->Value; // The progress bar will get updated with a normalized angle value pbAngle->Value = (int)fabs(DialAngle->Value)%360; } //---------------------------------------------------------------------------
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、これは通常のC ++ですが、Delphiのレガシーには少し「汚」です。



以下は、次のHWハンドラーを備えた従来のボタンです（ただし、ボタンにそれほど似ていません）。

 //--------------------------------------------------------------------------- void __fastcall TForm1::btnHelloClick(TObject *Sender) { // A simple HW assignment btnHello->Text = "Hello world!"; } //---------------------------------------------------------------------------
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

右側には、日付を選択するためのフィールド（DateTimePicker）があります。 私たちは主に、モバイルOSでの彼の外観に関心がありました。それぞれの場合にネイティブコントロールまたは描画されたものが使用されるかどうかです。 同じ理由で、スライダーとON / OFFスイッチは以下に従います。 ただし、このスイッチには別の機能が追加されています。標準のFMX視覚効果（ラジアルブラー）の1つが含まれています。FMXが独自にコントロールを描画するか、この作業をモバイルOSに委任するかどうかを確認します。 結果は明らかではなかったため、以下でこの問題に戻ります。



一番下には、2つの列がある表があります。 この表には、慣性スクロールがありますが、デスクトップアプリケーションの特徴があります。 私たちは、携帯電話でそれをどのように使用するかを確認したかったのです。 目がしがみつくように、テーブルはアプリケーションの開始時に埋められます。

 //--------------------------------------------------------------------------- __fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { // Initialize the string grid with a bit of texts // Define the number of items gdDemo->RowCount = 1000; // Generate the texts for every Row and Column for(int r = 0; r < gdDemo->RowCount; r++) { gdDemo->Cells[0][r] = "iResearchFX"; gdDemo->Cells[1][r] = IntToStr(r+1); } } //---------------------------------------------------------------------------
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

編集

コンパイルは非常に遅くなります-通常通り、C ++ Builderはなんとなく緊張します。 しかし、長年にわたって、C ++コンパイラはそれを速くしませんでした。



モバイルデバイス用のバージョンで同じアプリケーションを見る時が来ました。 アプリケーションのコードやユーザーインターフェイスを変更する必要はありません。 プロジェクトのいくつかの設定を変更するだけで十分です。これらの設定は、「簡単な動き」によってターゲットプラットフォームを変更できるように作成されたものです。



プラットフォームの切り替えは簡単です-IDEでは、インターフェイスのこの側面は意図的に妥協なく行われます。 デバッグまたはリリースコンパイル、ターゲットプラットフォーム、シミュレーター、またはデバイスを選択し、アセンブリが内部のニーズまたは発行のために実行されるかどうかを個別にマークする必要があります。 後者の場合、証明書に署名する必要があります。 Android証明書、まだ持っていない場合は、開発環境から直接生成するようにすぐに招待されます。 そして、iOSプロファイルは、最終ビルドフェーズが実行されるMac上にある必要があります。



Androidセクションには、Android SDKで設定されたすべてのシミュレーターと、接続されているすべてのデバイスがリストされていることが簡単にわかります。



iOSセクションでは、オプションはXcodeのセットを正確に繰り返します-シミュレーターのアセンブリと起動がリモートMac OSマシンで実行されることを考えると、これは驚くことではありません。






左は、アプリケーションが主要なモバイルプラットフォームでどのように見えるかを示しています。



気付くのは簡単です-そして、これは心強いことです-外観はあまり変わりませんでしたが、逆に、アプリケーションは理解できないほど変わりましたが、今では各プラットフォームのインターフェイスをゼロから作成した場合とまったく同じに見えます。 これは、FMXをテストしたい誘惑です。 Qtを初めて使用する喜びのようですね！



これはまだ同じアプリケーションですが、すべてのコントロールがプラットフォームごとに「ネイティブ」に変更されていることがわかります。 これは、私たちの意見では、GUIアプリケーションの真のクロスプラットフォーム開発と言えるでしょう。


モバイルアプリケーションの準備ができました！ 物理的なAndroidデバイス（HTC One）で作成されたスクリーンビデオの例で、彼の作品をライブで見ることをお勧めします。 ビデオはほとんど同じです。統計用に2つのビデオを作成しました。



ビデオは、アプリケーションのいくつかの側面を示しています。

1. 開始時間。 「コールド」スタートについて話している場合、Android-e上のすべてのアプリケーションは非常に速く起動しないと考えられています。 ここで、開始時に約2秒が失われていることがはっきりとわかります（ビデオの冒頭の黒い画面）。 これが多いかどうかはあなた次第ですが、私たちの意見では、それはアプリケーションのタイプに大きく依存します。
2. 仕事のスピード。 特別な苦情はありません-インターフェイスは非常にうまく機能します。
3. コントロール すべての要素はネイティブのものに置き換えられ、非常にAndroydの印象を与えます。
4. グリッド モバイルプラットフォームにとっては面白く、非常に機能しています。インプレースセル編集もあります。

死後

新しく作成したAndroidアプリケーションの内部を見てみましょう。



APKアーカイブは、6 MBという非常に具体的なサイズです。 どうやら、古いDelphiの伝統によれば、ランタイムライブラリ全体がそこに引き込まれたようです。



APKアーカイブ内には、次のフォルダー構造があります（右側に表示）。 ネイティブコンパイラARMv7およびNDKが正確に使用されたことを示唆するかのように、動的ライブラリ（so）の存在が目を引きます。



libフォルダーにはアーキテクチャの名前を持つサブフォルダーが含まれており、それぞれに何らかの理由でlibProject1.soと呼ばれるアプリケーションがあることに注意してみましょう。 したがって、armeabi-v7aフォルダーにあるのは本物であり、サイズは約21 MB（アンパック）です。 残りのライブラリファイルは既製のクラッパースタブであり、ユーザーのアーキテクチャがARMv7と異なる場合にユーザーの顔にメッセージを表示します。 製造業者はこれを正直に認めており、これまでのところ他に何も残していません。



classes.dexファイルにはアプリケーションがまったく含まれていませんが、メインFMXアプリケーションライブラリのJavaローダーと、ネイティブAndroidコントロールのラッパーの実装が含まれています。 このフラグメントにより、アプリケーションがOSと対話し、通常のAndroidアプリケーションになりすますことができます。

ネイティブ度

ビデオで目立つようになると、FMXエフェクトは「ネイティブ」Androidコントロールに大きな影響を与え続け、レンダリングを妨害します（たとえば、コントロールの輪郭のグローをオンにしたこともあります。つまり、FMXはAndroidコントロールとは異なり、写真付きですが、非常にタイトです）。



Sebastian Ginger（SEBASTIAN PR GINGTER）は、よく知られているFMXの記事で、ユーザーインターフェイスが独立した方法で描かれ、どのプラットフォームでもネイティブに見えないという事実を厳密に批判して、フレームワークについて非常に不平を述べています。 どうやら、ある時点でこれはまさにそうでしたが、今ではそのような批判は公正とは見なされません。 著者は、このアプローチの潜在的な利点を否定しながら、特定の実装に関係なく、クロスプラットフォームのGUIアプリケーションという概念を否定しています。

おわりに

もちろん、考慮されるツールは、VCLのすべての伝統（栄光と不誠実）の継続です。 真のクロスプラットフォームモバイルアプリケーションのアセンブリテクノロジーが機能し、非常に優れたパフォーマンスを発揮することを確認しました。 特定のクラスのアプリケーションでは、FMXが非常に役立ちます。



マイナス面には、起動時の顕著な遅延と、結果として生じるアプリケーションのサイズが小さいことが含まれます。

使用材料：

1. Embarcaderoドキュメント
2. FMでの開発プロセスの説明
3. XE6のARMスタブ
4. 非ネイティブインターフェイスの批判