Author
Topic: Java/ J2ME mobile orbiter (Read 123673 times)

I've been watching the forums for a while and I've seen feature requests for a mobile java orbiter appear every so often, with the occasional 'Yes, that sounds great, I'll get on it!' Does anyone know if this is in progress?

I'm a very experienced java dev, including j2me, and I'd be happy to help with the effort, or start the effort if it's dead at the mo.

I'm a bit hazy about the remote orbiter architecture, and my C/C++ is decidedly ropey, so I can start to do this if someone is willing to give me a few pointers . .

The mobile orbiter is a big project. I committed to pay an Indian developer with Symbian experience to port the mobile orbiter to Symbian series 3 and after 6 months he petered out. It was too much for him. The Pluto guys can give a lot of help in what is required and how it works.

The biggest problem is that the Orbiter is based on moving graphics across to the device. OK across a network. Lousy with bluetooth and not good over gprs.

However I'm ready to support such an effort. I bought on Nokia e50 I'll never see again for this so I'm serious about my support.

The easiest approach would be to mimick the Symbian mobile orbiter code. This basically has the orbiter running on the CORE and effectively a proxy running on the mobile device. Communication between the two is through a Bluetooth channel that effectively is just a smart socket type interface.I think the first step would be to replicate the BD library that is in the code using Java (JSR-82 support would be needed).Once that is done then the orbiter functionality that runs on the mobile device is quite simplistic and should be limited to buttons and bitmap displaying.

I started to look at it at one stage but gave up because all the mobiles I have access to did not have JSR-82 support which I would consider critical.

1audio,I didn't think that the mobile orbiter moved graphics across at runtime. I thought all the designer objects were rendered for the device and put into the .sis file. The runtime bluetooth communications seemed to be limited to COMMAND replication. I could be wrong though.

I was told that the limited memory of the cell phones required some graphics to be passed over the network. Some are cached but not all. And an Orbiter rebuild would require updated graphics to be sent to the phone. A more efficient solution would be nice for all of the Orbiters actually.

hmm, interesting. I'd kind of picked up that the symbian orbiters worked that way. Providing a java clone of the current functionality would seem to be the most logical way forward.

I was wondering though, since java (and as you say, jsr 82) capable phones range from wizz bang top of the range to quite basic low resolution devices, they might require a very low resolution UI. Do we know if this is already handled well in the symbian orbiter?

1audio, I had also wondered about the graphics, and since at least some phones will have low resolution, it might be worth having an option of a mainly text based UI, menus etc, which are very easy to throw together in j2me.

1audio, I had also wondered about the graphics, and since at least some phones will have low resolution, it might be worth having an option of a mainly text based UI, menus etc, which are very easy to throw together in j2me.

What do we think?

There is maybe something similar to what you're looking for. Cisco phone is receiveing XML files describing menus - so maybe digging into that would help. It's somekind of customized Orbiter proxy that sends xml files to phone to display GUI and I guess it contains less (or even none) graphics....

In a long term it would be proper solution to have somekind of Text Orbiter proxy, that could deal with less graphic and more text oriented devices...

There is maybe something similar to what you're looking for. Cisco phone is receiveing XML files describing menus - so maybe digging into that would help. It's somekind of customized Orbiter proxy that sends xml files to phone to display GUI and I guess it contains less (or even none) graphics....

In a long term it would be proper solution to have somekind of Text Orbiter proxy, that could deal with less graphic and more text oriented devices...

I agree, this sounds like a good model. A generic xml orbiter proxy seems a useful thing to have, as you could have it used by different remotes with no change to the proxy.

This would also have the advantage of removing or at least reducing the need for regenerating the orbiter, and would make using the device that much more feasible over a gprs link.I think it will still be preferable to transfer some graphics over the wire, but it may be possible to have a seperate graphics service running to give access to those and let the remote device request them when required.

In fact, taking that concept a bit further, if you had some kind of separate service running to serve up media to the orbiters, such as menu graphics, you could then have the xml orbiter proxy tell the device semantically what to render as an xml file, it could then runtime detect the best way (graphic/ text/ combo), then request the correctly scaled versions of the graphics from the DCE router media service, using these to construct the UI.

Something like this would give us a nice development path, create an xml orbiter proxy, create a j2me app that renders them menus as text; then add nicer graphics features in the future.

Has anyone looked at the cisco orbiter proxy code in detail? would it be easily adaptable as a generic xml proxy? I'm not very good at C++, so would anyone like the chance to make a huge contribution to lmce and join me in constructing this?

I have never looked at the Cisco orbiter stuff, but some comments on using an XML based proxy..- as a wrapper for either the DCE commands or even for presentation config it would certainly make it easy to deal with from a number of devices- It still needs to be transported reliably over either TCP or Bluetooth- The work has already been done to replicate the DCE logic using the BD library, albeit using a prorietary binary format

My suggestion would to have a look at both and see what makes sense.

I am happy to assist where I can. I used to write C++ for a living but havn't done it full time for many years, after switching to Java.

I have never looked at the Cisco orbiter stuff, but some comments on using an XML based proxy..- as a wrapper for either the DCE commands or even for presentation config it would certainly make it easy to deal with from a number of devices- It still needs to be transported reliably over either TCP or Bluetooth- The work has already been done to replicate the DCE logic using the BD library, albeit using a prorietary binary format

My suggestion would to have a look at both and see what makes sense.

I am happy to assist where I can. I used to write C++ for a living but havn't done it full time for many years, after switching to Java.

regardsDarren

Hi Darren,

as you say, there will still need to be a transport to push this over, which would logically be bluetooth for local phones/ or tcp or maybe http for a phone far away, over it's gprs link (not sure about that, never done it on a phone before . .)

The question becomes, would it be easier to create a java implementation of DCE (that goes via the bluetooth DCE layer), or create what is in effect another method of transferring DCE commands from the phone to the router.

Not sure, both have advantages and disadvantages.

I think the code needs to be explored now, see what options are available. I am up for creating something wizz bang, but my time is limited, so I'm probably going to head for the direction of least effort.