Jak zadeklarować zmienne globalne w Androidzie?

Napisałem tę odpowiedź w 2009 roku, kiedy Android był stosunkowo nowy, a w rozwoju Androida było wiele niezbyt ugruntowanych obszarów. Dodałem długi dodatek na dole tego postu, odnosząc się do pewnej krytyki i szczegółowo opisując filozoficzny spór, jaki mam z użyciem singletonów, a nie podklasowania aplikacji. Przeczytaj na własne ryzyko.

ORYGINALNA ODPOWIEDŹ:

Bardziej ogólnym problemem, z którym się spotykasz, jest to, jak zapisać stan w poprzek kilka czynności i wszystkie części aplikacji. Zmienna statyczna (na przykład singleton) jest powszechnym sposobem osiągnięcia tego w Javie. Odkryłem jednak, że bardziej eleganckim sposobem w Androidzie jest powiązanie stanu z kontekstem aplikacji.

Jak wiadomo, każda czynność jest również kontekstem, czyli informacją o jej środowisku wykonywania w najszerszym tego słowa znaczeniu. Aplikacja ma również kontekst, a system Android gwarantuje, że będzie istnieć jako pojedyncza instancja w całej aplikacji podanie.

Sposobem na to jest stworzenie własnej podklasy Androida.app.Application , a następnie określ tę klasę w znaczniku application w manifeście. Teraz Android automatycznie utworzy instancję tej klasy i udostępni ją dla całej aplikacji. Możesz uzyskać do niego dostęp z dowolnej metody {[4] } za pomocą metody Context.getApplicationContext() (Activity zapewnia również metodę getApplication(), która ma dokładnie taki sam efekt). Poniżej przedstawiamy niezwykle uproszczony przykład, z zastrzeżeniami do follow:

class MyApp extends Application {

  private String myState;

  public String getState(){
    return myState;
  }
  public void setState(String s){
    myState = s;
  }
}

class Blah extends Activity {

  @Override
  public void onCreate(Bundle b){
    ...
    MyApp appState = ((MyApp)getApplicationContext());
    String state = appState.getState();
    ...
  }
}

Ma to zasadniczo taki sam efekt jak użycie zmiennej statycznej lub Singletona, ale całkiem dobrze integruje się z istniejącym frameworkiem Androida. Zauważ, że nie będzie to działać między procesami (jeśli Twoja aplikacja będzie jednym z rzadkich, które ma wiele procesów).

Coś do odnotowania z powyższego przykładu; załóżmy, że zamiast tego zrobiliśmy coś w stylu:

class MyApp extends Application {

  private String myState = /* complicated and slow initialization */;

  public String getState(){
    return myState;
  }
}

Teraz ta powolna inicjalizacja (np. uderzanie dysku, uderzanie sieci, blokowanie czegokolwiek itp.) będzie być wykonywane za każdym razem, gdy aplikacja jest instancyjna! Możesz pomyśleć, cóż, to tylko raz na proces i tak będę musiał zapłacić koszty, prawda? Na przykład, jak wspomina Dianne Hackborn poniżej, jest całkowicie możliwe, aby twój proces został utworzony-po prostu-w celu obsługi zdarzenia transmisji w tle. Jeśli przetwarzanie transmisji nie ma potrzeby tego stanu, potencjalnie wykonałeś całą serię skomplikowanych i powolnych operacji za nic. Lazy instantiation to nazwa gra tutaj. Poniżej znajduje się nieco bardziej skomplikowany sposób korzystania z aplikacji, który ma większy sens dla wszystkiego, ale najprostszych zastosowań: {]}

class MyApp extends Application {

  private MyStateManager myStateManager = new MyStateManager();

  public MyStateManager getStateManager(){
    return myStateManager ;
  }
}

class MyStateManager {

  MyStateManager() {
    /* this should be fast */
  }

  String getState() {
    /* if necessary, perform blocking calls here */
    /* make sure to deal with any multithreading/synchronicity issues */

    ...

    return state;
  }
}

class Blah extends Activity {

  @Override
  public void onCreate(Bundle b){
    ...
    MyStateManager stateManager = ((MyApp)getApplicationContext()).getStateManager();
    String state = stateManager.getState();
    ...
  }
}

Chociaż wolę podklasowanie aplikacji niż używanie singletonów jako bardziej eleganckiego rozwiązania, wolałbym raczej, aby deweloperzy używali singletonów, jeśli jest to naprawdę konieczne, zamiast w ogóle nie myśleć o wydajności i wielowątkowości implikacji kojarzenia stanu z podklasą aplikacji.

Uwaga 1: również jako anticafe skomentowano, aby poprawnie powiązać nadpisanie aplikacji z aplikacją niezbędny jest znacznik w pliku manifestu. Ponownie Zobacz dokumenty Android, aby uzyskać więcej informacji. Przykład:

<application
     android:name="my.application.MyApp" 
     android:icon="..."
     android:label="...">
</application>

Uwaga 2: user608578 pyta poniżej, jak to działa z zarządzaniem cyklem życia obiektów natywnych. Nie jestem na bieżąco z używaniem kodu natywnego z Androidem w najmniejszym stopniu i nie mam kwalifikacji, aby odpowiedzieć na pytanie, w jaki sposób miałoby to współdziałać z moim rozwiązaniem. Jeśli ktoś ma na to odpowiedź, jestem gotów zapisz je i umieść informacje w tym poście, aby uzyskać maksymalną widoczność.

Dodatek:

Jak zauważyli niektórzy, jest to , a nie rozwiązanie dla uporczywego państwa, co być może powinienem był bardziej podkreślić w oryginalnej odpowiedzi. Nie ma to być rozwiązanie do zapisywania użytkownika lub innych informacji, które mają być przechowywane przez cały okres życia aplikacji. Tak więc, uważam większość krytyki poniżej związane z aplikacji jest zabity w każdej chwili, itp..., nie ma znaczenia, ponieważ wszystko, co kiedykolwiek musiało zostać zapisane na dysku, nie powinno być przechowywane przez podklasę aplikacji. Ma to być rozwiązanie do przechowywania tymczasowego, łatwego do ponownego utworzenia stanu aplikacji (na przykład, czy użytkownik jest zalogowany) oraz komponentów, które są pojedynczymi instancjami (na przykład menedżer sieci aplikacji) (, a nie singleton!) w naturze.

Dianne stwierdza: "nie ma powodu, aby podklasować z aplikacji. To nie różni się od tworzenia Singletona..."To pierwsze twierdzenie jest nieprawidłowe. Istnieją dwa główne powody tego. 1) klasa aplikacji zapewnia lepszą dożywotnią gwarancję dla programisty aplikacji; gwarantowana jest żywotność aplikacji. Singleton nie jest bezpośrednio związany z żywotnością aplikacji (chociaż faktycznie jest). Może to nie być problem dla przeciętnego dewelopera aplikacji, ale powiedziałbym, że jest to dokładnie taki rodzaj umowy, jaki powinien oferować Android API i zapewnia znacznie większą elastyczność systemu Android, minimalizując żywotność powiązanych danych. 2) Klasa aplikacji zapewnia programista aplikacji z posiadaczem pojedynczej instancji dla stanu, który bardzo różni się od posiadacza pojedynczego stanu. Lista różnic znajduje się w linku wyjaśniającym Singleton powyżej.

Dianne kończy się słowami: "sam framework ma mnóstwo singletonów dla wszystkich małych współdzielonych danych, które utrzymuje dla aplikacji, takich jak bufory załadowanych zasobów, pule obiektów itp. Działa świetnie."Nie twierdzę, że używanie singletonów nie może działać dobrze lub nie jest uzasadnioną alternatywą. Argumentuję, że Singletony nie zapewniają tak silnej umowy z systemem Android jak korzystanie z podklasy aplikacji, a ponadto używanie singletonów ogólnie wskazuje na nieelastyczną konstrukcję, która nie jest łatwa do modyfikacji i prowadzi do wielu problemów na drodze. IMHO, silny kontrakt Android API oferuje deweloperom aplikacji jest jednym z najbardziej atrakcyjnych i przyjemnych aspektów programowania z Androidem i pomógł doprowadzić do wczesnego przyjęcia dewelopera, który doprowadził platformę Android do sukcesu, jaki ma dzisiaj. Sugerowanie używania singletonów jest w domyśle odejściem od mocnego kontraktu API i moim zdaniem osłabia Androida ramy.

Dianne skomentowała również poniżej, wspominając o dodatkowym minusie korzystania z podklas aplikacji, mogą one zachęcić lub ułatwić pisanie kodu o mniejszej wydajności. Jest to bardzo prawdziwe, i edytowałem tę odpowiedź, aby podkreślić znaczenie rozważania perf tutaj, i biorąc poprawne podejście, jeśli używasz podklasowania aplikacji. Jak stwierdza Dianne, ważne jest, aby pamiętać, że klasa aplikacji będzie tworzona za każdym razem, gdy proces zostanie załadowany (może być wiele razy na raz, jeśli aplikacja działa w wielu procesach!) nawet jeśli Proces jest ładowany tylko dla zdarzenia transmisji w tle. Dlatego ważne jest, aby używać klasy aplikacji bardziej jako repozytorium dla wskaźników do współdzielonych komponentów aplikacji, a nie jako miejsca do przetwarzania!

Zostawiam ci następującą listę minusów singletonów, skradzionych z wcześniejszego linku StackExchange:

• niemożność użycia abstrakcji or interface classes;
• niemożność podklasowania;
• wysokie sprzężenie w całej aplikacji (trudne do modyfikacji);
Jest to bardzo trudne do przetestowania (nie można udawać/naśmiewać się w testach jednostkowych); [70]} Nie jest to jednak żaden problem, ponieważ nie jest to możliwe.]}

I dodaj własne:

W 2007 roku firma została założona przez firmę Microsoft, która od 2007 roku zajmuje się produkcją i dystrybucją oprogramowania dla Androida.]}