• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Are MIDlets keep class members after destroyApp ???

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic