iPhoneおよびiPadアプリケーション用のクロスプラットフォームコード
Model-View-Presenterパラダイムを研究し、iPhoneとiPadのグッズをAppStoreにすぐに投入します
iPhone用に作成されたアプリケーションをiPadに移植するのに最適な方法は、自分だけです。 このWebアプリケーションの特定の例で使用するのに便利ないくつかのレシピしか提供できません。
次に、コード編成パラダイムが提案され、SDK 3.2で利用可能なコンポーネントが検討されます。 そして、あなたは自分で設計パターンを学びます:-)
すべては設計から始まります。 通常、複数のiPhone画面が1つのiPad画面に収まるようにします。
iOSプラットフォーム用のプログラムのユーザーインターフェイスを作成する場合、 Model-View-Controllerパラダイムが使用されます。 ただし、iPhoneおよびiPad用のアプリケーションを移植およびサポートする場合は非常に不便です。 ウィキペディアでそれについて調べることができます。
この画像は、モデルとビューの間に接続があることを示しており、モデルを再利用する自由を侵害しています。 また、コントローラーがやや難しくなります。これは、iPad用に書き直すことにもなります。
代わりに、Microsoftが.Netプラットフォームで初めて導入したパラダイムを使用することをお勧めします。 これは、コントローラーをプレゼンターに置き換えることにより、以前のものから来ました。プレゼンターは、モデルとビューのすべての相互作用を取り、ビューとモデルの接続を切断します。 その結果、モデルはより汎用的になり、コントローラーコードが減少します。
記述されたコードの量を減らし、それに応じてiOSのエラーの数を減らす方法
コード編成戦略でプロジェクトを開始する必要があります。 次の例では、プロジェクト設定を使用し、コードでbtContinueボタンビューを作成します。 これらのビューは、iPhoneとiPadで異なります。 両方のデバイスの2つのアプリケーションをコンパイルする場合、コンパイル段階で動作を変更するマクロによって変更を制御する必要があります。 変更はコンパイルされ、アプリケーションにハードコーディングされます。 #define IPADを使用します。 2つのアプリケーションがあります。1つはiPhone用、もう1つはiPad用です
変更は実行時に監視されます。 UIDeviceを使用します。 iPhoneとiPadの両方で実行される1つのアプリケーションを取得します。
ユニバーサルアプリケーションを作成する場合、プレゼンテーションの定義はそれぞれコード実行モードで行われ、この操作によりプログラムの速度が低下します。
この例からわかるように、両方のアプローチは実際に記述されたコードの量に違いはありませんが、最初のオプションはより速く動作するはずです。
個人的な経験から
人々は合法的なソフトウェアを非常に積極的に使用しています。 たとえば、AppStoreのプロジェクト「 ファイルキャビネット」（仲裁事件のファイルキャビネット）は、1日あたり100回以上ダウンロードされます。
アービトレーションファイルを作成する場合、UISplitViewControllerやUIPopoverControllerなど、SDK 3.2で利用可能な標準コンポーネントを使用することはできませんでした。 たとえば、前者はUINavigationControllerの操作をサポートしていないため、メイン画面にする必要があります。 2番目のコンポーネントは、iPhoneとの後方互換性がありません。 終了 ：コンポーネントを記述します。 ちなみに、サードパーティの開発者はすでにオプションを用意しています。 たとえば、Habré に関する記事があります
ご希望の場合は、iPhoneの画面から借用した情報をiPadの画面にますます多く表示できます。 プロジェクトファイルキャビネットには下位互換性がありました。つまり、ケースインスタンスからケースインスタンスへの移行を使用するために、UIPopoverControllerドロップダウンリストが使用されました。何らかの理由で、iPhoneでの使用が禁止されています。 終了 ：コンポーネントを書き込みます。
ちょっとした練習
通常、実際には、ビューはPresenterで直接形成されます。
Appleのパラダイムでは、画面（ビュー）はリソースに保存する必要がありますが、これは非常に不便です。 モデルはもちろん、コントローラーとの通信を常に維持する必要があります。 Presenterでプレゼンテーションを直接作成することが最も効果的であると判断されました。 同時に、プレゼンター自体のコードを増やす必要はありません。逆に、リスト項目のこの例に示すように、クラスやサブクラスに選択することができます。
弱いハードウェアを扱っていることを覚えておく必要があります。そのため、プロセッサ時間とメモリは非常に重要なリソースになります。 したがって、リソースに表現を格納することが正当化される状況があります。 さらに、この特定のコード例では、これは完全に正当化されます。 単に不要なリンクやこれらのリンクを提供するコードはありません。 それでも、xib（nib）では、UITableViewCellなどのUIViewを保存できます。
しかし、これは、さまざまなiPhone / iPad実装に対して、このxib（nib）リソースが単一になれないことを意味するわけではありません！
多くの場合、人々は新しいものを恐れています。 彼らは、マクロを復活させ、関連性が生じた場合でも、新しい命を吹き込みたくありません。 事実、私たちは単にそれらを調理する方法を知らないだけです。 これは、オートミールのような有用な食品であるだけでなく、たとえば祖母のジャムで味付けされている場合、非常においしいものでもあります。 1つのインターフェイス（クラス）のフィールドを宣言する2つの例に注意してください。 後者では、ちなみに、最初のエラーは修正されています。 しかし、その効果は次のとおりです。似たようなコンパクトなものを忘れた場所にリダイレクトする必要はありません。最も重要なことは、コードが明確になっていることです。
避けられないマクロの使用（嫌な！）
マクロの望ましい使用（それは良いことです！）
まとめ
まず、プロジェクトの設定を定義して、コンパイルまたは実行段階でビューを定義する必要があります。 次に、相互作用のロジックをPresenterに転送して、モデルとビューの関係を取り除く必要があります。
可能な限りxibによって形成された表現を取り除き、アトミックWebのみを残します（たとえば、UIViewTableCellなど）。
次に、iPhone / iPadデバイスのプレゼンテーションを制限するマクロを定義します。 また、Objective-Cは「メッセージ指向プログラム」言語であることを忘れないでください（独自のVCLを作成しています）。
iPhone用に作成されたアプリケーションをiPadに移植するのに最適な方法は、自分だけです。 このWebアプリケーションの特定の例で使用するのに便利ないくつかのレシピしか提供できません。
次に、コード編成パラダイムが提案され、SDK 3.2で利用可能なコンポーネントが検討されます。 そして、あなたは自分で設計パターンを学びます:-)
すべては設計から始まります。 通常、複数のiPhone画面が1つのiPad画面に収まるようにします。
iOSプラットフォーム用のプログラムのユーザーインターフェイスを作成する場合、 Model-View-Controllerパラダイムが使用されます。 ただし、iPhoneおよびiPad用のアプリケーションを移植およびサポートする場合は非常に不便です。 ウィキペディアでそれについて調べることができます。
この画像は、モデルとビューの間に接続があることを示しており、モデルを再利用する自由を侵害しています。 また、コントローラーがやや難しくなります。これは、iPad用に書き直すことにもなります。
代わりに、Microsoftが.Netプラットフォームで初めて導入したパラダイムを使用することをお勧めします。 これは、コントローラーをプレゼンターに置き換えることにより、以前のものから来ました。プレゼンターは、モデルとビューのすべての相互作用を取り、ビューとモデルの接続を切断します。 その結果、モデルはより汎用的になり、コントローラーコードが減少します。
記述されたコードの量を減らし、それに応じてiOSのエラーの数を減らす方法
コード編成戦略でプロジェクトを開始する必要があります。 次の例では、プロジェクト設定を使用し、コードでbtContinueボタンビューを作成します。 これらのビューは、iPhoneとiPadで異なります。 両方のデバイスの2つのアプリケーションをコンパイルする場合、コンパイル段階で動作を変更するマクロによって変更を制御する必要があります。 変更はコンパイルされ、アプリケーションにハードコーディングされます。 #define IPADを使用します。 2つのアプリケーションがあります。1つはiPhone用、もう1つはiPad用です
変更は実行時に監視されます。 UIDeviceを使用します。 iPhoneとiPadの両方で実行される1つのアプリケーションを取得します。
ユニバーサルアプリケーションを作成する場合、プレゼンテーションの定義はそれぞれコード実行モードで行われ、この操作によりプログラムの速度が低下します。
この例からわかるように、両方のアプローチは実際に記述されたコードの量に違いはありませんが、最初のオプションはより速く動作するはずです。
個人的な経験から
人々は合法的なソフトウェアを非常に積極的に使用しています。 たとえば、AppStoreのプロジェクト「 ファイルキャビネット」（仲裁事件のファイルキャビネット）は、1日あたり100回以上ダウンロードされます。
アービトレーションファイルを作成する場合、UISplitViewControllerやUIPopoverControllerなど、SDK 3.2で利用可能な標準コンポーネントを使用することはできませんでした。 たとえば、前者はUINavigationControllerの操作をサポートしていないため、メイン画面にする必要があります。 2番目のコンポーネントは、iPhoneとの後方互換性がありません。 終了 ：コンポーネントを記述します。 ちなみに、サードパーティの開発者はすでにオプションを用意しています。 たとえば、Habré に関する記事があります
ご希望の場合は、iPhoneの画面から借用した情報をiPadの画面にますます多く表示できます。 プロジェクトファイルキャビネットには下位互換性がありました。つまり、ケースインスタンスからケースインスタンスへの移行を使用するために、UIPopoverControllerドロップダウンリストが使用されました。何らかの理由で、iPhoneでの使用が禁止されています。 終了 ：コンポーネントを書き込みます。
ちょっとした練習
通常、実際には、ビューはPresenterで直接形成されます。
Appleのパラダイムでは、画面（ビュー）はリソースに保存する必要がありますが、これは非常に不便です。 モデルはもちろん、コントローラーとの通信を常に維持する必要があります。 Presenterでプレゼンテーションを直接作成することが最も効果的であると判断されました。 同時に、プレゼンター自体のコードを増やす必要はありません。逆に、リスト項目のこの例に示すように、クラスやサブクラスに選択することができます。
弱いハードウェアを扱っていることを覚えておく必要があります。そのため、プロセッサ時間とメモリは非常に重要なリソースになります。 したがって、リソースに表現を格納することが正当化される状況があります。 さらに、この特定のコード例では、これは完全に正当化されます。 単に不要なリンクやこれらのリンクを提供するコードはありません。 それでも、xib（nib）では、UITableViewCellなどのUIViewを保存できます。
しかし、これは、さまざまなiPhone / iPad実装に対して、このxib（nib）リソースが単一になれないことを意味するわけではありません！
多くの場合、人々は新しいものを恐れています。 彼らは、マクロを復活させ、関連性が生じた場合でも、新しい命を吹き込みたくありません。 事実、私たちは単にそれらを調理する方法を知らないだけです。 これは、オートミールのような有用な食品であるだけでなく、たとえば祖母のジャムで味付けされている場合、非常においしいものでもあります。 1つのインターフェイス（クラス）のフィールドを宣言する2つの例に注意してください。 後者では、ちなみに、最初のエラーは修正されています。 しかし、その効果は次のとおりです。似たようなコンパクトなものを忘れた場所にリダイレクトする必要はありません。最も重要なことは、コードが明確になっていることです。
避けられないマクロの使用（嫌な！）
マクロの望ましい使用（それは良いことです！）
まとめ
まず、プロジェクトの設定を定義して、コンパイルまたは実行段階でビューを定義する必要があります。 次に、相互作用のロジックをPresenterに転送して、モデルとビューの関係を取り除く必要があります。
可能な限りxibによって形成された表現を取り除き、アトミックWebのみを残します（たとえば、UIViewTableCellなど）。
次に、iPhone / iPadデバイスのプレゼンテーションを制限するマクロを定義します。 また、Objective-Cは「メッセージ指向プログラム」言語であることを忘れないでください（独自のVCLを作成しています）。
All Articles