|
Replies:
2
-
Last Post:
May 28, 2009 7:48 AM
by: peter_budo
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
Display - Best practice
Posted:
May 28, 2009 1:14 AM
|
|
|
What is best practice in handling movement from screen to screen in midlet?
My teacher at university wasn't able to explain this to me, could be due to that he chuck whole 300+ lines in one file.
Secondly none of the books or tutorials that I read so far went on discussing this.
So here is how I do it and I would like to know if my approach is correct and if not I would like to know how to handle this correctly.
ImageHttp.java
package imageHttp;
import javax.microedition.lcdui.Display;
import javax.microedition.midlet.MIDlet;
import imageHttp.gui.MainMenu;
public class ImageHttp extends MIDlet{
public static ImageHttp instance;
private MainMenu mMenu;
public ImageHttp(){
instance = this;
}
public void startApp(){
if(mMenu == null){
mMenu = new MainMenu();
}
Display.getDisplay(this).setCurrent(mMenu);
}
public void pauseApp(){}
public void destroyApp(boolean unconditional){}
public static void quitApp(){
instance.destroyApp(true);
instance.notifyDestroyed();
instance = null;
}
}
MainMenu.java
package imageHttp.gui;
import javax.microedition.lcdui.Command;
import javax.microedition.lcdui.CommandListener;
import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.Displayable;
import javax.microedition.lcdui.List;
public class MainMenu extends List implements CommandListener{
private final Command exitCom;
public MainMenu(){
super("Image Up/Down-load", List.IMPLICIT);
exitCom = new Command("Exit",Command.EXIT,0);
addCommand(exitCom);
setCommandListener(this);
}
public void commandAction(Command c, Displayable d){
if(c == exitCom){
imageHttp.ImageHttp.quitApp();
}
else{
int index = getSelectedIndex();
Displayable dis = null;
switch(index){
case 0:
dis = new ImageUrlRequest();
break;
case 1:
dis = new ImageServletRequest();
break;
case 2:
dis = new ImageUpload();
break;
default:
break;
}
Display.getDisplay(imageHttp.ImageHttp.instance).setCurrent(dis);
}
}
}
In my opinion this better solution then sending instance of Displayable argument to next class.
|
|
|
|
|
|
|
Re: Display - Best practice
Posted:
May 28, 2009 7:06 AM
in response to: peter_budo
|
 |
Helpful |
|
|
doing all of these static calls, and memory segment changes to address remotely located variables is not only a lot of typing but also can cause performance issues on small devices.
There are dozens of possible ways to address this depending on your desires. I use my project MicroBus.dev.java.net to handle this decoupling of classes by use of messaging. On one side I have an event, which fires a message, the other an object that registers for listening to for given messages. That would be major overkill for your needs 
To help with performance/addressing issues you can add an instance variable of "private Display disp = Display.getDisplay(this);" to the ImageHttp class. Then by adding a method to change the current screen like:
public void changeScreen(Displayable _ui) { disp.setCurrent(_ui); }
Then your screen change logic goes from:
Display.getDisplay(imageHttp.ImageHttp.instance).setCurrent(disp);
to:
ImageHttp.instance.changeScreen(disp);
It's a little shorter code, but it removes the need to constantly call into the Display object, while changing the addressing to get the ImageHttp instance and then switch back to the Display Object to set the current UI.
However you will find that each screen may need to have its own commandListener which will make your app get really messy real quick. Making each screen then it's own CommandListener is going to be a better organization of logic, and here is a way that can help automate some construction logic by passing the class name and then you could have your ImageHttp pass an instance of itself to the class and not have to make a static variable of itself. This would require all screens you build have an interface, I'll call it CoreUI, and have one method: "void setUIManager(ImageHttp _mgr) ;"
Each Screen class would need to set itself as the commandListener and then implement CoreUI with an instance variable of type ImageHttp that I'll call mgr and the setUIManager implementation:
public void setUIManager(ImageHttp _mgr) { mgr =_mgr;}
Then to change the view all they need to do is call:
mgr.changeScreen("imageHttp.gui.ImageUrlRequest");
or if you had your screen classes defined in the CoreUI as constants then:
mgr.changeScreen(CoreUI.URL_REQUEST);
Then your ImageHttp class would have this changeScreen() method:
public void changeScreen(String _uiClass)
{
Displayable display = null;
try
{ display = (DIsplayable)Class.forName(_uiClass).newInstance();
disp.setCurrent(display);
((CoreUI)display).setUIManager(this);
}catch(Exception e){}
}
Then in ImageHttp's startApp() method instead of building the MainMenu class you use:
changeScreen("imageHttp.gui.MainMenu");
or if you setup the constant in CoreUI:
changeScreen(CoreUI.MAIN_MENU);
Following this style will also allow you to not have the static "instance" variable, and the quitApp() method can go from a class method to an instance method. (no more statics in your app)
|
|
|
|
|
|
|
|
|
Re: Display - Best practice
Posted:
May 28, 2009 7:48 AM
in response to: peter_budo
|
|
|
sfitzjava thank you for explanation, it was very helpful
|
|
|
|
|
java.net RSS
