J2ME Modals
Author
Heyas
I was checking some things and I realised that doing modal dialogs in J2ME is a bit trickier than I thought.
for example
Main Loop:
while(true) {do game }
During the game i want to ask the user a question so
boolean bResponse = GetUserChoice;
GetUserChoice would be something that draws a modal window and then asks the user to choose its option, basically a modal window.
My problem is this: if I wait for user input I have to pause my main loop and trigger a second loop on a separate thread that will handle the drawing and management of my modal. Nothing else on the main loop will be working as its locked onto that point, waiting for that answer.
I can write this no worries but I was wondering if there was a better way of handling this.
Any thoughts?
Yours Truly
K
With J2ME, in general, you want to avoid doing things in separate threads.
What you probably want is something similar to this:
Obviously, this is just a pseudocode representation of what you might be looking for. (Note, you need to separate update & rendering [wink] )
You want to avoid any places where you are waiting for input. Additionally, in the J2ME event handlers (keyPressed, keyReleased, hideNotify/showNotify, etc.) you want to avoid doing lots of processing and other things that will potentially take a long time. What you should be doing is using those event handlers to set flags or call functions that trigger other behavior in your main loop.
What you probably want is something similar to this:
void keyPress(int key){ if(key == whatYouWant) setModal = true;}mainloop(){ while(true) { if(setModal) { update & render the modal. } }}Obviously, this is just a pseudocode representation of what you might be looking for. (Note, you need to separate update & rendering [wink] )
You want to avoid any places where you are waiting for input. Additionally, in the J2ME event handlers (keyPressed, keyReleased, hideNotify/showNotify, etc.) you want to avoid doing lots of processing and other things that will potentially take a long time. What you should be doing is using those event handlers to set flags or call functions that trigger other behavior in your main loop.
Author
Quote:Original post by trojanman
With J2ME, in general, you want to avoid doing things in separate threads.
What you probably want is something similar to this:
*** Source Snippet Removed ***
Obviously, this is just a pseudocode representation of what you might be looking for. (Note, you need to separate update & rendering [wink] )
You want to avoid any places where you are waiting for input. Additionally, in the J2ME event handlers (keyPressed, keyReleased, hideNotify/showNotify, etc.) you want to avoid doing lots of processing and other things that will potentially take a long time. What you should be doing is using those event handlers to set flags or call functions that trigger other behavior in your main loop.
hm... yeah, I follow you in all of those but my problem is when I actually want to know now what the user wants to do:
For example: a normal Are you sure?
During the game loop I pool the keystates and discover that the user just chose an action. I then want to know if the user is sure before triggering the code. If I dont have a blocking modal (stops my current processing until it returns) then i will have to set a lot of flags and states so that after the modal returns I can correctly process it.
Is that what most of you are doing? or are you using blocking modals?
All my work experience is window based programs (not games) and there we tend to use a lot modals for these situations (basic window modal dialog). Those completly block all processing of our code until the modal returns (not counting drawing and processing of the modal itself of course).
I could re implement something similar (and am planning to) but I would like more input on this.
Anymore ideas?
basically: blocking modal or saving state and then resuming it after modal done.
Yours Truly
K
Quote:Original post by BloodWarrior
Is that what most of you are doing? or are you using blocking modals?
All my work experience is window based programs (not games) and there we tend to use a lot modals for these situations (basic window modal dialog). Those completly block all processing of our code until the modal returns (not counting drawing and processing of the modal itself of course).
I could re implement something similar (and am planning to) but I would like more input on this.
Anymore ideas?
basically: blocking modal or saving state and then resuming it after modal done.
You basically described most of the modals and menu models that I've seen and implemented myself. While the blocking modal is certainly the easiest in terms of setting up a FSM and transitioning states back and forth, setting up a system that creates menus and modals while also updating and rendering whatever is going on underneath can be just as cool and useful depending on the application. Personally, for mobile, I prefer to stick to the former and create modals that are simple, easy to use, and clear in what they present. I will 'pause' whatever is going on underneath the modal and wait for the user to respond. Blocking modals are generally easier to implement and there are less side-effects.
One note, prior to most modals, I still prefer to save state and information just in case the user wants to end the application the quick way or they receive a phone call or other interrupt.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
