display MIDlet suite after login

[uraravind]

Hello,
May I know how to make a particular MIDlet from a midlet suite to run first when the application is run?
For eg, suppose i want to run the LOGIN MIDlet first and then i have to show the list of MIDlets in the suite.
How to do like this?
I tried, but all the MIDlets including the login MIDlet are shown in parallel.
Please help..
Thank you..

[hartti]

Not possible. You could combine all the MIDlets in the suite to be a single MIDlet - that way you get control of the flow. Would that work for you?

Hartti

[uraravind]

hi hartti,
I tried with what you've told. But its not working that way. all the MIDlets are shown at once. But that is not what i want. Help me.

Not possible. You could combine all the MIDlets in the suite to be a single MIDlet - that way you get control of the flow. Would that work for you?

Hartti

[hartti]

Maybe you misunderstood my response. What I said was that you should combine all the MIDlets in one, single MIDlet. Of course that requires you to do quite some coding as you need change the rest of the MIDlets to act as sub programs (not MIDlets, that is) for the login part and you need to ad some kind of dashboard in the login part to show the available functions and let the user start each of the functions.

This way you will have only on MIDlet in your suite. the logic of showing the various functions after the login needs to be coded by you inside that MIDlet

But as said, I do not know if this approach works for you.

Hartti

[uraravind]

NO, I understood what you were meaning.
But the thing is, as i am a beginner, i feel its like doing R&D.
Of course, i can do it. but i feel its better if i keep them all as seperate MIDlets.
If there is no other go, i'll automatically need to go in ur way.
Helps from you people are really beneficial for beginners.
Help me, if i can do it in any other simpler way.

Thanks in advance.

Maybe you misunderstood my response. What I said was that you should combine all the MIDlets in one, single MIDlet. Of course that requires you to do quite some coding as you need change the rest of the MIDlets to act as sub programs (not MIDlets, that is) for the login part and you need to ad some kind of dashboard in the login part to show the available functions and let the user start each of the functions.

This way you will have only on MIDlet in your suite. the logic of showing the various functions after the login needs to be coded by you inside that MIDlet

But as said, I do not know if this approach works for you.

Hartti

[grahamhughes]

Hartti knows what he's talking about... combining all the MIDlets into one MIDlet is the only way to get the kind of control you're asking for,

I see no benefit in keeping the separate parts of your application as separate MIDlets. It will only make your life difficult.

Graham.

[laars80]

Sorry i fI interphere in this discussion, or anyway reopen it, but I have practically the same problem, but with a little difference and I was wondering whether there might be a different solution, rather than starting a new thread.
If I have a midlet, and would like to add a login component to it, could I just create the menus and logic of the login in a separate class (not midlet, just normal class) and plug it in the existing midlet just by passing the display to this class and back to the midlet when I am finished with the login?
I tried and I can get it to work, meaning the id I pass the display object from the midlet to the login class, I can actually control the screen from the login class, but then I do not know how to give the control back to the midlet......and whether other things like record management would work)

protected void startApp() throws MIDletStateChangeException {
		display=Display.getDisplay(this);
		LoginModule log=new LoginModule(this.display);
		log.start();
               nextMenuInMidlet();? //do not know how to continue from this point when login is done....

and the login class would look like:

public class LoginModule implements CommandListener {
       Display display;
       TextBox   box;
       private Command ok=new Command("ok", Command.OK, 1);
	private Command ok2=new Command("ok2", Command.OK, 1);;
     LoginModuler(Display  d){
    	   this.display=d;
       }
       public void menuTest(){
    	box=new TextBox("Start","External menu",50,0);
   		box.addCommand(ok);
   		box.setCommandListener(this);
   		display.setCurrent(box);
       }
 public void menuTest2(){
       	box=new TextBox("Start","External menu 2",50,0);
      		box.addCommand(ok2);
      		box.setCommandListener(this);
      		display.setCurrent(box);
          }
	public void commandAction(Command arg0, Displayable arg1) {
		if (arg0.getLabel().equals("ok")) {
			menuTest2();//end();
		}
		if (arg0.getLabel().equals("ok2")) {
			menuTest();//end();
		}
	}
}

Is there any way to accomplish this?

[laars80]

Not even a hint about what I should be looking for at least? I am not really sure about how to call what I am trying to do, so I have problems looking for possible solutions elsewhere......

[raj_J2ME]

Not even a hint about what I should be looking for at least? I am not really sure about how to call what I am trying to do, so I have problems looking for possible solutions elsewhere......

No worries, Let me move ahead with point to point,

There are major two ways of drawing the GUI using the Java ME.
1.High Label API
The UI classes of of MIDP 2.0's javax.microedition.lcdui package can be divided into two logical groups: the high- and low-level groups. The classes of the high-level group are perfect for development of MIDlets that target the maximum number of devices, because these classes do not provide exact control over their display. The high-level classes are heavily abstracted to provide minimal control over their look and feel, which is left for device on which they are deployed to manage, according to its capabilities.
Classes : Alert, Form, List and Textbox.

2.Low Label API
The classes of the low-level group are perfect for MIDlets where precise control over the location and display of the UI elements is important and required. Of course, with more control comes less portability. If your MIDlet is developed using these classes, it may not be deployable on certain devices, because they require precise control over the way they look and feel.
Classes: Canvas and its subclasses.

This is the example of using the Form,
On the canvas you have to write the code by yourself.

[laars80]

Hi, thanks for the answer, but I am not sure I understand, maybe my code was misleading, I am sorry.
I know how to create a login screen and how to handle a display and so on, my problem is only wheter it is possible for a midlet to temporary hand over the control flow to another class and get it back when that class is finished.
In my case the class would be LoginModule, sorry I put some dummy code in there rather then the real login screen and authentication method, it was just to illustrate the concept.

In other words, let us assume that I have a working midlet, and one day I decide I would like to add a login screen to it and the related authentication mechanism, but I don't want to bother with the implementation details, and I found out someone created such class for me, ready to use.
Could I just plug in this class in my midlet, let it perform the necessary authentication steps and if succesful go on with my midlet?
This way anyone wanting to add a login to the application, just puts a line or two of code in their midlet giving their display object to my class (or whatever else is needed, maybe the midlet object itself), run the class et voilà! (as in the example code)

an alternative I was thinking about creating a midlet with all these login screens and logic (not just a normal class), and let your midlet extend it, so that it would inherit all the necessary classes. Would this approach be possible? I tried and I get no errors, but when
I start the midlet extending the LoginMidlet, it says that it uses no screen....in this case the code would lokk something like:

public class LoginModule extends MIDlet implements CommandListener{
......

protected void destroyApp(boolean arg0) throws MIDletStateChangeException {
           //empty, not supposed to work on its own, just to provide a ready to use implementation for another midlet
	}

protected void authenticateServerScreen(String mess) {
		Form form = new Form("Login Screen);
		userName = new TextField("UserName", "", 30, TextField.ANY);
		pass = new TextField("Password " + otcNr, "", 30, TextField.ANY);
		form.append(userName);
		form.append(pass);
		form.addCommand(authenticate);
		form.addCommand(exitCommand);
		form.setCommandListener(this);
		display.setCurrent(form);
	}

protected mainScreen(){
//user must override this screen in his midlet
}

protected loginErrorScreen(){
//some default screen that can be overriden by user
}
protected void authenticate(user,pass){
boolean isAuth=false;      
//connect to some server and authenticate       
     if(isAuth)
        mainScreen();
    else
        loginErrorScreen();
}

rest of the midlet...

And the midlet extending the LoginModule would look like:

public class SecureMidlet extends LoginModule {

	public SecureMidlet() {
		super();
	}

   protected void startApp() throws MIDletStateChangeException {
	   this.display=Display.getDisplay(this);
           loginScreen();
	}

  protected void meinScreen(){}


}

[traud]

Of course you can, however, this depends a bit on how you auth and keep your session active. If you create an auth layer in your network exchange, then you can do anything there you like: Forward without auth or HTTP auth or … For the log-in screen, just hand over to that auth object which is a subclass of Displayable. If there is no auth, that object changes the current Displayable back or to your next Displayable. Did that help?

[laars80]

Hi,
yes this might help even though I have to try it.
Right now I found a maybe more complicated solution that at least works.
I created an object that take the user midlet as parameter in the contructor, so that I have access to the current display and other methods like notifyDestroyed when creating screens with menus in my authentication object. This object creates all screens necessary for the authentication and controls the flow between them just like any midlet would (but it is not a midlet itself), then when it is finished, it simply invoke a method inside the user midlet that was passed as parameter, so that the control is back where it came from.
To achieve this I require that the use midlet extend an abstract class that alwasy must implement the method i call from inside the object performing the authentication.
Since the authentication object is created locally and instantiated inside a method of the user midlet, I assume that once it passes back control to another method in the midlet, it will be destroyed and garbage collected (hopefully).

To explain it with code:

The abstract class that the user midlet must extend:

abstract class AbsSecureClient extends MIDlet{

protected void startApp() throws MIDletStateChangeException {

	  AuthModule m=new AuthModule(this);
          m.start();

	}

abstract void userMenu();

}

Then the AuthModule class performing authentication:

public class AuthModule implements CommandListener {

  private Display display; 
  private AbsSecureClient c;

  public AuthModule(AbsSecureClient c){
     display=Display.getDisplay((MIDlet) c);
     this.c=c;
  }

  public void start(){
  / /Do the uthentication magic using as many screens and menus as you like....
  }

  public void successfulAuth(){
    //the authentication procedure is finished and well... 
   c.userMenu(); //class that user must always implement to regain control of the screen;
  }
....
}

And finally the user Mdlet using the authentication module:

public class UserMidlet extends AbsSecureClient{

public void userMenu(){
//implementation of the screen the user will get to after authentication
}
}