web-dev-qa-db-ja.com

企業がモバイルアプリ内に複数のモジュールを出荷しないのはなぜですか？密結合について懸念はありますか？

まえがき：私の質問はGoogleだけに関係するのではなくiOSだけに関係するわけではありません。多くの人に馴染みがあるので、例としてGoogleとiOSのみを使用しています。 「Company X」、アプリ「A」、「B」、「C」、「D」、「E」、および「Android」を同じように簡単に使用できたが、実際の質問に根ざしたい具体的な例のある世界。

IOSアプリストアには、Googleに多くのアプリがあります。一目で「グーグル検索」「グーグル+」「グーグルマップ」「グーグルアース」「Gmail」が見えます。

しかし、私は疑問に思います-これらの5つのアプリが提供するすべての機能を提供できる「Google」アプリを単に作成しなかったのはなぜですか？黒いメニュー各GoogleWebページの上部にあるバーは、これをWeb上で可能にします。では、なぜ「グローバル」なGoogleアプリの下部にあるメニューボタンを使用してこれを可能にしないのでしょうか。

  • Googleはアプリ間の緊密な結合を懸念していますか？
  • Googleは、アプリを開発するチーム間の密結合を懸念していますか？
  • Googleはアプリのサイズを心配していますか？
  • Googleは、そのようなモノリシックアプリがロードされたときに発生する可能性のあるメモリフットプリントまたはCPU負荷について懸念していますか？

[暴言ではありません。悪魔の代弁者を演じるだけです。]

多くの利点があるにもかかわらず、一部のiOS批評家は、アプリの複数のページがiPhoneとiPadを「雑然とした」感じにさせていると言います。これは私の質問に特に関係があります。なぜなら、ユーザーが非常に多くのGoogleモバイル製品について知っている（そして管理している）ことを期待するのは少し難しいように思われるからです。製品の観点から、そしておそらく使いやすさの観点から、単一のアプリを出荷するのが賢明であるように思われます。

Google's Black Menu Bar

興味があれば、私はiPhoneとNexus 7を持っている。そのため、2つの主要なモバイルプラットフォームのどちらにも慣れていません。

そして、私はここで解決すべき本当の問題を抱えています-1つの大きなアプリ内に複数のアプリをバンドルするのか、それとも複数のアプリに別々の機能を分散させるのか。

EDIT：応答として、 @ MichaelTのコメント

architecturedeploymentmobilecoupling
4
Jim G.

素人の言葉で：

  • すべてのユーザーが会社のすべてのアプリを使用するわけではない
  • ユーザーが異なればニーズも異なります
  • 一部だけが必要なのに、なぜユーザーにフルパッケージの購入を強制するのですか？ （OK、Googleアプリは無料ですが、他のソフトウェアメーカーは無料ではありません。）
  • これらのアプリを個別に用意することで、個別に更新でき、最も重要なこととして、個別に販売することができます。
  • 複数のアプリが同じ会社によって作成されているという事実は、それらが一緒に属していることを意味しません。
  • Photoshop、Lightroom、Reader、Dreanweaverなどで構成される単一の「Adobe」アプリがあると想像してみてください。
  • このモジュールを備えた単一の「Apple」アプリを想像してください：iPhoto、iTunes、Apertureなど。
  • このロジックはデスクトップアプリとモバイルアプリの両方に適用されます

編集：

  • モバイルアプリには通常、メモリ制限があります（@AndreF）
  • モバイルアプリは通常無線でダウンロードされるため、ファイルサイズを大きくすることはお勧めできません。
  • マルチモジュールアプリをナビゲートするには、さらに多くの手順が必要です。モバイルユーザーは、より簡単で高速なGUIを必要としています。
22
Tulains Córdova

ユーザーは、モバイルアプリが単一のタスク、または非常に関連のあるタスクの小さなセットを実行することを期待しています。

あなたが言及するモバイルプラットフォームは、特に電話OSとして始まりました。通常、ユーザーはスマートフォンで多くの短いタスクを終日実行します。これはデスクトップコンピュータとはまったく異なります。この短いバースト使用パターンは、シングルタスクアプリに直接アクセスできるカスタマイズ可能なホーム画面の設計につながりました。サードパーティの開発者は、アプリを単一のタスクに集中させることも推奨されていました。

タブレットの登場により、モバイルデバイスの使用パターンは多様化しましたが、ベンダーはもともと電話ユーザー向けに最適化されたパラダイムを維持することを選択したようです。ユーザーが慣れてきていると思います。

Googleアプリの例に戻ると、ほとんどの人はすべてを必要としているわけではありません。また、ホーム画面が乱雑になると、適切なアプリやタスクを見つけにくくなる可能性があることは事実です。追加レベルのナビゲーションを備えたアプリはほとんど同じです。

6
Kris Van Bael

3つの言葉：関心の分離1つのことをします（そしてそれをうまくやります）。 ;-)

補足：ある種の「ウィンドウ管理」またはその他のクレイジーロジックを再実装せずに、単一のアプリでマルチタスクを実行することはできません。それが私の最初の声明に戻ります…

2
nietonfir

最大の理由は、顧客が実際に使用したいソフトウェアを提供するには、小規模なチームの方が効果的であるため、できるだけ小さなチームを使用する必要があるためです。 「まあ、個々の機能に小さなチームを使用して、後でそれらを組み合わせてみませんか？」と思うかもしれません。複数のチームの作業をシームレスで一貫した方法で組み合わせるのは非常に難しいことがわかりました。そして、そのような製品の管理（どのような機能が必要ですか？どのように宣伝しますか？など）も非常に面倒です。

現在、一部のAndroidアプリは実際にこれを制限付きで実行します。Googleマップアプリには、マップ、ナビゲーション、ローカルの3つの異なるエントリポイントがあります。これらは、ユーザーには3つの個別のアプリのように見えますが、マップという1つのパッケージをインストールすると、3つすべてが得られます。これらすべてに必要な同様の機能がたくさんあり、同じグラフィックやアイコンが必要なため、これは理にかなっています。基本的には、 「オールインワン」マップアプリのメインメニューと、アプリを使用するたびにユーザーに質問に答えさせるのではなく、ランチャーに「プッシュアップ」します。これは、「アプリの機能」は「アプリの選択」と同じように感じられます-ランチャーでアイコンを選択します。

1
kindall

グーグルが何を懸念しているのかは言えないが、私はどう思うか：

  • Is Google concerned about tight coupling between the apps?-アプリをまとめると、個別に更新することはできません。単一の（サブ）アプリのすべてのマイナーアップデートは、アプリのアップデートになります。これは、多くの小さな更新が頻繁に行われるか、大きな更新がほとんど行われないことを意味します（これはバグ修正には適していません）。

  • Is Google concerned about tight coupling between the teams that develop the apps?-チームは別々に作業できますが、チーム間の調整が必要です。特にアプリのビルドと統合に。良い面は、1つのアプリしかビルドされないため、必要なビルド/アーキテクチャエンジニアが少なくなる可能性があることです（各チームにそのようなメンバーは必要ありません）。

  • Is Google concerned about app size?-サイズはモバイル環境では有効な懸念事項です。ただし、一度ダウンロードするだけなので、アプリのサイズ自体は大きな問題ではないと思います。私は頻繁な更新についてもっと心配していますが、ユーザーが望まないこともあります（ユーザーが使用していないサブアプリが更新された場合）。遅いネットワークとデータ料金が主な理由です-使用しないアプリの一部を更新するため、不要な更新を待たなければならないことを想像してみてください。そして、あなたはそれを支払う必要があります...

  • Is Google concerned about the memory footprint or CPU load that such a monolithic app might incur when it is loaded?-アプリの構造によっては、分離した場合と比較して、それほど多くのメモリ/ CPUを必要としない場合があります。ただし、アプリ/リソースのサイズは大きくなります。アプリケーションには、メソッド/クラスの数など、さまざまな制約があります。内蔵ストレージのスペースが多すぎる可能性があります。

1
stan0

それらはそれぞれ別個のプログラムであり、それらをすべて同じアプリ内で実行すると、デバイスのプロセッサで多くの使用量が発生します。それらを別々にすることは、プロセスを分割することができ、すべてが同じスレッドで同時に実行されるわけではないことを意味します。このようにすることで、OSはアプリをバックバーナーに配置できるようになり、他のプロセス/アプリがプロセッサの可能性を最大限に活用できるようになります。いずれにしても、それらすべてを同時に使用することはできません。

それらはアドビのアプリケーションスイートのようなバンドルとして提供される可能性がありますが、そのスイートは複数の個別のアプリケーションで構成されているため、それらの1つを使用するためだけにすべてを同時に実行する必要はありません。

0
Malachi

他のすべての投稿された意見に反対するリスクがあるので、すべてが統合されたGoogleモバイルアプリを作成することは素晴らしいと思いますが、邪魔にならない方がいいと思います。

彼らのソフトウェアの多くは、単一のユーザーアカウントに適用できます。私は個人的にGmail、Google検索、Googleドライブを最もよく使用しています。これらのアプリは個別のアプリですが、統合されています。ブラウザでこれら3つのアプリのいずれかを既に使用していて、もう1つのアプリに移動する必要がある場合は、上部のナビゲーションバーがアプリを切り替えるための最良の方法であることがわかります。

Programmatic Thinking＆Learning Refactor Your Wetware で、Andy Huntは、マルチタスクとコンテキストの切り替えは生産性に悪影響を及ぼし、これにはアプリを切り替えて作業を行うことも含まれると述べています。

Alt-Tab（またはMacの場合はCommand-Tab）が何と呼ばれるか知っていますか？これはコンテキストスイッチです。

Emacs は、非常に多様な機能と目的を備えた単一の強力なプログラムの良い例です。その成功を見てください。37年以上の歴史があり、今でも非常に人気のあるエディターです。 Emacsから、メールのチェックと送信、ファイルの編集、シェルコマンドの実行、Webの閲覧、イベントとToDoのスケジュール設定などを行うことができます。コンテキストを切り替えることなくこれらすべてを行うことができます。

同様に、Googleはモバイルアプリをリンクすることでコンテキストの切り替えを軽減するか、Googleアプリを作成することで完全に回避できます。

*生産性がアプリの目標ではない場合、またはアプリが完全に無関係である場合、アプリを単一の製品に結合する十分な理由はないと思います。 Googleの場合、そのアプリの多くは生産性を重視しています。

0
Korey Hinton