Just to answer my own message here, the problem was not with spinning
off the thread per se, but with the setup where I had one object being
the command listener for most of the screens. The fact that the new
"now loading" screen has the same command listener as the previous
screen meant that the new screen redraw was getting held up in the
event queuing works somewhere, while the loading thread was off doing
its thing properly.
So to avoid this problem, make sure you have separate CommandListeners
for your new screen and old screen...
- Colin
On 2002.11.5, at 02:31 PM, Colin Mack wrote:
> Hi all,
>
> After my embarrassing little foray into jad file rules last week, I
> still have one remaining problem with the current au "mostly MIDP" app
> in progress. Again an apparently simple problem that is making me go
> batty. This is all related to MIDP as it is implemented on kddi's au
> phones.
>
> At the beginning of this little game app, there are a few menus and
> such. I decided to do these using the MIDP high level interface since
> there are a number of screens with choices to be made, etc before you
> get to the game canvas. Great. All works fine just as advertised, but
> I am having a problem with something I thought would be pretty easy.
> That is a simple "now loading" type message to show the user while the
> appli goes off and gets some data from the server. It's just a few KB
> of data, but the overall time required to get the data is long enough
> to merit some kind of message from the appli to let the user know it's
> not just lost in space, and the standard "data transfer" icons around
> the screen edge in most of these handsets are not noticeable enough to
> do this job well.
>
> So, between the screen where the user picks which type of data to
> download, and the screen where the user makes a choice based on the
> contents of the downloaded data, I wanted to just have a screen that
> says "now downloading data..." with perhaps "cancel" and "quit"
> buttons available. Sure. Easy.
>
> However, no matter how I try, I can not get the body of the screen,
> i.e. the main part that says "now loading" to be displayed. Sometimes
> you will see an oh-so-brief flash of it before you see the user choice
> screen that comes next, but usually you never even see the "now
> loading" screen at all.
>
> The basic deal is that I have separate Screen objects for all menu
> screens as members of my MIDlet class. Most screens have a selection
> list, text and or pics, and "quit" and "continue" commands for the
> buttons down at the bottom of the screen. The commandListener for all
> commands on all menu screens is set to be the main MIDlet object. In
> the commandAction() method there, I generally just register some user
> choice, then use this.display.setCurrent() to go to the next screen.
> All works fine except for the data loading thing. First I simply tried
> this (in response to "get data" command on the main menu):
> this.display.setCurrent(this.nowLoadingScreen);
> this.dataObject.getDataFromServer();
>
> The dataObject thing is a simple class DataObject that has a
> constructor, getFromServer() and storeToServer() methods, and members
> to hold data.
>
> Ok so the first try didn't work, but I wasn't really expecting it to,
> as my imode experience indicated that sending receiving data was
> likely to hog the whole machine. But on imode I was able to get around
> that with using threads creatively so I tried that here. I've tried
> making the DataObject class implement Runnable and spinning the
> loading off into a different thread. Nothing. Made that thread sleep
> immediately for a while when started, and made the main thread sleep a
> while before/after starting it -- no luck. Tried putting the
> display.setCurrent() call in a different thread. Nothing. Have tried
> pretty much every combination of spinning different parts of the
> operation off into threads, sleeping various threads, etc., all with
> no luck. (I do not even know which if any of these things actually
> happen in different threads, and will have to look into it.)
>
> Anyway, I always get the same results when trying to show the
> nowLoading screen *before* actually starting loading: the *buttons*
> down at the bottom of the screen change immediately to the "cancel"
> and "quit" buttons on the NowLoading screen. BUT, the upper part of
> the screen -- the main body where the message is, does not change
> until the data transfer is compeleted, and at that time almost
> invariably changes directly to the screen that is meant to be
> displayed after data transfer is done, with only a split second of
> showing the now loading message, if at all. The fact that the command
> buttons change at the expected time indicates to me that at least at
> the data level, the display.setCurrent() command has been registered
> at the right time (since the cancel button only appears on this
> screen), but for some reason the main screen update is held off until
> the data transfer finishes, even if I use thread.sleeps to delay the
> actual start of data transfer to 10 seconds after the time the
> display.setCurrent() command is registered.
>
> Can anyone give me any info on how I can get around this problem, or
> at least info on how the whole screen update timing mechanism works
> with the high level MIDP GUI API's on au phones? The whole display
> update thing seems to be waiting for something before drawing the new
> screen, but I can't figure out what. Aaaarrrrrgghghghh!!!!
>
> TIA,
>
> Colin
>
Received on Thu Nov 7 13:55:51 2002