7

私は Android のプロではありませんが、アプリを非常に大きくする 50 以上のアクティビティで構成されるアプリを開発しました。開発から 8 週間が経過しましたが、現在、アプリのメンテナンスとアップグレードが困難な問題が発生しています。私が扱っている主なものは、

  1. アクティビティのコンストラクターにオブジェクト参照を渡すことができません。startActivityForResult実際、私は– Intent–のメカニズムがonActivityResult本当に制限されており、アクティビティごとのアクションの多くの定数の汚いコードが発生し、その多くswitch caseがアプリの流れをたどるのが本当に難しいことを発見しました。

  2. もう 1 つの問題は、アクティビティごとに独自のライフ サイクルがあるため、アプリ全体のライフ サイクルを管理する方法がわからないことです。

私はLWUITとJ2MEで成功した経験がありました。これは、 J2ME MIDlet を無視し (android のアクティビティに似ています)、独自のアーキテクチャとウィンドウ システムをアプリへのエントリとして 1 つの MIDlet だけで実装するものです。私はアンドロイドについても同じ考えを思いつきました。

明確にするために、Activityオブジェクトを拡張するオブジェクトとして実装されたメイン アクティビティとその他のアクティビティが1 つだけのアプリを考えています。Viewこれらのビューはメイン アクティビティに動的に追加されFrameLayout、互いにスタックされます。アクティビティのロジックはそのようなクラスで実装でき、この方法でダイアログを実装する方法さえ見つけました。ビジネス オブジェクトと状態オブジェクトをコンストラクターに渡すことができます。これは、コードをもう少し書くという副作用を無視して良さそうに思えます。このようにして、リスナーをビューのコンストラクターに渡すこともできるため、アプリの UI 切り替えとフロー管理が容易になります。

しかし、質問は次のとおりです。

  • それは良い習慣ですか？
  • パフォーマンスやメモリの問題が発生しませんか?

私も承知しております

これらのいずれも、合理的な証拠または文書化された参照を使用して、パフォーマンスまたは実践に関する問題に明確に対処していません

誰かこれで私を助けてください

4

2 に答える 2

6

市場には、アクティビティが 1 つまたは少数の人気のあるアプリがあります。彼らはフラグメントを使用してそれらを切り替えます。あなたのアプローチよりも断片を好むでしょう。フラグメントは多くの目的にとって複雑すぎると思いますが、あなたのユースケースではそれが良い解決策になるでしょう. UI 動作はフラグメントである必要があり、アクティビティはフラグメント間でデータを転送するコントローラー部分です。フラグメントにも独自のライフサイクルがあります。

私も好きじゃないstartActivityForResult。一連のアクティビティ (すべてがデータを提供する) があり、それらがどの順序で呼び出されるかわからない場合、シングルトン クラスを使用し、アクティビティ間のデータ転送にインテントを使用することを好みます。しかし、適切な解決策を得るには、問題を分析する必要があります。

于 2012-06-02T12:05:29.207 に答える
1

MVC フレームワークが構築されたPureMVC ライブラリが既にあります。

于 2013-02-14T17:12:50.893 に答える