Classe statica in Java (Android) – l’uso o il non uso

Di recente ho iniziato lo sviluppo in Java per Android.

Mia idea è quella di creare una classe statica che caricherà sacco di roba sull’inizio e archiviare i risultati per una durata di applicazione.

Ho letto molto di come condividere oggetto tra le attività e penso che la cosa migliore sarà quello di creare una classe statica. Voi cosa ne pensate? Devo utilizzare un altro approccio? Mi chiedo perché ho letto molto di contatore di opinioni su internet.

Grazie.

  • Il modo migliore è quello di utilizzare SharedPreferences
  • Condiviso le preferenze sono un bene per alcuni tipi di dati di piccole quantità di dati che si inserisce una chiave/valore di modello e non ci vuole molto tempo per caricare in memoria. Non è adatta per ogni problema.
  • Vuoi dire un singleton? Una “classe statica” è una classe interna che non necessita di un’istanza del suo allegando classe, che non ha nulla a che fare con la condivisione dei dati a livello dell’applicazione.
  • sì intendevo singleton. Colpa mia. 🙂
InformationsquelleAutor Mihalko | 2013-02-26



3 Replies
  1. 17

    Sto assumendo che si fa riferimento a campi statici di una classe, contro classe statica che, come Wyzard sottolineato, è qualcosa di completamente diverso. Come regola generale di pollice, in possesso di informazioni in campi statici non è una buona idea in Java. La ragione di questo è che impedisce la capacità di creare più istanze di tutto ciò che è memorizzato in classe.

    Nel caso specifico di un’applicazione Android, il miglior modo per affrontare il problema di disporre di dati memorizzati associato con l’applicazione è possibile creare una sottoclasse di android.app.Application di classe e di utilizzarlo per gestire applicazioni-dati globali:

    class FooApplication extends Application
    {
        private String privData;
    
        public String getPrivData() {
            return privData;
        }
    }

    È quindi necessario dichiarare che questa classe è la tua classe principale dell’applicazione (invece di quella di default Application). Nel application entrata in AndroidManifest.xml aggiungere il seguente:

    <application android:name="com.example.application.FooApplication"
                 ...>
        ...
    </application>

    Quindi è possibile individuare l’istanza di applicazione da qualsiasi punto all’interno della vostra applicazione che utilizza il metodo Context.getApplicationContext() che sarà un’istanza della Application sottoclasse:

    FooApplication app = (FooApplication)Context.getApplicationContext();
    String privData = app.getPrivData();

    A seconda da dove si sta cercando di guardare per sottoclasse di “Applicazione”, si potrebbe invocare il “getApplicationContext()” senza “Contesto”:

    FooApplication app = (FooApplication)getApplicationContext();
    String privData = app.getPrivData();
    • Mi riferivo alla classe statica. Ok, io ci sono più commenti su questo tipo di archiviazione dei dati delle applicazioni, così io andrò in questo modo. Grazie.
  2. 3

    Il problema con la tua soluzione è che si sta creando in pratica un enorme pila di variabili globali. A volte è inevitabile, ma ha lo stesso tipo di problemi globali hanno sempre – si rapidamente finire con difficile la lettura del codice che in realtà non hanno una buona ripartizione OO. È possibile utilizzare questo, ma da usare con parsimonia e solo con dati importanti strutture che possono realmente essere condivisa tra più attività.

    • Tutte le API si crea o si usa alla fine si riduce ad un riferimento che è statico o è sempre presente durante la durata dell’applicazione. Tutto dipende da come è progettato.
  3. 2

    Android fornisce una classe denominata Application, che non sarà gc cantando finché l’Applicazione non è ucciso. Utilizzare questa classe per l’inizializzazione, le classi statiche come contenitori sono un po ‘ brutto, ma non riesco a individuare il perché.

    Ho solo usarli come contenitori per le costanti come maschere di bit, che non può essere espresso come EnumSets.

    Come gli altri post menzione SharedPreferences: credo che le preferenze esistono per memorizzare i valori, ma non per caricare le strutture che avete bisogno per la vostra applicazione. Queste strutture devono essere caricate da un costrutto che rappresentano o un modello per i dati della semantica.

Lascia un commento