• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

Are MIDlets keep class members after destroyApp ???  RSS feed

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
It seems that destroyApp() does not touch class members (attributes) or in MIDP 2.0 spec is an error.
Look at the example on page 95 (SamplePingMe class).
On start of the startApp() it checks dconn == null.
But dconn is not initialized in constructor!
It assumes that there was destroyApp() earlier and there is dconn=null.
I think that in J2SE compilator I would have compilation error ("variable might not been initialized").
Does anybody know if there is any place in spec that guarantees that after destroyApp() variables are kept?
On the other side - is such a programming practice that is shown in this example really good? I think it is not...
 
Maciej Wegorkiewicz
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And another aspect:
If attributes are kept it means that after destroyApp the device cannot garbage app class. What if this class allocated a lot of memory? It is strange as we know CLDC devices can have very little amount of memory.
 
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Maciej Wegorkiewicz:
... or in MIDP 2.0 spec is an error.


You'd find that often this isn't the case...

Look at the example on page 95 (SamplePingMe class).
On start of the startApp() it checks dconn == null.
But dconn is not initialized in constructor!


Dude - dconn is a class member. Its automatically initialized to null.
Cheers.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!