翻訳者のエントリー

過去2年間にわたってWindows Mobileプラットフォームの開発に携わってきた私は、Apple IPhone、Google Android、Palm Preなどの新しいプラットフォームについて耳を傾けざるを得ませんでした。 しばらく前、私はWindows Mobile開発者のブログに出くわしました。このブログは、「30日のWindows Mobile」をパロディ化してかなりrather笑的なスタイルに保ち、そのシリーズの彼の投稿は「30 Days of Bitching about .NET CF」 「.NET CFの裏で30日間のゴシップ」など。 これらの投稿で、彼は開発中に遭遇した落とし穴について説明しました。

数か月前、このブロガーはHTC G1を買収し、Android開発の世界に突入しました。 AndroidマーケットでいくつかのアプリケーションをリリースしたKushik Dutta（これはまさに彼の名前です）は、Windows MobileとAndroidの開発体験の比較分析を書くことにしました。

オリジナルはこちらです。 この記事は2008年11月に作成されましたが、今日、一部の情報は多少古くなっていますが、これによって悪化することはありませんでした。 テキストには、フォーム[X]の参照がいくつかあり、最後にトランスクリプトがあります。

Android vs Windows Mobile

Andriodの開発について十分深く掘り下げるまで、このトピックに関するブログを控えたいと思いました。 そして、私はAndroidプラットフォームの第一人者ではありませんが、私は冷静にかなり一般的な声明を出し、誰かの水疱を踏み、私の意見を守ることができると信じています[0]

バイトコード

Googleは、Androidに関して興味深い建築的および戦略的な決定を下しました。 最も注目すべきは、開発言語としてのJavaと仮想マシンとしてのDalvikです。 要するに、Dalvikは、実行時にSun JavaまたはMicrosoft Intermediate Language（IL）[1]のバイトコードとして解釈されるバイトコードです。 このすばらしい記事を読むまで、GoogleがJava用に独自のバイトコード仕様を作成することにした理由を理解できませんでした。 しかし、最終的には、SunはJava MEのライセンスに問題があり、モバイルデバイスの「オープン」アライアンス（Open Handset Alliance）は、大企業が溶接を試みない可能性がない限り、オープンプラットフォームを実際に持つことはできませんアカウント[2]

しかし、疑問は未解決のままです。ILがそのようなライセンスによって保護されていないのに、なぜ新しいバイトコードを発明するのですか（ ECMAが承認した標準ですか）。 おそらくグーグルは、ILがモバイルプラットフォームに適していないか、またはMicrosoftと同じベッドで眠りたくないと考え、決定したかもしれません。 後者が最も可能性が高いと思います。

言語

一般的に、舞台裏で生成されるバイトコードは、靴下の色と同じくらい重要です。 私は定期的にそれについて考えていません。 しかし、本当に重要なのはあなたが書く言語です。 Googleは、ターゲット開発者が新しいプラットフォームに移行しやすくするためにJavaを選択したことを理解できますが、それでも...はい、最後に言います。 Javaはダメ。

なぜJavaは吸うのですか？ 数えましょう。

1. パッケージ/ファイル/ディレクトリ/クラス名に関する恐ろしい制限
2. 匿名メソッドの欠如
3. 閉鎖の欠如
4. ラムダ式の欠如
5. イベント/デリゲートなし
6. 部分クラスの欠如
7. リストの面白い実装
8. ジェネリックのひどい実装
9. 構造の欠如と、結果として、複合オブジェクトを全体としてスタックに格納することができません。 これは、重要なパフォーマンスに大きく影響します。
10. 文字列は不変ですが、インターンされません（ インターンを参照）
11. 安全でないコードへのアクセスなし
12. プロパティの取得/設定メソッドはありません
13. オペレーターの過負荷なし
14. 拡張方法はありません
15. 最後に愚かで直感的ではないブラケット

いくつの理由がありますか？ 15？ ハハハ


私は障害を見つけようとはしていません-上記にリストされているものはすべて、私は定期的に使用しています。 ただし、匿名クラスはある程度好きですが、イベント/デリゲートがなければほとんど役に立たないことに注意してください。 私がリストしたのは、概して構文糖衣であり、JavaもC＃もお互いより強力ではないことを理解しています-両方の言語はあなたが必要とするすべての言語であなたが必要とするすべてを行うことができますあなた自身に。 C＃を使用すると、開発をより速く、より効率的に、よりエレガントに進めることができます[3]。

開発環境

Eclipseは巨大な香りのする作品です...ええ。 はい、非常に豊富で柔軟性がありますが、このゴミの使いやすさのテストを実施する人は、首の周りのロープの圧縮強度のテストに取り組む必要があります。


私のお気に入りの痛みは、式ビューをクリックするだけで何も編集できないことです。 必ず右クリックして、[追加/編集]を選択してください。 その結果、Intellisenseのないプリミティブテキストエディターが開き、そこで式を印刷し、エラーがないことを祈って[OK]をクリックします。 間違っています-もう一度繰り返します。
以前、Javaの内部クラスの機能を賞賛しました。 Eclipseがどれほど優れていても、Eclipseはその利便性をほとんど無効にします。内部クラスの親クラス変数の値を見ることができません！ これはデバッグを本当に苦痛にさせます。何かがうまくいかない場合、親クラスをローカル変数にロードする必要があります。 確かに、これがEclipse、Java、Androidのいずれの問題なのかわかりません。

Eclipseの自動アドオンは、ぞっとするほど邪魔です。 開発者の希望に関係なく、すべてをそれほど激しく補うことはできません。 その結果、彼が私に挿入したものはほとんど役に立たなかったので、すべてを完全にオフにしました。 しかし、オートコンプリートを完全にオフにしても、Eclipseは引き続き括弧を付けてくれます...

SDK

Androidの開発について多くの苦情を申し立てましたが、Android自体については苦情を申し立てていないことに注意してください。 実際、私が考えることができるAPIはすべて標準化されて存在しています。
この意味での私のリトマステストは、 クラクソンをAndroidに移植することでした。 2つのプラットフォームの大きな違いを強調するのに大いに役立ちました。

私個人にとって最も顕著な違いは、ハードウェアセンサーにアクセスするためのAPIでした。 Android SDK 1.0は簡単なSensorManagerクラスを提供しますが、これは5分でわかりました。 Microsoftには、Sensor APIのないWindows Mobileの6つのバージョンがありました。

第二に、Androidでのスケジュールされたアプリケーションの起動は、Windows Mobileよりもはるかに簡単です。 Windows Mobileでこれに対処した方法を比較します。

• 私はCeRunAppAtTimeから始めました 。 素晴らしいP / Invokeを書きました。 しばらく動作し、その後完全に停止します。 他の人も同じ問題を抱えていました。 別のメカニズムに切り替える必要がありました。
• 次に、 CeSetUserNotificationExを試しました 。 別の多額のP / Invokeを作成しました。
• これが機能するためには、 UserNotificationTrigger構造体を適切に設定する方法を理解する必要がありました 。
• その後、デバイスがスリープしている場合、 Klaxonは常に正しく動作しないことが判明しました 。
• もう一度ドキュメントをシャベルし、この問題も解決しました。デバイスにenableコマンドを明示的に送信する必要があります。そうしないと、再びスリープ状態になります。
• Klaxonは、夏時間への切り替えが行われるまで、もう少し作業を続けました。 一部の電話では、1時間後に通知がトリガーされます。 理由はわかりません。 あきらめた。

次に、Androidと比較します。

• AlarmManagerを参照してください
• 特定の時間にイベント（意図）のトリガーを構成する
• イベントを処理する

すべてが正常に機能し、問題ありません。 イベントは使いやすく、驚くほど柔軟で同様に強力であると言わなければなりません。


したがって、Android上のWindows Mobileの開発中の2つの困難な部分の1つは、梨の殻をむくのと同じくらい簡単であることが判明しました。 最後に-ユーザーインターフェイス。

WindowsフォームとAndroid XMLレイアウト。 Windows Formsは、絶対寸法と配置で動作します。 Androidは相対的なサイズと位置で動作します。 アニメーションコントロールに対する「静的」コントロール。 実際、比較するものは何もないので、私はしようとはしません。


簡単に言えば、Android SDKはWindows Mobile SDKに細分化されます（言語とフレームワークの機能は考慮されません）。

Windows Mobileにははるかに優れたドキュメント（MSDN）がありますが、これは若いSDKの運命です。

プラットフォーム

Androidはセキュリティの観点から非常に厳しく制限されています。 アプリケーションは必要な機能を登録する必要があり、ユーザーはそれらを確認する必要があります。 しかし、これは非常に前向きなことですが、欠点もあります。 たとえば、自分以外のもののスクリーンショットを撮るアプリケーションを書くことは不可能です。なぜなら、 安全でないと見なされる[4]

また、Androidのせいではありませんが、電話はそれほど「オープン」ではありません。 彼らはそれらを助成します。 たとえば、ユーザーはrootアカウントにアクセスできません。 これにより、Androidにインストールされている標準アプリケーションを設定/変更することはできません。 それでもルートアクセスを取得できる場合は 、標準アプリケーションを実際に変更できます。 それらはソースにあります。

一方、Windows Mobileは何も隠しません。 開発者は、絶対にあらゆるものに低レベルでアクセスできます。 たとえば、AndroidにセンサーAPIがない場合、開発者にはチャンスがありません（ADB経由でバイナリを手動でインストールする場合を除く）。 別の例：AndroidはまだMedia Playerを介したストリーミングビデオをサポートしていません。私の知る限り、OTA更新を介してシステムバイナリにパッチを適用しない限り、何もできません。

そうそう、Androidマーケットです！ 名前から何も言わないので、すべてが明確です。
注：はい、Marketplaceは2009年の秋にのみ表示されます...

おわりに

朝の4時に、なんらかの素晴らしい結論を書かないでしょう。 Windows Mobile向けの開発が本当に好きだとしか言えません。 言語と開発ツールは素晴らしいです。 ただし、プラットフォームとアプリケーションの使用はあまり便利ではありません。 一方、Androidの開発にはそれほど満足していませんが、プラットフォーム、アプリケーション、使いやすさは素晴らしいです！ 最後に、携帯電話と戦ってオンラインにする必要はありません。 だから、どの電話がいつも私と一緒にいると思います。 そして、どの携帯電話の開発にもっと興味があるかを考えてください。

マイクロソフトがユーザーフレンドリーなプラットフォームを作成して、私を幸せなユーザーであり開発者にしてくれることを本当に願っています。 私はこれを言っているとは思いませんが、Appleブックからページを削除する必要があると言います。「後方互換性を忘れ、既存のアプリケーションを忘れ、機能する完全に新しいプラットフォームを作るだけです」 。 あまりにも長い間、彼らは「後方互換性」というマントラに頼り、それは単に彼らが先に進むのを妨げています。 その間、彼らは皆市場から遠ざかりつつあり、その一部は負けを恐れています。

脚注

[0]私はAndroidマーケット向けにTelnetとKlaxonの2つのアプリケーションを開発しました。そのため、Androidプラットフォーム向けの開発についてアイデアがあると思います。 Klaxonは、2つのプラットフォームの大きな違いを強調するのに非常に役立ちました。
[1]はい、ILはWindows Mobileでは解釈されないことを理解しています。 JITコンパイルを通過します。
[2]マイクロソフトの「悪」が何であれ、その特許を擁護しようとする試みでは、ニュースでは見られませんでした。 太陽とは異なり
[3] Rubyを見たい
[4]将来的にはGoogleが行うかもしれません。