Blackberry Application design question - Singletons

Question

Je suis en train de refactoriser une application Blackberry et j'ai un scénario où je pense que j'utilise actuellement une variable globale, mais je ne suis pas sûr que ce soit la bonne chose à faire. Brièvement, mon scénario est le suivant -

Mon application nécessite d'abord l'utilisateur de se connecter. Les (uid, pass) sont envoyés à un service Web qui détermine si la connexion est valide et renvoie des données supplémentaires. J'ai un objet modèle sur mon application qui ressemble à quelque chose comme ça - (Après un login appelant avec succès)

class UserDataModel 
{ 
    private String username; 
    private String password; 
    private String fullName; 
    private String age; 
    ... 
    /* Getters and Setters */ 


} 

J'ai aussi un UserPreferencesModel qui contient toutes les préférences que l'utilisateur a sauvé. (J'ai besoin de les sauvegarder dans notre base de données/les restaurer sur plusieurs appareils, etc.)

De plus, dans quel contexte les Globals sont-ils généralement utilisés dans le contexte du développement mobile?

Merci,
Teja.

Answer 1

sont quelques scénarios lorsque la variable statique est bonne idée. comme pour les champs de chaîne constante.

Voici le lien vers blackberry officiel Document sur les meilleures pratiques pour l'écriture de code efficace pour la plateforme blackberry.

Black Berry: Best Practices: writing efficient code

Answer 2

Il n'y a rien particulièrement spécial à propos de BlackBerry en ce qui concerne l'utilisation des singletons. Bien sûr, les vraies constantes devraient être juste statiques. Et tous devraient être finaux mais Strings: il y a une pénalité d'utilisation de la mémoire si un static final String est réutilisé souvent dans votre code. Ce que singleton vous donne est la possibilité de remplacer ou d'enlever des modèles complexes avec une durée de vie relativement longue via un point de contrôle unique. Dans votre exemple, DataModel est un bon candidat. BlackBerry est un périphérique personnel, il y a donc de fortes chances que ce DataModel avec profil utilisateur et, probablement, des données supplémentaires, survive pendant la durée de vie de l'application active. Ainsi,

class UserDataModel 
{ 
    private static UserDataModel singleton; 

    public static void login() { 
     //get credentials 
     //authenticate 
     singleton = new UserDataModel(... user profile data...); 
    } 

    public static UserDataModel getInstance() { return singleton; } 

    private String username; 
    private String password; 
    private String fullName; 
    private String age; 
    ... 
    /* Getters and Setters */ 


} 

Cette façon de faire est valide, un peu simplifiée, par exemple. Si quelque chose change (disons, hôte du serveur), tout ce que vous devez faire est de remplacer singleton. De plus, cela ouvre la possibilité d'utiliser le polymorphisme, si l'implémentation de UserDataModel est différente pour différents serveurs, etc. Il y a de nombreux avantages au prix d'une variable supplémentaire dans une chaîne d'accesseurs. Encore une fois, il n'y a rien de spécial à propos de BlackBerry ici, ce raisonnement est valable dans n'importe quelle application Java. Pourquoi l'exemple est simplifié parce que vous devez penser à des threads. S'il y a même une faible chance que quelque chose accède à getInstance() sur un thread différent de login(), vous devez les synchroniser correctement (même si je n'ai jamais été capable de casser une simple référence d'objet en accédant/discussions sur BlackBerry).

Answer 3

Eh bien, je fait un exemple simple comment vous pouvez utiliser le RuntimeStore, je souhaite que ce soit utile de

public class myData 
{ 
long ID = 0xf46f5a7867d69ff0L; 
String d1; 
RuntimeStore runTS = RuntimeStore.getRuntimeStore(); 

public void setData(String _d1) 
{ 
    try 
    { 
     syncronized (runTS) 
     { 
      runTS.put(ID, _d1); 
     } 
    }catch(Exception ex){} 

} 

public String getData() 
{ 
    String s; 
    try 
    { 
     s = (String)(RuntimeStore.getRuntimeStore().get(ID)); 
    }catch(Exception ex){} 
    return s; 
} 
}