Skip to main content

Starting one Xlet from another with parameters

4 replies [Last post]
zohan29
Offline
Joined: 2009-12-20
Points: 0

Hi,

Imagine we have two Xlets and we want one of them to invoke the other, with passing parameters.

My intention was to use org.dvb.application.* classes (AppsDatabase and AppProxy).
Xlets are packaged into their own JARs, with one single BDJO descriptor. Testing in both Scenarist QC and Sony PS3 reveals that both Xlets got loaded and initialized prior to the first one being started. Then, seems like AppProxy.start(String[] args) does not have any sence, since the second Xlet already being initialized with empty arguments (both Xlet properties "dvb.caller.parameters" and "javax.tv.xlet.args").

Concerning the above, how do we implement on-demand execution of one Xlet from another with passing parameter data? I'm now looking at IxcRegistry for that.

The second question is, are IxcRegistry-bound remote objects suitable for synchronizing between Xlets via notify()/wait()?

Thank you!
Zohan

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
billf
Offline
Joined: 2004-02-13
Points: 0

Hi Zohan,

You're exactly right about AppProxy.start(String[]), and using IXC instead. I believe that the player behavior you're seeing is a player bug: I've seen players where start(String[]) works as specified, that is, via dvb.caller.parameters (if memory serves). I ran into it quite some time ago, so I fear this may be a long-standing player bug. When I ran into it, I did as you suggest, and used IXC.

Another alternative is to use the GPRs.

As to using IXC objects for synchronization via notify/wait, no, you can't do that directly. IXC gives the receiver a proxy object, not the original object itself, so if you synchronize on it, you're synchronizing on a different object. I don't know the specifics of your project, but a priori I'd suggest putting the synchronization object(s) in one xlet or the other, and building up the needed protocol through remote methods. That is, designate xlet B as the place where the synchronization happens, and when xlet A needs to do something requiring synchronization, have it call xlet B, even if it's just acquiring a lock and calling back to xlet A.

IXC is exactly like RMI in this regard.

Cheers,

Bill

zohan29
Offline
Joined: 2009-12-20
Points: 0

Bill,

Thanks a lot for your help! Meanwhile, I've examined MonitorXlet-based approach used in the HDCookBook demo disk, and found that it is quite suitable for my needs.

Besides, I've figured out that the situation above (with parallel Xlet initialization prior to the first one being started) takes place if both Xlets are autostarted (controlCode == 1 in BDJO). I hope that AppProxy.start(String[]) may have sence in the case of non-autostarted ("present") Xlets, but haven't tested that yet.

Regards,
Zohan

krramanan3
Offline
Joined: 2011-09-14
Points: 0

Hi Bill,

In the MonitorXlet based example, MenuXlet implements Xlet. I am using GRIN feamrwork and my xlet extends GrinXlet. How can I get the interXlet communication working using MonitorXlet when using GRIN framework.

You mentioned in a README file of xlets/GrinXlet that "bookmenu" project will be developed based on GRIN later. It it is done, where I can find that source code?

It will be great help if you could provide some assistance on this.

Thank you.

Regards,

Ramanan

billf
Offline
Joined: 2004-02-13
Points: 0

Hi Ramanan,

I don't remember everything needed to do IXC - I'd have to look up the API - but I guess the only sticking point to using it from GRIN is getting the XletContext instance, so you can pass it in to the IXC methods. That's made available to you via the public data member GrinXlet.xletContext.

The other GrinXlet trick is dealing with the fact that XletContext isn't available on desktop Java, and thus not in the desktop GRIN viewer app. For that reason, anything dealing with it, like the IXC part of your code, will have to live in xlet_src. If you want the build for desktop Java to still work, stub out those parts of the xlet in se_src.

With that, just use the IXC APIs normally, from some suitable thread. If you want, you can subclass GrinXlet, and intercept the xlet lifecycle methods -- there's a build property in vars.properties that lets you specify the name of your subclass.

We never did to a GRIN version of bookmenu, alas. Which README is that in? I should update it :-)

Cheers,

Bill