Android: Co jest lepsze - wiele czynności czy ręczne przełączanie widoków?

Opracowałem kilka aplikacji na Androida i zawsze pozostaje to pytanie:

Jak powinienem zorganizować mój interfejs użytkownika? Czy powinienem uruchamiać aktywność po aktywności i zostawić telefon, aby zrobić przycisk „Wstecz”, czy powinienem wybrać bardziej zoptymalizowany, ale bardziej złożony do wdrożenia sposób z ręcznym przełączaniem widoków, a następnie ręcznie wykonując funkcję przycisku „Wstecz”?

Jak myślisz (lub wiesz) co jest lepszą praktyką?

Powiedziałbym, że wiele działań prawie zawsze ma większy sens. Po prostu nie sądzę, by Android był zaprojektowany do ciągłego przełączania własnych widoków - tak wiele tracisz. Musisz zaimplementować Back sam, nie otrzymasz żadnych przejść między działaniami, musisz zaimplementować dużo wewnętrznej logiki, aby wznowić aplikację w odpowiednim stanie. Jeśli nie podzielisz aplikacji na działania, później znacznie trudniej będzie zmienić przepływ aplikacji. Powoduje to również jedno mega-działanie, które może być znacznie trudniejsze w obsłudze niż wiele mniejszych fragmentów kodu.

Trudno mi sobie wyobrazić, że szybkość jest naprawdę problemem; jeśli tak, to jest coś nie tak ze sposobem inicjowania każdego działania. Na przykład próbowałem przekazywać obiekty możliwe do serializacji między działaniami i okazało się to niewiarygodnie powolne; kiedy przeszedłem na szybszą metodę mijania obiektów, prędkość uruchamiania Aktywności ogromnie wzrosła.

Myślę też, że jest to wymowne, że wytyczne Androida dotyczące projektowania działań i zadań w ogóle nie wspominają o przełączaniu widoków; koncentruje się wokół projektu Activity-as-View.

Chciałbym zwrócić uwagę na kilka przypadków, w których pojedyncza czynność może być lepszym projektem dla aplikacji na Androida, która ma więcej niż jeden widok pełnoekranowy:

• Jeśli ekrany aplikacji są ściśle powiązane i mają wspólny obiekt, na którym wszystkie działają. W tym przypadku przekazywanie Obiektu może wymagać pakietu i może być podatne na błędy, ponieważ będą dostępne jego kopie. Dobrym przykładem może być czarodziej . Tak, możesz użyć statycznych, aby uzyskać dostęp do wspólnego obiektu, ale statyczne mogą być niebezpieczne w Androidzie (pomyśl o zmianach konfiguracji!)

• Jeśli chcesz mieć naprawdę fajne animacje między ekranami. Może chcesz, aby ptak wystartował na jednym ekranie i wylądował na innym ekranie. Spróbuj to zrobić, gdy każdy ekran jest aktywnością!

Z drugiej strony, jeśli jeden z ekranów jest przeznaczony do wyświetlania przez dowolną liczbę innych aplikacji, powinien on być jego własnym działaniem.

AKTUALIZACJA marzec 2014:

W tym miejscu pytanie powinno teraz obejmować wybór fragmentów. Myślę, że widoki są prawdopodobnie najmniej prawdopodobnym wyborem 3: aktywność, fragment, widok. Jeśli chcesz zaimplementować ekrany korzystające z przycisku Wstecz, powinny to być Aktywności lub Fragmenty, ponieważ oba natywnie obsługują przycisk Wstecz. Aby przycisk Wstecz działał, należy dodać fragmenty do stosu wstecznego FragmentManager. Zarządzanie fragmentami, dialogami i tylnym stosem może być jednak trochę irytujące!

AKTUALIZACJA wrzesień 2018:

Niektórzy programiści w Google polecają aplikacje do pojedynczych działań korzystające z nowego komponentu architektury nawigacji .

Należy również pamiętać, że wdrożenie aplikacji z wieloma aplikacjami Activitieszapewni użytkownikowi bardziej spójne wrażenia z całej platformy. Część wrażeń zostanie ukształtowana za pomocą wbudowanych aplikacji Google, więc użytkownicy prawdopodobnie będą mogli łatwiej korzystać z aplikacji, jeśli będzie zachowywać się podobnie do tych, które są już zainstalowane w telefonie.

W odróżnieniu od innych używam mieszanki obu, na przykład
1. Po uruchomieniu aplikacji znajduje się menu główne
2. Klikasz na wyszukiwanie, przenosi cię do czynności wyszukiwania
3. Następnie jest przycisk filtru, który po prostu przełącza widok i pokazuje filtrujesz opcje
4. Na końcu widoku filtru znajdują się dwa przyciski. Naciskasz „Szukaj” lub „Anuluj” i wracasz do widoku wyszukiwania (bez przełączania czynności)
5. Teraz, jeśli użytkownik z powrotem kliknie telefon wrócił do menu głównego zamiast opcji filtru wyszukiwania. Co, jak sądzę, jest właściwym zachowaniem.

Używaj go tak, jak użytkownik poczuje się naturalnie. A trzymanie wszystkiego w jednym działaniu skomplikuje sprawę.

Wszystko zależy od aplikacji, co starasz się osiągnąć lepszą wydajność, płynniejszy interfejs użytkownika. IMHO Wolę drugie podejście polegające na ręcznym kontrolowaniu działań, nawet jeśli jest to bardziej złożone, jak powiedziałeś. Jest to podejście, które zastosowałem w moim projekcie Android Tabs, możesz również rzucić okiem na klasę o nazwie ActivityGroup (nie jesteś pewien pakietu), która pozwala na wiele działań, między którymi możesz się przełączać, dobra rzecz w tej klasie polega na tym, że Twoje działania nie są wyładowywane po przełączeniu, ale złe jest to, że ładowanie głównej aplikacji trwa dłużej.

Tylko moja opinia.

Problem z przełączaniem widoków, na który się natknąłem, jest również spowodowany przez garbage collectora. Wygląda na to, że GC jest wyzwalane po opuszczeniu aktywności, a nie widoku. Na przykład zmiana kart z dość złożonymi widokami potomnymi prawie nieuchronnie doprowadzi do wyjątku przepełnienia stosu.

Miałem tak wiele problemów z układem wielu działań, że zdecydowanie odradzam, chyba że jest dobry powód, aby go wybrać.

Wada wielu działań

Korzystając z wielu działań, bardzo trudno jest refaktoryzować kod w celu zwrócenia danych z działania.

Jeśli nazwiesz działanie podrzędne, działanie główne może zostać zakończone. Ale nigdy nie doświadczysz tego podczas debugowania na przyzwoitym urządzeniu, dlatego musisz zawsze radzić sobie z zapisywaniem i poprawnym odzyskiwaniem stanu. To jest ból. Wyobraź sobie wywołanie metody z biblioteki (tj. Innej czynności) i musisz mieć pewność, że gdy ta metoda zwróci, Twoja aplikacja musi być w stanie całkowicie odtworzyć swój stan ze wszystkimi polami we wszystkich obiektach maszyny wirtualnej (tj. Aktywność. restoreIntance). To niesamowite.

Również w drugą stronę, gdy otwierasz podaktywność, maszyna wirtualna mogła zostać zabita od momentu pierwszego pojawienia się podaktywności, na przykład gdy aplikacja jest zminimalizowana, gdy wyświetlana jest podaktywność.

Jest o wiele czystsze mieć tylko jedno miejsce do przechowywania odpowiedniego stanu aplikacji, aw moim przypadku najczęściej, jeśli maszyna wirtualna zostanie zabita, chcę przywrócić użytkownika do głównego ekranu i pozwolić mu ponownie zrobić swoje, ponieważ nie robię nie spędzają 30-50 godzin na kodowaniu funkcji zapisywania / wznawiania, z której kiedykolwiek skorzysta 0,1% użytkowników.

Alternatywny

Fragmenty lub po prostu sam zarządzaj widokami aktywności. Ręczne zarządzanie widokami wymaga w razie potrzeby kodowania alternatywnych przełączników widoków dla działań / fragmentów z przejściami.

I nie, nie oznacza to jednej mega aktywności, jak sugeruje przyjęta odpowiedź, w żaden inny sposób niż jej jedna mega-aplikacja. Wymaga to po prostu nieco więcej zaprojektowania bazy kodu w pasujące elementy, ponieważ jest nieco więcej pracy przy zarządzaniu widokami, chociaż znacznie mniej pracy na zarządzaniu stanem aktywności i innymi dziwactwami.

Prawdopodobnie istotne: Reddit: To oficjalne: Google oficjalnie zaleca architekturę aplikacji z pojedynczą aktywnością