The T720 is a strange beast, and some of you may have read my post about not being able to rely on even very simply code (ie: j = 0). After much work I''ve narrowed down the problem (a bit). The T720''s memory seems to get temporarily corrupted. By temporary I mean that memory can get turned to mush and then magically fix itself at some future time. To verify this try allocating a really large buffer (like an image, buf store it as an array of ints), display the buffer somehow, and then interrupt your app using the volume key on the side of the phone. When you return to your app you might be surprised at what is being displayed. For some types of bufferes this is not such a big deal (I can''t belive I said that) but for any flags that or state variables your using this can be catastrophic. Here are the steps I''ve taken to minimize the effect of the T720''s bad attitude. 1. Avoid static varaibles. Thats right: static int j seems to be less reliable than int j. 2. Anywhere you need to set a global variable, make sure your code is structured so that you can reset it again before it''s actually used. ie: static int myState; void mainloop() { myState = 6000; . . . stateHandler(); } void stateHandler() { if ( myState != 0 || myState != 1) myState = 0; } So what we''ve done is just made sure any ''default'' state changes are affected when we need them, thus avoiding the T720''s poor short-term memory. As ugly as this phone appears to the developer, it is attractive to the consumer. If you''re writing you apps for a variety of platforms I would suggest targeting this phone as well. Cheers, Will

Sounds like your data is just being moved around or thrown away.

Many DirectX developers used to get caught out by a similar issue where texture data would get thrown away if someone ALT+TABbed out of the game. Windows would fill the graphics card up with its own data to draw the desktop and windows, destroying the game''s data. When the game was brought back up, it would draw crap to the screen. Newbies called this a "bug"; in fact, it''s a necessary fact of life.

If the T720 does something similar, there will be an event you can check that lets your app know that it''s been interrupted. When you get this, you suspend operations and wait until the app is given the screen back. When that happens, you''ll need to reload the data. It''s strange that it affects variables too though. It could just be that your phone is fucked.

--
Sean Timarco Baggaley

pinacolada: I''m using J2ME, not BREW. If I were using C I wouldn''t use classes. lol. As it stands I have to do a lot of trickery to get a decent frame rate out of the slower phones-- this includes lots of static variables and as few classes as possible. Curious-- why did you choose BREW? I was under the impression that it wasn''t widely used.

stimarco: There is an event which I catch that lets me know the app is being interrupted. My main loop runs in a thread, which I pause when I get this notification. Maybe I''m not pausing it properly.. I''ll have to check in to it.

It is a very odd thing, and I think you''re right about the memory being shuffled around-- this would explain the data magically comming back to life.

There are some other issues as well-- we don''t have the luxury of access a screen buffer, so everything I do is a request to the Java runtime-- screen updates are unpredictable. That is to say, some areas get updated, others don''t. It has something to do with cliping regions (setClip) but that''s as much as I know.

Will