7

Po przeczytaniu artykułu o Avoiding memory leaks autorstwa @RomainGuy zdałem sobie sprawę, że moja obecna aplikacja na Androida jest nękana błędem przekazywania głównej aktywności aplikacji. Więc za każdym razem, po prostu mogę zastąpić ten parametr aktywności z Activity.getApplicationContext().Wzór polecenia do przekazania metod działania aplikacji?

Jednak w mojej aplikacji istnieją pewne klasy, które nadal wymagają uruchomienia metod, które mogą być tylko członkami głównego działania aplikacji.

Tak więc rozważałem możliwość użycia Command Pattern, aby obejść to ograniczenie.

Problem polega na tym, że jeśli spojrzymy na ten przykład:

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

używam znowu w ślepy zaułek z konieczności przepustkę wokół aktywności (tym razem w przebraniu Object danych).

Jak wyjść z sytuacji "kurczaka &"?

Czy istnieje lepszy sposób rozwiązania tego problemu?

+6

W tym artykule nie ma nic, co sugerowałoby, że "pominięcie głównej działalności aplikacji" jest błędem. Umieszczenie go w statycznych elementach danych * jest * pomyłką, i jest to główny problem, który kryje się za pierwszą i trzecią kulą u dołu artykułu. IMHO, używaj tylko "aplikacji", kiedy dokładnie i dokładnie wiesz, dlaczego jej używasz. Nie jest to zamiennik dla "Aktywności", szczególnie w przypadku pracy z interfejsem użytkownika. – CommonsWare

+2

@CommonsWare Dzięki za wskazanie tej znaczącej różnicy. W moim przypadku przechowuję statyczny element danych SharedPreferences w mojej głównej aktywności, aby ułatwić dostęp do różnych modułów w aplikacji. Mogę więc uzyskać dostęp do wspólnych preferencji, unikając przekazywania głównej aktywności jako parametru: "MainActivity.staticPrefs". Czy jest to uważane za "* Umieszczenie go w statycznych elementach danych *"? – ih8ie8

+1

To dobre pytanie. Ponieważ 'SharedPreferences' jest interfejsem i nie wiem, gdzie jest konkretna implementacja, nie wiem. Jeśli 'SharedPreferences' zatrzymuje się na' Context' - i może się zdarzyć, to musisz albo użyć 'Application' albo ominąć statyczny element danych. Spodziewałbym się, że 'Application' będzie dobrze działał z' SharedPreferences'. – CommonsWare

Odpowiedz

3

Myślę, że to, czego możecie tu przegapić, to właściwy rozdział obaw. Jeśli powiesz, że musisz przekazać główną działalność innym działaniom, aby wywołać jakąś funkcjonalność, wydaje mi się, że architektura Twojej aplikacji ma kilka podstawowych wad konstrukcyjnych.

Niezależnie od tego, czy użyć wzorca polecenia, nie mogę tego stwierdzić, ale zazwyczaj robię to, identyfikując te metody, które wymagają współdzielonego dostępu, przenoszę je do oddzielnej klasy, a następnie utrzymuję oddzielne wystąpienie tej klasy w wszystkie działania wymagające tej funkcji lub jeśli chcesz udostępnić stan wystąpienia, utwórz go w kontekście aplikacji globalnej i zapewnij mu globalną ścieżkę dostępu (niepożądane, ale bez struktury DI, takiej jak RoboGuice, bardzo trudno jest zaimplementować DI na Androida, ponieważ konstruktory są unieważniane.)

Moim zdaniem, w dobrze zaprojektowanej aplikacji Android, działanie jest wolne od logiki biznesowej i zapewnia jedynie operacje zmieniające stan interfejsu. Przepływ interfejsu użytkownika lub jakichkolwiek innych obliczeń pozostawiono by innym klasom. Znacznie pomaga tutaj Model-View-Presenter pattern, aby zachować strukturę kodu przez odpowiedzialność.

Nie dając nam więcej wglądu w to, co dokładnie próbujesz osiągnąć, trudno jest podać konkretne porady.