How to open one midlet from other midlet??

HI ...

I want to start one midlet from my already runing midlet... is that possible?
How?

Thanks.

If they are in the same MIDlet suite

Hi giz155,

Jason Glass is right. However, if they're in different jars maybe you can use the solution/workaround discussed in the thread below, it is somehow related to what you'd like to do.

[url]http://discussion.forum.nokia.com/forum/showthread.php?t=76059[/url]

BR

Hi juarezjunior, Jason Glass..

both midlets are in same suit...can you plz explain me in detail how the call from first midlet to second midlet can be made?


Thanks.

You can't really call one MIDlet from another MIDlet. What you can do is redesign your app so you don't have to.

This means you move all of the functionality of the app out of the MIDlet subclasses so that all they do is start a main class that does all the actual work. Then you will be able to call this main class from anywhere in any MIDlet in your suite.

shmoove

smooth move shmoove,

guess i was wrong, but I had thought I had done it before, maybe i was using a CLDC library (RIM) that was calling another midlet/midlets. I believe that was what I was doing.

But are you sure there is no way such as using Class.forName()? Sun says you can do it, but of, course, does not provide an example, and their is not cra%p online with regards to

My code gets past the Class.forName, but does nothing, i.e. does not get display, no error is thrown, but when i uncomment the get instance method, it barfs on the init method withing Midlet B with a security exception

[COLOR=Green]Thread aThread = new Thread()
{
public void run()
{

try
{
Class c = Class.forName("test.MIDlet_B");
//MIDlet m = (MIDlet) c.newInstance();
//MIDlet_B m = (MIDlet_B) c.newInstance();
}
catch(Exception e)
{
form.append("Couldnt launch MIDlet 'B'");
System.out.println("Couldnt launch MIDlet 'B'");
System.out.println(e.getMessage());
e.printStackTrace();
}
}
};
aThread.start();[/COLOR]

Sincerely,

Hi,

The MIDlets are in the same suite so you can register an alarm and wake up the other MIDlet in case you're using MIDP 2.0.

Use

[B]public static long registerAlarm(String midlet,
long time)
throws ClassNotFoundException,
ConnectionNotFoundException[/B]

from PushRegistry.

Take a look at this article for more:

The MIDP 2.0 Push Registry
[url]http://developers.sun.com/techtopics/mobility/midp/articles/pushreg/[/url]

BR

I didnt want to do it from PUSH reg, I was trying to do it another way, I.e. the way that was described, but yes juarez is correct, that is probably the fastest and only implementation possible

See this is was confuses me, and I swear I had it running at one point:
From Sun:
[COLOR=DarkGreen]"For security reasons, it is assumed that MIDlets within a MIDletSuite are packaged together for a reason and should be able to interoperate. What's implied here is that the MIDlets share a name space; in other words, each MIDlet in the MidletSuite can "see" one another. Because they can see one another, they can launch one another ([B]Class.forName[/B] metaphor).

In contrast, one MIDletSuite cannot launch another MIDletSuite. That's because they do not share name spaces. Since the CLDC+MIDP does not have a security manager (too big and complex for small devices), the MIDP expert group felt it more prudent to limit the interaction of downloaded applications to those that are packaged together by the provider."[/COLOR]

If MIDlets are in the same Suite then you can "reach" them. That means you can create an instance of the other MIDlet subclasses. In theory you can do this and call their startApp() method. But you aren't really starting the other MIDlet in the formal way. The JAM still considers the original MIDlet as the one that is running. So, for example, any systems events will still reach the original MIDlet and not the new one.

What I usually do is make my MIDlet subclasses just an "application-lifetime-skeleton". They don't have any of the actual functionality which is usually in one or more main classes. That way you don't actually have to start any new MIDlets, just load and initiate one of the other main classes.

shmoove

I got you, I think our code is setup that way now, we are just not activating or "launching" any of the subclassed midlets as we have no need, yet.

Sorry guys, my task is changed with, now two midlets are not in the suite ...they r in different jars. now what to do?

Thanks

depends if the class path of both is the same or not, if different, i.e

Midlet A = com.you.common

Midlet B = com.me.common

you might be in trouble, but if in same, i.e.
Midlet A = com.we.common
Midlet B = com.we.common

your still good, or should be

also, if in separate classpaths, you could do the PUSH regsitry thing, as juarezjunior pointed out.

both r in same class path

if both r in same class path still I will need topush registry????

[QUOTE=shmoove]If MIDlets are in the same Suite then you can "reach" them. That means you can create an instance of the other MIDlet subclasses. In theory you can do this and call their startApp() method. But you aren't really starting the other MIDlet in the formal way. The JAM still considers the original MIDlet as the one that is running. So, for example, any systems events will still reach the original MIDlet and not the new one.

What I usually do is make my MIDlet subclasses just an "application-lifetime-skeleton". They don't have any of the actual functionality which is usually in one or more main classes. That way you don't actually have to start any new MIDlets, just load and initiate one of the other main classes.

shmoove[/QUOTE]

giz155, shmoove detailed this plan for you