7

在閱讀@RomainGuy的Avoiding memory leaks文章後,我意識到我目前的Android應用程序存在着傳遞應用程序主要活動的錯誤。所以無論何時,我都可以簡單地用Activity.getApplicationContext()替換該活動參數。命令模式來傳遞應用程序的活動方法?

但是在我的應用程序中有某些類仍然需要運行只能是應用程序主要活動成員的方法。

因此,我想使用Command Pattern來解決這個限制。

的問題是,如果我們看看這個例子:

public class SomeCommandExecuableOnlyByActivity implements Command 
{ 
    public void execute(Object data) 
    { 
     doIt(((MyActivity)data).getWindow()); 
    }  
} 

我又遇到了需要周圍的活動通(這一次僞裝Object數據)的死衚衕。

我該如何擺脫這種「雞蛋&」的局面?

有沒有更好的方法來解決這個問題?

+6

該文章沒有聲稱「傳遞應用程序的主要活動」是一個錯誤。把它放在靜態數據成員*中是一個錯誤,這是文章底部的第一個和第三個子彈背後的核心問題。恕我直言,只有當你具體和準確地知道你爲什麼使用它時才使用'Application'。它不是'Activity'的全面替代品,特別是用於UI工作。 – CommonsWare

+2

@CommonsWare感謝您指出這一重大差異。在我的情況下,我在我的主Activity中保留了一個靜態SharedPreferences數據成員,以便應用程序中的各個模塊輕鬆訪問。所以我可以通過避免將主Activity作爲參數傳遞來訪問共享首選項:'MainActivity.staticPrefs'。這是否被認爲是「*把它放在靜態數據成員*」中? – ih8ie8

+1

這是一個很好的問題。由於'SharedPreferences'是一個接口,我不知道具體實現在哪裏,我不知道。如果'SharedPreferences'持有一個'Context' - 它可能 - 然後你需要使用'Application'或避免靜態數據成員。我希望'Application'能夠與'SharedPreferences'一起正常工作。 – CommonsWare

回答

3

我想你在這裏可能會錯過的是一個適當的問題分離。如果你說你必須將主要活動傳遞給其他活動以調用其中的某些功能,那麼在我看來,你的應用程序的體系結構有一些基本的設計缺陷。

是否在這裏使用命令模式我不知道,但我通常會做的是確定那些需要共享訪問的方法,將它們移動到一個單獨的類,然後將該類的一個單獨的實例所有需要此功能的活動,或者如果您需要共享實例狀態,請在全局應用程序上下文中創建它併爲其提供一個全局訪問路徑(不是理想的,但沒有RoboGuice之類的DI框架,在Android上實現DI非常困難,因爲構造函數是無效的。)

在我看來,在一個精心設計的Android應用程序中,一個Activity沒有業務邏輯,只提供改變UI狀態的操作。用戶界面或任何其他計算的流程將留給其他類。 Model-View-Presenter pattern在這裏幫助很大,以保持您的代碼由責任結構。

儘管沒有讓我們更深入地瞭解您準確實現的目標,但很難給出具體的建議。

相關問題