Android開發中的設計模式原理是什麼？

Question

我是一個JaveEE開發者。最近我加入了一個Android開發團隊。 Android的結構讓我困惑。 MVC設計模式似乎不適合Android開發。那麼Android開發的設計模式原則是什麼？我的意思是有任何關於如何編寫乾淨，簡單的閱讀和有效的Android代碼的暗示。

Answer 1

Android的架構起初讓我惱火，但是我開始看到一種讓他們瘋狂的方法。它很少被android文檔解釋。我最大的抱怨一直是，你的活動像普通應用程序一樣共享對象的集中數據模型很困難。 Android似乎希望我成爲一名遊牧民，因爲我只能在我的活動之間分享原語。在數據庫中丟棄垃圾並不是一個模型，因爲它不包含任何行爲。因此，大多數人的業務邏輯都以我的活動結束，很難在其他活動中共享業務邏輯。

我來找出我錯過了一些關鍵的拼圖。 Android是MVC。但是，它與View相當。

1. 活動==控制器
2. 型號==應用的子類
3. 任何一個繼承查看==查看

有趣的是，你可以創建應用程序的一個子類，並在您的清單文件中聲明該，並且Android將創建一個此對象的單個實例，該實例的長度始終保持在應用程序的長度上，而不管Activity被銷燬或創建。這意味着您可以構建一個所有活動都可以訪問的集中式數據模型。

我看到的這種方式就像初始化Spring容器，你可以初始化對象並解決它們之間的依賴關係。這樣，您可以將應用程序的模型部分與Activity本身分離開來。只需讓Activity對模型進行調用，然後手動回調即可接收結果，以便更新UI。

Android的問題在於它將控制器和視圖混合在一起。例如，像TabActivity，ListActivity這樣的子類意味着正在使用某個視圖。因此，交換視圖是相當重要的。此外，即使您使用「活動」，Controller也會對視圖進行非常具體的假設。他包含對TextView等UI對象的直接引用，並且它註冊了低級別事件，如點擊，鍵盤等。

如果Activity可以註冊更多高級事件，如「Login」，「Update帳戶餘額「等，視圖將響應一系列點擊，鍵盤，觸摸事件而分派。這樣，控制器就可以在您可能描述的功能而不是設計功能的級別上工作。

我想我們最終會達到這種類型的設計，因爲我們更好地理解想出更好的工具和技術。看起來Android可能具有可擴展性來實現這一點，但是社區需要繪製它。

Answer 2

Android中的動作，視圖和活動是用Android UI工作的，並且是模型視圖視圖模型的實現，它在結構上與模型視圖控制器（在同一族中）類似。

據我所知，沒有辦法擺脫這種模式。它可能可以完成，但您可能會失去現有模型的所有好處，並且必須重新編寫自己的UI層才能使其工作。

您可以在以下找到MVC：

• 定義你的user interface由分辨率/硬件等各種XML文件
• 您可以通過語言環境等
各種XML文件定義您 resources
• 您將SQLite中的數據或您的自定義數據存儲在/ assets /文件夾中，詳細瞭解resources and assets
• 您擴展類似ListActivity，TabActivity和inflaters
• 利用XML文件的，你想爲你的模型，您可以創建許多類，並有自己的包，將作爲
• 很多Utils已經被結構爲你寫。 DatabaseUtils，Html，

沒有可以服從的單個MVC模式。 MVC只是或多或少地聲明你不應該混合數據和視圖，例如視圖負責保存處理數據直接影響視圖的數據或類。儘管如此，Android處理類和資源的方式，有時甚至被迫遵循MVC模式。在我看來，更復雜的是這些活動有時對於觀點負責，但在同一時間充當控制者。

如果你在xml文件中定義你的視圖和佈局，從res文件夾加載你的資源，並且如果你或多或少地在代碼中混合這些東西，那麼你無論如何都會遵循MVC模式。

Answer 3

我的印象是，android編程模型與MS WPF有很多相似之處。 XML佈局定義，總是綁定到其中一個定義的代碼...所以，如果您因爲想要改進當前或開發android項目而詢問設計模式，也許您應該查看WPF實踐和模式用於改進架構，如MVVM。

請查看以下鏈接：

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

有一個已經嘗試類似的事情，小項目：

http://code.google.com/p/android-binding/

歡呼

Answer 4

Android開發主要是圖形用戶界面的開發，像Java中的Swing/AWT包含許多匿名內部類reactin g到GUI事件。其中一件事讓我擺脫了與Swing的大量合作......但是我擁有一部Android手機，所以我會咬緊牙關，然後克服它，就像許多蘋果迷們說的那樣關於天線問題。 ;）

Answer 5

Android使得製作控制器和查看單個類的典型決策成爲可能。這鼓勵把太多的東西放在同一個地方。一個活動對應一個屏幕，每個視圖到一個屏幕區域（有時是整個屏幕），每個用戶的控制器都是從屏幕的該區域進行手勢操作的，模型只是模型，有時由環境或其他服務提供支持瘋狂的一套實用功能。我使用Activity來協調一個或多個MVC三重奏。這有助於處理Android的選擇，把所有東西都放在同一個地方。

我可以在不運行模擬器的情況下測試絕大多數Android應用程序。大贏。

Answer 6

對不起，我的英語。

Android具有非常好的模塊化（活動，片段，視圖，服務等）。所以在MVC中沒有必要。

當然，有輸入（活動，片段），邏輯，視圖（XML或Java）和數據（數據庫，文件，首選項）的分離。但這不是MVC。你不應該嘗試使用MVC，它只會使你的架構複雜化。

Android並不是將東西放在全局範圍內，而是激勵您儘可能在對象範圍（類成員，局部變量）中保留對象，並使用Intents/Bundles將對象傳遞到活動或傳遞到片段。這也是由於內存限制。如果前景活動 需要更多的資源，因此係統必須關閉後臺進程 恢復記憶

該系統可能會破壞你的活動。

因此，將非常量（可變）對象存儲爲全局（靜態）對象並不安全。通常你使用static作爲不變的常量。

簡而言之，你將你的應用程序劃分成屏幕（Activities）。然後，每個屏幕 - 成片段（碎片）。要在屏幕上執行一系列操作，您還可以使用Fragments（example）將它們分開。

因此，您的應用程序中有非常小的塊，每個塊都可以輕鬆測試和重用。