「断片化」への取り組み：開発者は複数の画面をサポートすることで断言します

Androidはさまざまなデバイスで実行されます。つまり、さまざまな画面サイズと解像度でも実行されます。多くの人がこれを「断片化」と呼びます。デスクトップで何年も同じ方法で設計および開発された製品を使用しているという事実を気にしないでください。どうやらすべてが正確に同じではない場合、「フラグメンテーション」ラベルを取得します。

さまざまなサイズと密度の画面を使用する場合に発生する問題に対処するさまざまな方法があります。 Appleには、iPhone用とiPad用に設計されたアプリの個別のリストがあります。マイクロソフトは、大画面デバイス用の新しいエコシステムを作成します。 Androidは、開発者が同じアプリを画面ごとに異なる動作にする方法を提供します。それぞれの方法には長所と短所がありますが、ここではAndroidに焦点を当てます。

Androidでは、アプリケーションはさまざまなサイズの画面と解像度に合わせてレイアウトを調整できます。これはすべて組み込まれていますが、アプリの見栄えを良くするために開発者がコードで宣言する必要があるいくつかのことがあります。留意すべきことは、画面サイズと密度がアプリの外観をどのように変えるかです。 Droid DNAは、Motorola XOOMタブレットよりも高解像度の画面を備えていますが、携帯電話サイズの画面上のアプリのタブレットレイアウトは見たくありません。

開発者は、高解像度で鮮明に見えるほど十分に高品質のアセット（画像）を提供する必要があります（めちゃめちゃ高解像度を気にしないでください）。これにより、ボタンやその他のコントロールのようなものが、Galaxy S2のような低密度の画面で本当に大きくなったり、DNAのような高密度の画面で本当に小さくなったりするのを防ぎます。

複雑に聞こえますが、これらのほとんどはアプリのコーディング時に行われます。開発者が行う必要があるのは、適切な宣言を行い、任意のサイズ（物理的サイズと解像度の両方）またはレイアウトをサポートする適切なアセットを提供することだけです。 Google+アプリのような複数のレイアウトアプリでさえ、考えられるすべての画面をカバーするために同じコードを使用します。

ここで開発者を判断しようとはしていません。アプリを書くのは大変です。 Android開発者は、Gingerbreadのリリース以来、これらすべてを説教してきましたが、どれほど実用的ですか？数人の開発者にそれについて尋ねたところ、休憩後に彼らが何を言わなければならないかがわかりました。

詳細：GoogleのAndroidデベロッパーサイト。

このテーマに関するいくつかの基本的な質問を、少数の開発者（大小両方）に依頼しました。

ガイドラインに従うのはどれくらい難しいですか？
紙の上では簡単に見えますが、これまでに見た特別な問題や、Googleがカバーしていない部分はありますか？
仮にそうであったとしても、これは開発時間とコストにどのように影響しましたか？
あなたが共有したい主題についてさらに何か？

バイアスをかけずにこれに入らないように、質問をできるだけ中立にするようにしました。疑わしいときは、知っている人に尋ねますよね？プログラミングはかなりやりましたが、JavaでのコーディングとAndroidアプリの構築は、Cやマシンコード、さらにはPerlでのコードの記述とは大きく異なります。アプリを作成する一般的な方法を習得しても、理解できない微妙な違いがあります。

かなりの数の皆さんが私のようであり、Androidアプリの作成の複雑さを知らないことを想像します。 Android開発者の発言を見るだけで、簡単に聞こえます。彼らにとっては、おそらくそうです-彼らは2007年以来、このようなものをゼロから書いてきました。彼らをフォローすることができた人々が言っていることを見てみましょう。

ジョー・シンプソン（@kennydude）-ボイド

JoeはTeam Boidのメンバーであり、自分でアプリケーションを公開しています。彼（および彼のチームの残りの人）は、いくつかの素晴らしいアプリケーションを開発したAndroidへの情熱を持つ独立した開発者の素晴らしい例です。

ガイドラインに従うことは、特に無駄のないアプリが欲しいが、人々が後方互換性を望んでいる場合、かなり難しいです。最も厄介なことの1つは、d.android.com / designで何かがどのように見えるかを見ることですが、実際にそれを行う方法は何もありません。

弱点は、Twitterが原因でGCMを物理的に使用できず、PtRを使用したくない場合の更新です。また、Googleのアプリは独自のガイドラインを構成しています。たとえば、スライドインペインを例にとると、Google +はYouTubeとは異なる方法で機能します（ただし、サポートライブラリがこれを解決することを願っています）。

また、ポイントを得ることができ、何かに関するドキュメントはありません（たとえば、EdgeEffect）。

私は学生ですので、費用は見た目ではなく、時間がかかりますが、ユーザーはあなたを愛しています。基本的に、ライブショー（ADiA、App Clinic、Office Hours）は必須です（残念ながら）、Googleのアプリに関するフィードバックを提供することはできません。

Boidはまもなくオープンソースになります（イェーイ！）。アプリ自体はGoogle Playで見つけることができます。ここには、Joeのすべてのアプリ（宝石があります）もあります。

クリストフ・ヴェルシュー-BeTrains-SNCBベルギー; ホロ

Christopheは、BeTrains-SNCB Belguimなど、数多くのAndroidアプリケーションを構築しました。SNCBBelguimは、適切に構築されたアプリケーションで何ができるかを示す豪華なレイアウトのアプリです。米国のほとんどはこれを使用しませんが（ベルギーの鉄道の列車のスケジュールアプリです）、どれだけうまく機能しているかを確認するためだけにインストールする価値があります。西ヨーロッパの人々は確かにこれについて知っています。

さらに、彼はHoloEverywhereを共同開発しました。これは、他の開発者がAndroid 2.1以降用のHoloスタイルのアプリケーションを構築するために使用できるライブラリです。まだ多くの携帯電話がGingerbreadを実行しているので、これはアプリを最新の状態に保ちたい開発者にとって本当におもしろいものです。

難しくありません。真剣に。困難な部分は、顧客がそれらのガイドラインから逃れるように要求するときに来ます！

画面の下部にタブを配置し、iPhoneのボタンをどこにでも配置し、iPhoneスタイルのトグルをしたいという顧客を覚えています。このプロジェクトを達成するのは非常に難しく、多くの時間とお金を失いました。

彼がこれらすべての愚かなことを尋ねたとき、私は彼に本当に怒っていました、そして、彼はちょうど私が怠けている開発者であると思いました。

私は彼と多くの連絡を取り合っており、彼のアプリを全面的に書き直し、これらの役に立たない機能をすべて削除して「純粋な」Androidアプリを作成することで素晴らしいコードを作成しています。顧客と企業は、これらのガイドラインを意識するだけでよいと強く信じています。

ActionBarSherlock、HoloEverywhere（私の作成）、UnifiedPreferences、SlidingMenuのようなライブラリは非常に使いやすく、数行のコードで素晴らしいユーザーエクスペリエンスを提供します。

私が言ったように、時間とコストはGoogleのガイドラインに従うことで最小限に抑えられます。フラグメントとレイアウトフォルダーは非常に使いやすい（そして再利用することがより重要です）：タブレットアプリは携帯電話のレイアウトからコードを取得するだけで、何も書き換える必要はありません。同じFragmentが使用されているため、電話アプリの小さな変更はタブレットアプリにすぐに反映されます。

いくつかのすばらしいプロジェクトは、必ずしもGoogleではなく、コミュニティによって作成されています。 Roman Nurik（Google）、Reto Meier（Google）JuhaniLehtimäki、Jake Wharton、Taylor Lingなど、Google +で非常に活発に活動している人たち（重要な人々を忘れることを常に恐れています）開発者はどこを見ればよいかを知るだけで、Android開発は簡単になります！

BeTrainsはGoogle Playで見つけることができます。Androidの開発に興味がある場合は、HoloEverywhereをご覧ください。

マシュー・ルノ-ザッポス

私たちが話をしたいくつかの小規模な独立した開発者とは対照的に、ZapposのMatthewからも聞きました。 ZapposはWeb小売企業であり、Webサイトとアプリケーションの両方の設計専用の予算を持っている可能性があります。それは私が定期的に購入する会社でもありますが、これには何の関係もありませんでしたし、マシューは私が頻繁に顧客であることに気づきませんでした。

Zapposでは、小売業者であるため、何よりもまず自社ブランドに固執する必要があります。奇抜で楽しく、少し外れています。そうは言っても、私たちはどちらもAndroidの設計ガイドラインを強く信じており、UIで行うすべてのことはそれらのルールの精神に基づいています。 1年前、私たちのアプリは、見た目と動作の面から、ほとんどがiOSの移植版でした。今日、それは（私が思うに）Androidでできることの宝石です。私たちは可能な限りガイドラインを遵守します-そして、私たちのデザイナーは出発点としてそれらから働きます。

設計のガイドラインはすべてではなく、すべてを終えたものではありません。最終的には、Androidアプリの設計をより一貫性のあるものにしようとするためのものです。私たちが使用した一般的な「新しい」オープンソースライブラリのほとんどは、ガイドライン（スライドメニュー、クルトン）の一部として終わっていることがわかりました。

ガイドラインは決して差し控えるべきではありません。特定のこと-全体的なナビゲーション-は、アプリが「正常に動作する」ように一貫している必要があります。その他すべて-ガイドラインから始めて、設計を実行します。私たちはアプリを私たちのアプリにしたいので、ベースラインのホロテーマだけを行うことはできません。

今年は基本的に、フラグメントを処理するためのアプリの書き直しから始めました。過去6か月間、7インチタブレットのサポートを追加するために一生懸命取り組んできましたが、現在10インチサポートに取り組んでいます。最も難しいのはデバイスでのテストですが、それを支援する優れたQAチームがいます。 8月かそこらからアプリでフルタイムで作業している人が2人いましたが、それ以前は1人のフルタイムの人でした。

結論として、Androidの設計ガイドラインはプロセスの合理化に役立ち、それによりコストを削減できると思います。 iOSからのほとんどのデザイナーが直面している-だから、design.android.comのような素晴らしいリソースを持っていることは、Androidエコシステムで彼らをキックスタートさせるための素晴らしい助けです。

Zapposのデザインの選択肢はうまく機能しており、私の妻は私の主張を補強する服、財布、ブーツでいっぱいのクローゼットを持っていると言えます。 Google PlayからAndroidアプリをチェックしてください。

ジョシュ・バートン-jRemote

JoshはAndroid用の多数の小さなアプリケーションを作成しており、彼のjRemoteアプリケーション（人気のあるjDownloader PCプログラムのコントローラー）は、レイアウトを使用して携帯電話とタブレットの両方で見栄えの良いアプリを作成する方法の完璧な例です。これにより、デバイス画面の使用が最大化され、探している情報を正確に予測できます。

設計ガイドラインを順守することは、最初から順守している限り、非常に簡単です。アプリ全体を開発し、最後に戻ってフラグメント/タブレットレイアウトなどを実装しようとすると、時間、労力、フラストレーションが無駄になります。しかし、アプリを計画し、最初からフラグメントを使用して開発し、すべての適切なdpiバケット用のリソースを作成すると、開発が簡単になり、ガイドラインについて考えるのに多くの時間を費やす必要がなくなります。行き詰まった場合でも、デザインドキュメントはクリックするだけです。彼らは素晴らしいリソースです。

非常に多くのデバイスがタブレットレイアウトを持っていないことに本当にイライラします。アプリがフラグメントを使用して構築されている場合、タブレットレイアウトの追加は30分で完了します。正直なところ、それは簡単です。

多くの開発者にとって、テストするタブレットデバイスはないので、エミュレータを使用するのは大変です。しかし、リリースされたばかりの新しいADTツールにより、はるかに簡単になりました。レイアウトエディターのマルチ構成ビューにより、5〜6種類の画面サイズで一度にレイアウトがどのように見えるかを確認できます。そしてその高速。もちろん、最終的にはエミュレーター/デバイスでテストする必要がありますが、ワークフローが確実に高速化されます。

jDownloaderはデスクトップで使用する便利なプログラムであり、jRemoteはそれを制御する素晴らしい方法のように見えます。それ以外の場合は、Google Playからダウンロードして、アプリが同時にシンプルで美しいものになる方法を確認してください。

同じことを言っている他の多くの開発者から聞いた。それらをすべてリストアップするために、ここにはスペースがありません。それのすべての要点は、あなたが前もって計画すれば、Android開発者のガイドラインは本当にほとんどの場合うまくいくということです。私たちはそれを聞いてうれしく、素晴らしいアプリを楽しみ、熱心な開発者をサポートし続けます。