iOSからAndroidへの新機能

Google Plusでのこの投稿の翻訳。



Nexus Sを購入しました。ここ数日、Android用にプログラムしました。 Android APIでは、ユーザーは非常に優れたプログラマーである必要があります。 Androidの抽象化は、iOSの同等物よりもはるかに巧妙です（肥大化、強制、複雑化）。 一方、「意図」は素晴らしいですが、それを入力した場合のみです。



申し訳ありませんが、次は意識の流れです。 tl; dr







数日間のiOSプログラミングの後、動作するアプリケーションができました。 数日間のAndroidの後、私は抽象化を理解し始めました。



Android開発者は、消費者にAPI（アプリケーション開発者）が自由にやりたいことをやりたいと思っていたようです。 一方、設計パターンの知識の深さは非常に強力で無意味であるため、ほとんどのアプリケーション開発者はタスクを完了するために必要なことの50％しか学習せず、足を撃ち、残りの50％でユーザビリティを突然破壊します。 iOSでは、銃を足に向けることができますが、引き金を引くこともできません。



たとえば、非同期HTTPを正しく実装するには、iOSとAndroidでまったく異なるテストを実行する必要があります。 iOSでは、組み込みライブラリを使用できます。また、リクエスト時にユーザーが突然アプリケーションを切り替える場合、アプリケーションが完了する前にタスクを完了するために、通常はそれ以上の30秒まで余裕があることを確認できます。 Androidでは、 すべての重要なネットワーク呼び出しのために、Androidアプリサービス、APIを実装する必要があります。 アプリケーションはいつでも強制終了できます。そのため、すべての引数を保持し、本当に死んだ場合に備えて再度呼び出しを試行する必要があります。



これは「グッドプラクティス」と呼ばれ、99％のケースに適していると言われています（ただし、多くの不要なコードがあり、自分で作業する必要があります）。 ハードウェアとプロバイダーの制限がアンドロイドの不可欠な部分であることに気付くとすぐに、設計上の決定が明らかになりますが、これはアプリケーション開発者にほとんど喜びを与えません。 iOSは、95％のケースにも適したメソッドをサポートしていますが、開発者が適切に機能するアプリケーションを作成するのに必要な労力ははるかに少なくて済みます。



IOS開発者は優れたドキュメントにアクセスできます。 iOS / Cocoa / Core *ドキュメントライブラリが通常非常に優れており、開発者をより単純な抽象化に向けて正しい方向に導く場所では、Androidドキュメントはいくつかの仮定を行い、Java開発パターンの優れた知識を前提とし、これは独自のAndroidに追加されますパターン。 たとえば、「android.content.ContentProvider」または「android.app.Service」です。



Android開発には大きな可能性があり、本当に優れたアプリケーションがいくつかあります。 彼らがこのエリアにいないと感じるのは私だけです。 私たち（モバイルアプリケーション開発者）が95％の精度で問題をすばやく理解できるように、さらに抽象化が必要です。 現時点では、完璧なアプリケーションを作成できるAPIがありますが、最初のRESTリクエストが正しく機能するようにAndroidの（アンチ？）デザインパターンの研究に数か月投資したい場合のみです。 また、コンピュータサイエンスの専門家になることもできますが、実際、私たち全員がこの道を進んでいるわけではありません。 実際、私たちはほとんどいません（ほとんどすべての素晴らしいiOSアプリに注意を払ってください）。