今日、ローカルの.NetイベントでMonoのセッションを終了した後、MonoTouchの使用は、iPhone開発の代替手段として「触れられました」。 C#と.Netで非常に快適であるため、Monoスタックのいくつかの奇抜さにもかかわらず、魅力的なオプションのようです。しかし、MonoTouchの価格は400ドルなので、これがiPhone開発の方法である場合、私はやや引き裂かれます。
MonoTouchとObjective-Cを使用した開発経験のある人は誰でも、MonoTouchを使用した開発はObjective-Cの学習よりもはるかに簡単かつ迅速であり、400ドルの価値がありますか?
この投稿には、MonoTouchandObjective-Cを試したことがない開発者からの多くの伝聞があります。 MonoTouchを試したことがないのは、主にObjective-C開発者のようです。
私は明らかに偏見がありますが、MonoTouchコミュニティのこれまでの状況を確認できます。
そこでは、Objective-CとC#の両方で開発した開発者からの記事がいくつかあります。
したがって、以前の 類似した質問 に対する私の答えは、Objective-Cを学ぶことです。 (また、デバッグのサポートも忘れないでください)
これはおそらく気分を害するでしょうが、正直なところ、真剣な開発を行うつもりなら、Objective-Cを学ぶ必要があります。 iPhone開発でObjective-Cを知らないと、邪魔になります。多くの例を理解することはできません。 Monoの癖に対処する必要がありますが、Objective-Cの実用的な知識があれば、プラットフォームのドキュメントをもっと活用できます。
個人的には、プラットフォームのネイティブ言語よりもMonoを使用するほうが、必要な情報量を増やすという立場を理解していません。それは私にとって幾分逆効果のようです。これが非常に高価な提案(新しい言語の学習)である場合、基本的なプログラミング概念に時間を費やす価値があり、新しい言語の学習はかなり安価な提案になると思います。
別のユーザー も書いています:
モノタッチが簡単になりました。しかし、後で難しくなります。
たとえば、何らかの理由でMonoTouchをテストする必要がありますが、テストする必要がある新しいシードが出てきたらどうなりますか?
Monoに固執することで、フレームワークのリソースを検索するときはいつでも、Monoでそれらをどのように使用するかを精神的に変換する必要があります。あなたのアプリのバイナリは大きくなり、Objective-Cへの数ヶ月後の開発時間はそれほど速くなく、他のアプリ開発者はネイティブプラットフォームを使用しているため、あなたよりもはるかに有利になります。
もう1つの考慮事項は、Objective-Cよりも言語に精通しているため、C#の使用を検討していることです。しかし、iPhoneの学習曲線の大部分はObjective-Cではなく、フレームワークです。C#でも同様に呼び出す必要があります。
どのプラットフォームでも、そのプラットフォームの設計哲学を直接表現するプラットフォームを使用する必要があります-iPhoneでは、Objective-Cです。これを逆の角度から考えてください。GTKでプログラミングに慣れているLinux開発者がWindowsアプリを作成したい場合、C#を使用せず、GTKに固執することをお勧めします。
Monoの使用は松葉杖ではありません。 iPhone OSに追加するものはたくさんあります。 LINQ、WCF、Silverlightアプリ、ASP.NETページ、WPFアプリ、Windowsフォームアプリ間で共有可能なコード、およびAndroidのモノもあり、Windows Mobileでも機能します。
そのため、Objective-Cを書くのに多くの時間を費やすことができます(C#でまったく同じサンプルコードを書くことはOCよりもはるかに少ないという多くの研究からわかります)。私にとって、MonoTouchを選んだのは、書いているクラウドアプリには多くのインターフェイスがあり、iPhoneはそのうちの1つにすぎないからです。 WCFデータをクラウドからMonoTouchアプリにストリーミングするのは非常に簡単です。さまざまなプラットフォーム間で共有されるコアライブラリがあり、iPhone/WinMobile/Android/SilverLight/WPF/ASP.NET展開用の単純なプレゼンテーションレイヤーを記述するだけで済みます。 Objective-Cですべてを再作成すると、すべての機能を再利用するのではなく複製する必要があるため、製品が前進し続けるため、初期開発とメンテナンスの両方で膨大な時間の無駄になります。
MonoTouchをs辱したり、そのユーザーが松葉杖を必要としていることをほのめかしている人々は、.NETフレームワークを指先に持つことの意味についての全体像を欠いており、おそらくプレゼンテーションとロジックの適切な分離を理解していないプラットフォームやデバイス間で再利用できます。
Objective-Cは興味深く、多くの一般的な言語とは大きく異なります。私は挑戦が好きで、さまざまなアプローチを学びます...しかし、そうしないと私の進歩が妨げられたり、不必要な再コーディングが作成されたりしません。 iPhone SDKフレームワークには本当に素晴らしい点がいくつかありますが、そのすべてがMonoTouchで完全にサポートされ、すべての手動メモリ管理が不要になり、同じタスクを実行するために必要なコードの量が減り、アセンブリを再利用できます。私のオプションを開いたままにして、他のデバイスやプラットフォームに移動できるようにします。
切り替えました。 Monotouchを使用すると、少なくとも3〜4倍の速さでアプリを作成できます(Obj Cの古い1か月に1回のアプリと比較して、1か月に4つのアプリ)
少ないタイピング。
ちょうど私の経験。
これがあなたがこれまでに開発する唯一のiPhoneアプリであり、Macアプリケーションの開発にまったく興味がない場合、MonoTouchはおそらくその価値があります。
IPhoneアプリをさらに開発したり、Macのネイティブ開発を行いたいと思う場合は、Objective-Cと関連するフレームワークを学ぶ価値があります。さらに、あなたが新しいことを学ぶのが好きなタイプのプログラマーであれば、勉強するのは楽しい新しいパラダイムです。
個人的には、Objective-Cを学ぶだけで楽しい時間を過ごすことができると思います。
要するに:
UnityやMonoTouchのようなプロジェクトは「時間を節約する」はずですが、最終的にはドメイン固有の言語を学ぶ必要があり、時には物事を回避する必要があります。 (カレンダー時間で)学習を避けようとしている言語を学習するのと同じくらい長い間、おそらくすべてがあなたを連れて行くでしょう。最終的には時間を節約できず、製品と密接に結びついています。
編集:.NETについて否定的なことを暗示することを決して意図していませんでした。私の要点は、風変わりなオブジェクトブラケット表記法にまだ慣れていないからといって、複雑なレイヤーを追加することはあまり意味がないということです。
他の人がすでに言ったことに追加するために(まあ!):私の気持ちは、心配する必要があるバグの数を基本的に2倍にし、MonoTouchのバグをiPhone OSのバグに追加することです。新しいOSバージョンの更新は、通常よりもさらに苦痛になります。うん、周りに。
MonoTouchで私が目にする唯一の説得力のあるケースは、多くのC#プログラマーとC#コードを抱えている組織で、iPhoneで活用する必要がありますmust (3500ドルでさえ点滅しないお店の種類。)
しかし、ゼロから始める人にとっては、価値があるとか賢明とは思えません。
3つの単語:Linq to SQL
はい、それは$の価値があります。
Objective-Cに時間を費やすのは、主にこのようなサイトから得られるすべての支援のためです。 Objective-Cの強みの1つは、CおよびC++コードを使用できることであり、十分にテストされたのプロジェクトが数多くあります。
もう1つは、コード(選択言語)がAppleによってサポートされるということです。たとえば、iOS 5.xでは、MonoTouchなどのサードパーティソリューションのサポートが削除されますか?それでは、顧客に何を伝えますか?
Objective-Cに移行する準備が完全に整っていない場合は、HTML5のようなプラットフォームに依存しないソリューションを使用した方が良いでしょうか?
MonoTouchを数か月使用していますが、ObjectiveCから完成したアプリを移植して、将来のある時点でAndroidをサポートできるようにしました。
これが私の経験です。
悪いビット:
Xamarin Studio。私のようなインディー開発者は、Xamarin Studioの使用を余儀なくされています。毎週改善されており、開発者はバグを特定して修正するフォーラムで非常に活発ですが、それでも非常に遅く、頻繁にハングし、多くのバグがあり、デバッグもかなり遅くなります。
ビルド時間。 大(リンク)アプリをビルドしてデバイスでデバッグするには数分かかる場合があり、これはほとんどすぐにデプロイされるXCodeと比較されます。シミュレーター(非リンク)用のビルドは少し速くなります。
MonoTouchの問題。イベント処理に起因するメモリリークの問題が発生しました。ビューを出入りするときにイベントをアタッチおよびデタッチするなど、リークを防ぐためにかなりprettyい回避策を講じる必要がありました。 Xamarin開発者は、このような問題を積極的に調査しています。
サードパーティのライブラリ。私は自分のアプリで使用するObjectiveCライブラリの変換/バインドにかなりの時間を費やしましたが、Objective Sharpieなどの自動化ソフトウェアでは改善されています。
より大きなバイナリ。これは本当に気にしませんが、私はそれを言及すると思いました。 IMO数個の余分なMbは最近では何もありません。
良い点:
マルチプラットフォーム。私の友人は私のコアコードベースからアプリのAndroidバージョンを喜んで作成しています。並行して開発しており、DropboxのリモートGitリポジトリにコミットしています。うまくいっています。
。ネット。 C#.Netでの作業は、Objective C IMOよりも優れています。
モノタッチ。 iOSのほとんどすべてが.Netにミラーリングされており、動作させるのはかなり簡単です。
Xamarin。これらの人たちは、すべてを改善し、開発をよりスムーズで簡単にするために本当に働いていることがわかります。
特にVisual Studioで動作するBusinessエディションまたはEnterpriseエディションを使用するお金がある場合は、クロスプラットフォーム開発にXamarinをお勧めします。
別のプラットフォームで必要になることのないiPhoneアプリのみを作成していて、あなたがIndie開発者であれば、今のところXCodeとObjective Cを使い続けます。
受け入れられた答えがあったとしても、私が追加したいことはあります-誰がAppleはMono Touchで構築された兆候があるアプリを単に拒否しないのでしょうか?
C#とObjective-Cの両方の経験がある人として、ほとんどの人にとってXamarinはお金に見合うだけの価値があると思います。
C#は本当に優れた設計言語であり、C#APIも優れた設計です。もちろん、Cocoa Touch API(UIKitを含む)のデザインも優れていますが、言語はいくつかの方法で改善できます。 C#で記述する場合、Objective-Cで同じコードを記述するよりも生産性が高くなります。これにはいくつかの理由がありますが、いくつかの理由は次のとおりです。
C#には 型推論 があります。型の推論により、割り当ての左側にある型を「知る」必要がないため、コードの記述が速くなります。また、リファクタリングがより簡単になり、より節約できます。
C#には generics があり、同等のObjective-Cコードと比較してエラーが減少します(Objective-Cには回避策がありますが、ほとんどの場合、開発者はそれらを回避します)。
最近、Xamarinは Async/Await のサポートを追加しました。これにより、非同期コードの作成が非常に簡単になります。
MonoTouchは、主にCocoaTouch APIを非常に簡単な方法で実装します。たとえば、CocoaTouchの使用経験がある場合は、MonoTouchのコントロールのクラスを見つける場所がわかります(MonoTouch.UIKitには、UIButton、UIView、UINavigationControllerなどのクラスが含まれます。同様に、MonoTouch.FoundationにはNSStringのクラスがあります。 NSDataなど)。
Xamarinは、PhoneGapやTitaniumなどのソリューションとは異なり、ユーザーにネイティブエクスペリエンスを提供します。
現在、Objective-CにはC#に比べていくつかの利点がありますが、ほとんどの場合、C#でアプリを作成すると、開発時間が短縮され、コードがクリーンになり、同じアプリを他のプラットフォームに移植する作業が少なくなります。注目すべき例外の1つは、OpenGLに依存する高性能ゲームです。