こんばんは、habravchane！ 今日は、クロスプラットフォーム開発全般について書きたいと思います。 実際、本質的に、人々はデスクトップ、サーバー、モバイルクライアントを共有し、各セクターの境界を越えずに、各セクター内でクロスプラットフォームツールを探します。 これはさまざまな理由で発生します。 理由の1つ-VasyaはJavaでデスクトップを作成する方法を知っており、Petya-Objective-CでiPhone用のアプリケーションを作成する方法を知っています。 また、すべてのプラットフォームを統合するテクノロジーがあるとは誰も推測できません。



猫の背後には多くのテキストと統計があります。

Apps4Allフォーラムでの私の講演。 最初のパフォーマンス、材料の供給におけるすべてのエラーは、すでに口ひげに巻き付いています。

解決した問題

問題の最初のグループは製品の問題です。

なぜ人々は一般にクロスプラットフォーム開発に行くのですか？ 彼女は何のためですか？ プラットフォームごとに個別に記述した場合に発生する問題のリストを収集してみましょう。

• 各プラットフォームのコードには単一のフローがありますか？ この問題は、さまざまなプラットフォームで作成しているチームに調整や関係がない場合に発生します。 人々は別のコードを見ずに、それぞれを書いているという事実から-自分自身。
• APIのどこかに行ったことはありますか？ 同じ理由で発生しますが、もう1つ追加されます。変更に関する情報は、2番目ではなく1番目に到達しています。 さらに、APIのこのセクションがめったに使用されない場合、矛盾はまったく気付かない可能性があります。
• DBスキームに従って同期されましたか？ ドキュメントの共通リポジトリがない場合、この問題の原因は広がります（ただし、前の例のように）。 たとえば、ローカルストレージを使用する各プログラムは、人々が流されて変更について他の人に通知することを忘れているという理由だけで、コミットから他のプラットフォームから分岐し始める可能性があります。
• 各プラットフォームの単体テスト。 APIが変更されました??? これは大きな問題です。 ビジネスロジックがテスト（適切なプロジェクト内にある必要があります）でカバーされている場合、コードに加えてAPIまたはデータベーススキーマを変更する場合、関連するすべてのユニットテストをN回書き換える必要があります（Nはプラットフォームの数です）。

管理にも問題はありません：

• Java / Objective-C / ...開発者からのVenegretを調整する必要があります 。 マネージャーが各プラットフォームを完全に理解していると便利です。 そして、彼が前に1つだけを扱ったことがあり、開発者が経験がない場合はどうなりますか？ そうすれば、彼らは耳で麺を放送できるようになります。たとえば、いくつかのことはできないと言います（実際には、解決策を探すのは面倒です）。 そして、顧客が開発者自身である場合、そのたびにあなたは彼らのふざけた態度を赤面しなければなりません。
• 開発者がクラッシュしましたか？ 同じプラットフォームで見つける必要があります 。 たとえば、次のリリース用でなければ、これは問題になりません。 クロスプラットフォームツールセットを使用する場合、開発者を他のプロジェクトから移動できます。 少なくとも、プログラミング言語は使い慣れています。 これは大きな助けです。
• 顧客は同じコードに対して何度も支払います。 同意します。3つのプラットフォームで同じことを推進するには、エスキモーに雪を販売するための巨大なスキルが必要です。 「APIとどの程度統合できますか？ あなたはすでにこれを二度やった！」 そして、あなたは静かにそれらを理解しますが、あなたのものを主張し続けます。
• 外部APIは変更されましたか？ ここでは、経営陣は3つのプラットフォームに料金を支払ったばかりだったため、いらいらしました。今日から、変更に関連するすべてを書き直す必要があります。
• 各プラットフォームについて非常に正確に推定する必要があるため、 修正価格は苦痛を増します。 また、マネージャーが一部のプラットフォームで料理をしていない場合、問題が発生します。評価できないプログラマーの評価に頼らなければなりません。 「Vasya、あなたは間違いなくPiを掛けましたか？」
• 顧客は同じことを求めましたが、別のプラットフォームのみを求めました 。 そして、再び、上記の問題の全体の束。

リストされている問題は何を解決しますか？ すべての人々が単一のプラットフォームと最も均一なコードを使用する場合、それらは解決されます。 その後、すべての変更が一度だけ行われ、エラーが一度だけ修正されます。 そして、上記のポイントを通過すると、そのようなアプローチがそれらのほとんどすべてを減らすことを理解するでしょう。

問題の2番目のグループは開発ツールです。

あなたが何と言っても、開発はツールによって決定されます。 実際、便利で、リファクタリング、ルーチンテキストの入力の単純化、入力の自動補完、未知のAPIでの作業の支援が可能であれば、コードはより良く、より迅速に記述され、より安価になります。 これを理解することは、ライセンスの購入に貪欲ではなく、市場にある最高の開発ツールを使用するというアイデアにつながります。 多くの場合、プログラマーが開発ツール市場の新しいプレーヤーを選択できない有能なIDEがありません。 IDEは怖いですか？ キャラクター定義への移行は機能しませんか？ IDEが普及することはありません。 同意：クロスプラットフォーム開発への移行は、おそらくAPIを知らないことを意味します。 そして多くの場合、絶対に独自のAPIがあり、それを教える必要があります。 同時にIDEがコードのドキュメントのサポートを提供せず、メソッドやクラスにカーソルを合わせたときにツールチップにドキュメントを表示すると、インターネットアクセスは時間の浪費であり、意識の流れから抜け出すため、非常に困難になり、憎しみを感じるようになります。

問題の3番目のグループ-GUIプラットフォームの違い

このグループは、未解決の問題のグループです。 むしろ、すべてのプラットフォームで単一のGUIを作成することで解決できますが、このソリューションを好むユーザーはいません。使い勝手が悪く、慣れていません。 彼らはDelphiでこの問題を解決しようとしたと聞きましたが、この製品は非常に新しく、私は触れませんでした。何も言えません。 では、どのような違いが問題解決を難しくしているのでしょうか？

• 小さな（物理的に）画面上の指に触れることに対するキーボードとマウスの操作。
• めったに含まれないインターネットに対する安定した永続的なインターネットは、時には消えます。
• エキスパンドアイアンvsスローアンドリミテッド
• デスクトップでは、アプリケーションが長時間開きます。 モバイル-短期間。
• UIはどこでも異なります。 たとえそれが似ていても（デスクトップ）、至る所にさまざまなホットキー、さまざまなインデント、レイアウトルールがあります。

ただし、両方のアプローチの長所と短所を強調してみましょう。

• ネイティブUI
  
  
  • プラス：プラットフォームユーザーになじみがある
  • プラス：高速
  • プラス：豊富な機能を提供します（1つのプラットフォームに存在し、他のプラットフォームには存在しない機会があります）
  • プラス：使い慣れたUX
  • マイナス：どこでも違う。
  
  
  
• クロスプラットフォームUI
  
  
  • プラス：一度だけ
  • マイナス：どこでも同じに見える
  • マイナス：同様にすべてのユーザーに馴染みがない
  • マイナス：多くの場合、これは遅いソリューションです（常にハードウェアではなく、統合の必要性のため）
  • マイナス：プラットフォーム機能は使用されません
  • マイナス：なじみのないUX
  
  
  

ここからどのような結論を引き出すことができますか？ 私たち自身ではなくユーザーのために製品をリリースするには、プラットフォームごとに個別にUIを作成できるツールボックスが必要です。

開発ツールを選択しようとしています

したがって、クリーターが選択されます。

• 豊富で必要な機能がたくさんある優れたIDEがあります
• コードは単一のSDKを使用して1つの言語で記述されます
• UIはプラットフォームごとに個別に記述されています
• 単一コードの最大数。 つまり 私たちの場合、それはすべてUIではありません

クロスプラットフォームツールのカテゴリ

• アプリケーション工場。 アプリケーションジェネレーター。 私たちの目標は、切り捨てられたプラットフォームではなく、機能が豊富なプラットフォームを見つけることであるため、それらを考慮しません
• Webアプリツールキット。 さりげなくブラウジングします
• クロスプラットフォームIDE。

自分で理解するためには、膨大な数のクロスプラットフォーム開発ツールを個人的に使用する必要がありますが、そのうち約90個が用意されています（research2guidanceによる）。 そして、単に使用するだけでなく、それぞれにかなり複雑なアプリケーションを作成し、アプリケーションストアに送信します。 これはかなり面倒で費用のかかるプロセスなので、このトピックに関する研究を探すことにしました。 調査により、research2guidanceとVisionMobileという2つの組織のサイトに移動しました。



おそらく、すべての統計ではなく、Xamarinの会社について語っている統計だけを考えてみましょう。完全な統計は40ページかかり、読み取りと理解の両方のために広範囲に及ぶからです。 誰もが完全な統計情報を読むことができますが、個人的には、私の調査結果は以下のように簡単です。

認識

開発者と顧客の両方にとって十分に重要な要素は、使用されるものの認識です。 開発者にとっては、仕事を探すときに雇用主と話し合いやすくなり、多くの場合、履歴書を確認するため、認識は重要です。 顧客にとって、ツールボックスの認識は重要です。なぜなら、請負業者を選ぶとき、細心の注意を払った顧客は会社のサービスでなじみのある手紙を探すからです。 同時に、彼が現在使用されているものをインターネット上で検索するのが面倒ではなかった場合、左側の列のセットから何かを使用済みツールとして指定すると、コラボレーションを開始する機会が増えます。 ご覧のとおり、最も目立つのはAdobe Air、Phone Gap、Xamarin、jQuery Mobile、Unity、Titaniumです。 これらのプラットフォームの中で、アドビは際立っています。 おそらくこれは、主にAdobe自体の名声によるものです。 ただし、すべてのプラットフォームは、彼女、Xamarin、Unity 3Dによってのみカバーされます。 さらに、Unityはゲームプラットフォームであり、通常のアプリケーション向けに強化されていません。 そしてゲームのために-彼女はナンバーワンです。 ただし、ビジネスアプリケーションの場合、選択は次のようになります。Webフレームワークを選択する場合、より詳細に調べる必要があります。 クロスプラットフォームIDEの場合、このカテゴリでKsamarinが勝ちます。



©research2guidance

開発ですでに使用されています

2番目の重要な統計：開発で既にツールセットを使用している人の数。



©research2guidance



ただし、この図は初心者には非常に恩恵がないことを思い出させてください。 たとえば、Delphi XE3は、この調査が実施される数か月前にリリースされました。 彼女がここに来たのは奇跡です ただし、お気に入りに戻り、各プラットフォームの最初のリリースの日付を追加します。

1. PhoneGap-2005（〜31％）
2. Adobe Air-2008（〜17％）
3. Unity 3D-2008（iPhone / iPad）-（〜13％）
4. チタン-2008（〜13％）
5. jQuery Mobile-2010（〜28％）
6. 煎茶-2010（〜12％）
7. マーマレード-2011（〜12％）
8. Xamarin-2011（〜12％）
9. Qt Creator-2012（モバイルではない）（〜14％）

私は個人的にQT Creatorに質問がありました。モバイルプラットフォームでは機能せず、レポートにエラーが入り込んだ可能性があります。 ただし、成長指数と現在の人気を見ると、次のお気に入りが強調されます。

1. jQuery（3年でほぼ8年でPhoneGapと同じくらい）
2. マーマレードとザマリン（2年間で大きく成長）

しかし、私たちの秘密を思い出して、jQueryもMarmeladeも私たちに合わないことを理解しています。 1つ目も2つ目もプラットフォーム機能へのアクセスを提供しません。これは私たちにとって重要です。 このカテゴリにはXamarinがあります。

開発実績

©research2guidance



このチャートは、特定の開発ツールでの開発が、市場に至るまでの開発およびテストプロセスをどれだけ高速化するかを示しています。 この図から、開発中の最速のツールセットはUnity 3DとXamarinであり、最も損失の多いツールセットはMarmeladeとTitaniumであると結論付けることができます。 さらに、両方のお気に入りが同じテクノロジーに基づいていることに注意してください。



さて、最後の図：クロスプラットフォームツールを使用するためにまだ動揺していない場合



©by research2guidance



縦軸は調査対象者の割合を示し、横軸は質問への回答を示します。クロスプラットフォーム開発はどれくらい速く/遅くなりましたか？ したがって、大多数は、彼らは加速し、小さい方は減速したと答えた。

Xamarinプラットフォームについて

それでは始めましょう。 少し歴史を掘り下げると、私が話しているKsamarinプラットフォームは決して新しいものではないことがわかります。 これは非常に古く、Microsoftの.Net Frameworkのクロスプラットフォーム実装に根ざしています。 この実装はモノランタイムと呼ばれ、グラフィック出力ライブラリを除き、.Netの世界のほぼすべてが含まれています（ただし、完全に作成されているわけではありません）。 ただし、このマイナスは、巨大なプラスによって簡単に相殺されます。デスクトップでは、どこでも機能します。 Windows、Linux、およびMac OSでは、完全にデバッグされます。

プラットフォームはソースコードとともに配布されており、無料なので、開発者はそこからお金を得ることができず、モバイルアプリケーションを使用して監視を開始することに決めました。 結局のところ、比較すると、デスクトップの場合、クロスプラットフォームアプリケーションの開発の注文を探す理由はそれほど多くないことがわかります。 しかし、モバイルデバイスの場合、プラットフォームの一部またはすべてのプラットフォーム用のアプリケーションを作成する注文がはるかに多くあります。 さらに、UIに関連するすべてを.Net Frameworkから削除すると、優れたアーキテクチャ、デバッグされたコード、および既存のIDE間の優れたサポートを備えた豊富なインフラストラクチャが得られます。

主な問題は、プラットフォームごとにプラットフォームAPIを転送することです。

Javaには独自の仮想マシンがあります。Javowskaはいくつかのパラメーターに満足しておらず、その中には正直なジェネリック（後で説明します）ではなく、iOSはC＃からObj-Cに受け取った既製のアセンブリーの変換を使用しているためです 出力には何がありますか？

• クロスプラットフォームアプリケーションを作成できる膨大な数のプログラミング言語。 その中には、C＃、VB.NET、Boo、Nemerle、JavaScriptがあります。

  
  
  
  
  
  
  

• リッチインフラストラクチャの.Net Framework、および.Net用にすでに作成され、github、codeplexなどのリポジトリで待機している信じられないほどの数のライブラリ

  
  
  
  
  
  
  

• AndroidおよびiOSで既存のライブラリを使用する機能。

  
  
  
  
  
  
  

• 現時点で最も人気のあるプログラミング言語の最も広いコミュニティ-C＃はあなたの質問を未解決のままにしないでしょう。

  
  
  
  
  
  
  

• 安定した開発チームで、製品を愛し、急速に成長しているコミュニティ（現在、約500,000の登録があり、この数は止まらないと考えています）

  
  
  
  
  
  
  

• プログラマのスタッフと他のプラットフォームからプログラマを雇う能力を削減します。 たとえば、C＃に詳しいWindowsプログラマー。

  
  
  
  
  
  
  

• 最終製品の開発コストを削減し、それに応じて、より関心のある顧客を減らします。

  
  
  
  
  
  
  

私の前には、開発会社やフリーランサーのための耕作されていない分野があります。 結局のところ、私自身はWindowsでの開発から来ており、このプラットフォームはクイックスタートのための優れたツールキットであると考えています。 半年以上前にTouch Instinctに到着したので、今日はどのプラットフォームでも書くことができます。

C＃を学ぶ価値があるのはなぜですか？

統計では、2012年のプログラミング言語の人気指数として、C＃が今年の言語と呼ばれています。 彼らは、C＃の人気が2.3％増加したと推定しました。これは、インデックス内のすべての言語の最大数でした。 もちろん、MicrosoftはWindows 8も起動しました。Windows8では、C＃が主要なプログラミング言語です。 しかし、実際には、すべてが多少異なります。 Xamarinの共同創設者であるNet Friedmanは、C＃がモバイルプラットフォームに最適なプログラミング言語である8つの理由を投稿で強調しました。

1. 並列コード実行の第一級言語サポートにより、以前は退屈で厄介だったすべてが実装しやすくなり、膨大な数の潜在的なエラーが生じ、保守が容易なコードになりました。 そして、これに自動型推論、ラムダ式、LINQ言語、その他の言語の利点を追加すると、プログラミングは非常に快適なプロセスに変わります。

   
   
   
   
   
   
   

2. 豊富な機能 -オブジェクト指向プログラミングとカプセル化により、最大限に再利用できるようにコードを非常に簡単に構築できます。 また、リフレクションや依存関係のインジェクションなどの機能は、アプリケーションの拡張性と柔軟性のための本当に豊富な機会を提供します。

   
   
   
   
   
   
   

3. 高度なランタイム 。 ガベージコレクションは、開発者の負担からアプリケーションメモリを管理する負担を取り除くことにより、開発を大幅に簡素化します。 開発者は、ポインターに苦労してメモリリークを制御する代わりに、アルゴリズムやその他の問題の解決に集中できます。

   
   
   
   
   
   
   

4. 強く型付けされた言語のように、C＃はほとんどのコンパイル型チェックを行います。これにより、迷惑なエラーの数が減り、開発が高速化されます。

   
   
   
   
   
   
   

5. 簡単に適応できます。 C＃は非常に単純な言語であり、それに慣れるのは非常に簡単です。 しかし、あなたが慣れているなら、そこから抜け出すことは非常に難しいでしょう、信じてください。 そして、これに非常に多くのマテリアルを追加すると、初心者デベロッパーが1か所で動けなくなることはありません。

   
   
   
   
   
   
   

6. 高速実行 。 iOSのC＃は、最適化LLVMコンパイラを使用します。これは、オペレーティングシステムのベースとなるCおよびC ++言語で使用され、C＃プログラミングの高い生産性と低レベルプログラミング言語の高効率を実現します。 Androidでは、事態はそれほど悪くはありません。C＃はJavaよりも優れています。 これはいくつかの方法で説明できます。C＃は、デフォルトでは仮想タイプではなく、Javaとは異なり、値タイプ、実際のメソッドをサポートします。 また、もちろん、これは、Dalvikが試行済みのMonoランタイムよりも若いという事実によって説明できます。

   
   
   
   
   
   
   

7. プラットフォーム関数へのアクセスにより、オペレーティングシステムの機能だけでなく、元々特定のプラットフォーム用に作成されたサードパーティライブラリも使用できるようになり、長年にわたって開発されてきたサポートされているライブラリの備蓄を補います。

   
   
   
   
   
   
   

8. そして主な理由： アプリケーションをさまざまなプラットフォームにエクスポートする機能 。 サポートされているすべてのプラットフォームを含むモノラルプラットフォームで作成すると、アプリケーションで世界中の22億台のデバイスに到達できます。 この数字について考えてみてください。 この数値だけでも、誰でも少なくともこのプラットフォームを開発中に試すことができます。

   
   
   
   
   
   
   

そして、顧客があなたのオフィスに来たとき、彼はAndroid用のアプリケーションではなく、例えば...またはiPhone用に注文したいと考えています。 顧客はまずモバイルアプリケーションを望んでいます。 彼のアプリケーションを最大数のデバイスに依存させるため。 このプラットフォームを使用している場合、これにより開発コストの削減について話すことができます。 結局、開発自体を減らすだけではありません。 しかし、エラーも修正します。 ビジネスロジックコードは、Android、iOS、およびWindows Phoneで修正されます。 はい、各プラットフォームでUIに関連するすべてを新たに開発する必要があります。 ただし、残りのすべてのコードは変更されずに共有されます。 データベース、ゲームロジック、はい何でも動作します。

短所

このようなさまざまなプラスの中で、マイナスの一部について話さないのは不公平です。 ここで、私は、あなたが眠りに落ち始めた人たちが色にひっかかっていると思います。 まあ、最後に、彼らは言う、来る。 もちろん、この規模の開発と同様に、欠点もあります。

• Xamarin Studioは優れたIDEですが、デバッガーに問題がある場合があります。 問題があり、誰もがそれらについて知っています。そして、これは近い将来一番の優先事項であることを望みます。

  
  
  
  
  
  
  

• プラットフォームライブラリへのバインディングを構成する必要があります。 コンパイル済みのネイティブライブラリを使用する場合は、バインディングを構築して少し苦労する必要があります。 生活を楽にするツールセットがありますが、常に希望どおりに機能するとは限りません：ペンで仕上げなければならない場合があります

  
  
  
  
  
  
  

• 明確な記憶で充電する必要があります。 実際のところ、たとえばJavaではJava / Obj-Cではなく、Javaで作業しているため、2つのガベージコレクターが機能しています。 心配しないでください！ 会場を離れないでください！ すべて順調です。 しかし、両方のオブジェクトを解放するには、追加のアクションを実行する必要があります-リンクを解放します。 C ++のようなもの。 しかし、何をすべきか。 何もする必要はありません。

  
  
  
  
  
  
  

ただし、これらの不利な点は、真のクロスプラットフォームコードの開発の容易さと喜びによって補われています。一般的なアプリケーションロジックを個別のライブラリに分離し、たとえばMVVMを使用すると、プラットフォーム依存のUIアプリケーションのみを作成できます。 これにより、最終プラットフォームのコードの開発時間を80％に短縮できます。 これは大きな割合です。

ユズキージー

• 皆さんご存知のように、iOS用にプログラムするにはMacが必要です。 これは、Windowsプラットフォームを使用している場合に気分を害する可能性がある財政上の制限です。 ただし、悲しいことはありません。 Visual Studioのライセンスを既にお持ちの場合、JetBrains、ReSharper、およびその他のWindowsプラットフォームの製品である私たち全員のお気に入りがあります。開発中にMac Miniまたは他のMacを1つだけ使用してビルドサーバーとして使用できます。 Visual Studio

  
  
  
  
  
  
  
• Visual Studioのような安価なツールにお金がない場合、Xamarinにも解決策があります。 Xamarin Studio IDEは、MonoDevelop 4.0バージョンであり、開発に必要な膨大な数のリファクタリングやその他の便利な機能が含まれています。
  
  
• Xamarin Studioを使用してMacで開発することもできます。 当社全体がまさにそれを行っています。 WinPhoneアプリケーションにのみWindowsを使用します。