プラットフォームWP7、WP8、Win8間のコード共有。 基本

多くの場合、既存のアプリケーションを他のプラットフォームに移植するか、最初に一度に複数のプラットフォーム用に作成する必要があります。 この記事では、特に3つのプラットフォームでのコード共有の基本を検討しますが、説明した原則は、Xamarinを使用するなど、他のプラットフォームでのクロスプラットフォームアプリケーションの開発にも適用できます。

素材はかなりボリュームがあったので、記事を2つの部分に分割することにしました。 今日は初心者向けの共有の基本について説明します。既に基本的なスキルがある場合は、この記事を安全にスキップして次の記事を待つことができます。実際には、より複雑なコード共有シナリオを検討します。

次に、コードを共有する2つの主な方法について説明します。ファイルとライブラリを共通のコードにリンクする方法です。 両方のアプローチ、それぞれの主な長所と短所を一貫して検討します。

0.コピー

もちろん、コードを「共有」する別の一般的な方法-コピーについていくつかの言葉を言わずにリンクから始めることはできません。 特定のプラットフォームのコードをコピーして変更するのが最も簡単な「共有」方法であり、ほとんどの場合、このアプローチを部分的に使用します。 ただし、プラスよりマイナスの方が多いため、共有の主な原則とは見なしません。 このアプローチの利点：別のプラットフォーム用の作業コードを迅速に取得すると同時に、変更がメインプラットフォームに影響を与えることはありません。 短所：各プラットフォームの各コピーで既に同じタイプの変更を行う必要があるため、メンテナンスは高価です。

1.リンク

クロスプラットフォームアプリケーションを記述する最も簡単で、おそらく最も一般的な方法は、ファイルをリンクすることです。 多くの場合、既にWP7用の既製のアプリケーションがあり、WP8用の同じアプリケーション（またはその逆）を取得したい場合、既存のコードを単純に再利用し、既存のアプリケーションアーキテクチャに変更を加えないように誘惑されます（アーキテクチャがこのために調整されていない場合） ）

このアプローチを段階的に見てみましょう。

たとえば、非常にシンプルなWP8アプリケーションを作成し、メインページ（MainPage.Xaml）に古典的な「計算機」を追加しましょう。数字を入力する2つのテキストフィールド、追加ボタン、結果を表示するフィールドです。

<StackPanel> <TextBlock Text="A" Style="{StaticResource PhoneTextLargeStyle}"></TextBlock> <TextBox x:Name="TextBoxA" Text=""></TextBox> <TextBlock Text="B" Style="{StaticResource PhoneTextLargeStyle}"></TextBlock> <TextBox x:Name="TextBoxB" Text=""></TextBox> <Button Content="Summ" Click="ButtonBase_OnClick"></Button> <TextBlock x:Name="TextBlockResult" Text="" Style="{StaticResource PhoneTextLargeStyle}"></TextBlock> </StackPanel> 

C＃コード

 private void ButtonBase_OnClick(object sender, RoutedEventArgs e) { var valueA = Int32.Parse(TextBoxA.Text); var valueB = Int32.Parse(TextBoxB.Text); TextBlockResult.Text = (valueA + valueB).ToString(); } 

次に、WP7の新しいプロジェクトをSolultionに追加する必要があります（ファイル-追加-新しいプロジェクト-Windows Phoneアプリ-Windows Phone 7）。

その後、WP7プロジェクトからMainPage.xamlを削除し、WP8プロジェクトからMainPage.xamlへのリンクを追加する必要があります。

WP7プロジェクトのコンテキストメニュー（右クリック）で、[追加]-[既存のアイテム]を選択します。



次に、WP8のプロジェクトフォルダーでMainPage.xamlファイル（このファイルのみ、.csファイルが自動的に追加されます）を見つけ、[リンクとして追加]を選択します。

最終的に、プロジェクトで次のようなものを取得する必要があります。



概して、共通のコードを持つプロジェクトを取得しました。同じ方法で、必要に応じて画像やapp.xamlもリンクできます。 これで、プロジェクトに変更を加え（たとえば、数値入力検証を追加）、両方のプロジェクトでこれらの変更を一度に取得できます。

また、プロパティで両方のプロジェクトに同じ名前空間を指定することをお勧めします。

遅かれ早かれ、各プラットフォームの機能に直面します。 #If / #else / #endifディレクティブを使用して、コンパイルシンボルを使用してこれらの機能を分離できます。 たとえば、WP8およびWin8プロジェクトではApplicationDataを使用し、WP7ではIsolatedStorageを使用してデータを保存するとします。
たとえば、WP8プロジェクトの場合、次のメソッドがあります。

 public async Task SaveText(string text) { var fileBytes = System.Text.Encoding.UTF8.GetBytes(text); var local = ApplicationData.Current.LocalFolder; var dataFolder = await local.CreateFolderAsync("DataFolder", CreationCollisionOption.OpenIfExists); var file = await dataFolder.CreateFileAsync("DataFile.txt", CreationCollisionOption.ReplaceExisting); using (var s = await file.OpenStreamForWriteAsync()) { s.Write(fileBytes, 0, fileBytes.Length); } } 

したがって、WP7の場合、文字列を保存する次のコードがあります。

 public void SaveText(string text) { using (var local = IsolatedStorageFile.GetUserStoreForApplication()) { using (var stream = local.CreateFile("DataFile.txt")) { using (var streamWriter = new StreamWriter(stream)) { streamWriter.Write(text); } } } } 

どうすればコードを可能な限り組み合わせることができますか？

まず、メソッドシグネチャを統一する必要があります。 WP8 / Win8で非同期/待機を放棄するか、WP7で非同期をサポートします。

もちろん、グッズを拒否したくないので、最初に非同期をサポートするプロジェクトであるWP7にMicrosoft.Bclをインストールします。 Nugetパッケージマネージャー（WP7でプロジェクトをクリックするためのコンテキストメニュー-NuGetパッケージの管理）または次のコマンドを使用してNugetコンソールからインストールできます（Tools -Nuget Package Manager-Package Manager Consolからスタジオでコンソールを開くことができます）：
インストールパッケージmicrosoft.Bcl

（既定のプロジェクトがWP7用に選択されたプロジェクトであることを確認してください）。

これで、WP7でテキストを保存するための次のコードを作成できます。

 public async Task SaveText(string text) { using (var local = IsolatedStorageFile.GetUserStoreForApplication()) { using (var stream = local.CreateFile("DataFile.txt")) { using (var streamWriter = new StreamWriter(stream)) { streamWriter.Write(text); } } } } 

WP7およびWP8ファイルでも同じ方法がわかります。 問題は、WP7、WP8、Win8でプロジェクトのメソッド本体をどのように組み合わせるかです。

これは、コンパイル文字を使用して実行できます。 それらをプロジェクトに追加するのは非常に簡単です。 [ビルド]タブのプロジェクトプロパティで、必要なコンパイルシンボルを追加できます（たとえば、WP7 / WP8 / WIN8シンボルを好む）。



ご覧のとおり、既定で既に登録されているWINDOWS_PHONEシンボルに従って、Windows 8プラットフォームとWindows Phoneプラットフォームを分離することもできます。

コンパイルシンボルができたので、次のように異なるプラットフォーム用にコードを分割できます。

 public async Task SaveText(string text) { #if WP7 using (var local = IsolatedStorageFile.GetUserStoreForApplication()) { using (var stream = local.CreateFile("DataFile.txt")) { using (var streamWriter = new StreamWriter(stream)) { streamWriter.Write(text); } } } #else var fileBytes = System.Text.Encoding.UTF8.GetBytes(text); var local = ApplicationData.Current.LocalFolder; var file = await local.CreateFileAsync("DataFile.txt", CreationCollisionOption.ReplaceExisting); using (var s = await file.OpenStreamForWriteAsync()) { s.Write(fileBytes, 0, fileBytes.Length); } #endif } 

このプロジェクトでコンパイルされないコードには灰色の下線が引かれているため、異なるプロジェクトでは、メソッドの選択が異なることに注意してください。 この場合、ファイルはWP7プロジェクトで開かれており、WP8でプロジェクト内のファイルを閉じて開くと、選択が反転します。 コンパイラーはWP8のコードを「見る」

2.共有コードのあるライブラリ

2.1。 WP7共有ライブラリ

WP7およびWP8のみのプロジェクトがある場合、別のWindows Phone 7ライブラリで共通コードを選択し、このライブラリを2つのプロジェクトに使用できます。 これを行うには、新しいプロジェクト（[ファイル]-[追加]-[新しいプロジェクト]）Windows Phoneクラスライブラリを追加し、Windows Phone 7プラットフォームを選択し、この例で電卓（CalculatorCoreなど）を使用して名前を付けます。

このプロジェクトにページを追加するには、Microsoft.Phoneライブラリへのリンクを挿入する必要があります。



[アセンブリ-フレームワーク]タブで：



次のステップは、WP7およびWP8プロジェクトのCalculator Coreプロジェクトへのリンクを追加することです。

Referencesの各プロジェクトに対して、同様にプロジェクトへのリンクを追加します。これは[ソリューション]タブにあります。



これで、MainPageページをこの共有ライブラリに転送できます。

すべてが正しく行われた場合、プロジェクトの構造は次のようになります。



同様に、コンテンツ、ローカライズ、UserControlなどを共有ライブラリに転送できます。

プロジェクトが機能するためには、最後の手順が残ります。プロジェクトが別のアセンブリでこのページを見つけるためには、マニフェストファイル（WMAppManifest.xmlファイル）の各プロジェクトにこのページへの完全なリンクを追加する必要があります。

つまり リンクの代わりに：

/>

完全なパスを登録する必要があります。

/>

ここで、プロジェクトを実行すると、ページが表示されます。 したがって、2つの異なるプロジェクトがあり、1つの共通の作業コードがあります。 次の記事では、各プラットフォームの機能の使用方法について説明します。

2.2。 ポータブルライブラリ

多くの場合、いくつかのWP7 / WP8 / Win8プラットフォーム間でコードを「いじる」必要があります。これらのプラットフォームは、異なるUIを備えていますが、共通のロジックを備えています。

この場合、もちろん、一般的なWP7ライブラリは機能しません。 代わりに、ポータブルライブラリのようなプロジェクトを使用できます（このタイプのプロジェクトは、Windows PhoneではなくWindowsテンプレートにあります）。



ご覧のとおり、Xamarinを使用する場合は、AndroidとiOSでも共通のコードを使用できます（「純粋な」形式では、スタジオはポイントのないAndroidとiOSを提供します）

ここでは、使用するプロジェクトの種類を選択でき、同時に、選択したすべての種類のプロジェクトにあるプラットフォーム機能のみを使用します。

サポートされる機能のより詳細なリストは、 msdn Webサイトで見つけることができます。 または、 Xamarinを使用する場合。

ここでは、このライブラリの詳細については説明しません。次のパートでは、ほとんどの例がポータブルライブラリに関連しているためです。

おわりに

実際には、非常に多くの人々とチームがコード共有に関するアドバイスを求めており、おそらくその選択は提示可能ではありませんが、ほとんどの初心者開発者はファイルのリンクを好むことがわかりました。

一般に、ファイルをリンクすることによる共有の人気は、このアプローチの実装の単純さと速度によるものです。 ほとんどの場合、コードをリファクタリングする必要はなく、既存のコードを使用して、コンパイルシンボルの小さな挿入を行い、プラットフォームの機能をすばやく使用できます。 それどころか、共通のコードを持つライブラリでは、プラットフォーム機能を簡単に分離できないことがよくあります。次の部分では、この点について詳しく説明します。

ファイルリンクのアプローチには2つの重大な欠点があります。そのため、使用しないようにしています。

1. 大規模プロジェクトでは、コードのリファクタリングとメンテナンスは非常に複雑です。これは、コンパイラとスタジオが、コンパイルシンボルで区切られたコードを見ないためです。
2. 新しいプラットフォームまたは新しいソフトウェアを追加する場合、このコードを使用するには、これらすべての変更を繰り返し行う必要があり、多くの場合、すべてのコンパイルシンボルに変更を加えます。 コードのメンテナンスは時々複雑です。

共有ライブラリのアプローチの主な欠点は、より多くのコードが必要なことです（ただし、これはメンテナンスの容易さによって相殺されます）。 また、コードの品質が低いプロジェクトでは、この方法は適していません。 さまざまなチームの協議の中で、私は、共通のライブラリを使用するために、チームがプロジェクトを「きれいにする」ためにかなり大きくて膨大な作業を行わなければならないという事実に繰り返し遭遇しました。 しかし一方で、コードを共有する必要があると考える必要があり、そのために一般的なロジックを間接的に強調する必要があるため、コードの品質が向上しました。

更新しました
ビルド会議では、新しいタイプのUniversalAppsプロジェクトが示されました。これにより、W8.1およびWP8.1用の単一のアプリケーションを作成できました。 詳細については、素晴らしい著者shwarsが書いた記事を ご覧ください。