Discussion :

[Nicopilami]

Bonjour à tous

Comme l'indiquent les "best practices", j'utilise une Activity (que j'ai nommée "CommonFunctions") et que j'ai déclarée dans le Manifest en tant que classe statique, afin d'éviter les duplications de code.

Je trouverai dedant par exemple une fonction pour la création de notifications, une pour les alarmes, ...

Ainsi, j'appelle mes fonctions en faisant un ((CommonFunctions)getApplicationContext).mafonction(mesparametres) depuis le onStart de mon activity courante

Le hic, c'est que j'ai l'impression que suite à l'appel d'une telle fonction, je repasse dans le oncreate de mon "activity appelante", et du coup, je me retrouve dans une boucle infinie : OnStart activity1 -> appel fonction CommonFunctions -> OnCreate activity1 -> OnStart activity1 -> appel fonction CommonFunctions ...

-> Est-ce que c'est bien cela qui cause ce comportement ? (ou un bug dans mes fonctions)
-> Si oui, comment éviter cela ?

Merci

[Feanorin]

Bonjour,

est ce que tu pourrais nous montrer un bout de code ?

Merci.

[grunk]

Ca me parrait étrange de créer un activity pour en faire un "sac" à fonctions communes.

Que tu créer une classe static simple avec des fonctions dedans ok , mais une activity, je suis pas convaincu ...
T'as un lien vers cette recommandation ?

[Hephaistos007]

Comme l'indiquent les "best practices", j'utilise une Activity (que j'ai nommée "CommonFunctions") et que j'ai déclarée dans le Manifest en tant que classe statique, afin d'éviter les duplications de code.

Les "best practices" de qui ? parce que là je suis sceptique...

[Nicopilami]

mea culpa, je parlais d'Application, pas d'Activity...

Nico

[Feanorin]

Du coup c'est quoi le rapport avec ta première question.

Si on parle bien d'Application je ne vois plus le rapport avec ta première demande .

[grunk]

Application est plus fait pour contenir des données globales à l'application.
Si tu as des méthodes static de type utilitaires (des helpers en gros) préfère une classe static dédiée.

L'idée étant de garder Application la plus légère possible puisqu'elle est chargée partout.

[nicroman]

Ouais, enfin, les helpers aussi sont chargés en général partout
Mais je ne suis pas sur que gagner quelques Ko d'une classe soit d'un interêt capital.

Il faut surtout raisonner en terme de fonctionnalités, et ou ces fonctionnalités sont nécessaires.

Par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
public <T> T  getView(Activity base, int id, Class<T> cl)
{
    View v = base.getViewById(id);
    if (v == null) throw new IllegalArguementException(Integer.toHexString(id)+" view doesn't exist");
    if (!cl.isAssignableFrom(v))
       throw new IllegalArguementException(Integer.toHexString(id)+" view is not a "+cl.getSimpleName()+" ("+v.getClass().getSimpleName()+")");
    return (T) v;
}

Fonction super pratique à bien des endroit devrait être statique dans une classe "ViewUtils".

Les classes utilitaires n'ayant que des fonctions statiques peuvent être rendues non instanciables avec un constructeur (vide) privé.

[Hephaistos007]

Les classes utilitaires n'ayant que des fonctions statiques peuvent être rendues non instanciables avec un constructeur (vide) privé.

Ou une classe abstraite tout simplement.

[nicroman]

Ou une classe abstraite tout simplement.

Pas tout à fait... une classe "faussement" abstraite peut être instanciée (vive les classes anonymes):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
MaClassAbstraite instance = new MaClassAbstraite{ }();