Pourquoi startApp() est-il utilisé à la place du constructeur dans les applications Java ME?
Beaucoup de didacticiels Java ME utilisent la méthode startApp() pour créer et initialiser des objets et le constructeur est laissé vide. Cependant, la méthode startApp () est également appelée lorsque le MIDlet reprend à partir d'un état en pause. Cela provoque la ré-initialisation de tous les objets et la perte des modifications apportées.
J'ai également remarqué que l'EDI netbeans, dans son code généré automatiquement, utilise de nombreuses instructions if(object==null) dans startApp() pour vérifier si l'objet a été créé antérieur.
N'aurait-il pas de sens de simplement faire toute la création et l'initialisation de l'objet dans le constructeur lui-même? Y a-t-il une raison pour ne pas le faire?
1 answers
Il s'agit en partie de comprendre le modèle de threading MIDP.
Le thread dans lequel le constructeur MIDlet est appelé dépend de qui a développé la machine virtuelle Java sur le téléphone.
Les développeurs ont tendance à ne compter que sur ce que dit la spécification MIDP dans ce domaine, c'est-à-dire comment startApp, pauseApp et lcdui event handling devraient se comporter.
Cependant il n'y a que quelques cas où cela est important.
Le deuxième aspect de ce problème est le logiciel les développeurs essayant de libérer autant de ressources (mémoire, poignées de fichiers, sockets...) que possible lorsque le MIDlet est en pause.
Encore une fois, il y a des cas où les MIDlets devraient s'accrocher à certaines ressources même en pause, mais vous devez vraiment penser à ce que vous faites (et le comprendre mieux que par hasard) lors du codage de ce type de comportement.
Il convient également de rappeler que certains téléphones gardent toujours le processus JVM en cours d'exécution. Quand ils ont aussi une JVM qui ne prend pas en charge la classe déchargement (comme d'habitude dans un monde J2ME), cela signifie que les variables statiques peuvent rester en mémoire même après que le MIDlet a été complètement détruit.