2014-04-28, 18:18
Afternoon all,
I've got a need for a bluetooth Android remote connection for an in-car system - I'd rather keep my Android handset on it's GPRS data connection and connect to XBMC via bluetooth if at all possible.I started looking at the options, development-wise, and I noticed that some kind soul patched in a BT transport for the JSONRPC layer a while ago now, but I can't find a remote that's done anything with it (though I'd be thrilled to be wrong).
So - I started a proof of concept hack, and I've got a rough outline of a working implementation - It's a little hard-coded, hacky and unstable right now, but I know why and where things need to change... It's certainly good enough to satisfy me that such things should be possible.
So far, I've created a new org.xbmc.jsonrpc.Transport interface, and a new org.xbmc.jsonrpc.HTTPTransport class that implements it. I've then shifted all the HTTP specifc stuff from org.xbmc.jsonrpc.Connection out into the new HTTPTransport. Most stuff seems to work at this stage (there's a little unpleasantness about some thumbnails downloads, but only cos I've not sorted it out yet). I then added a new org.xbmc.jsonrpc.BTTransport which is the truly hacky bit, and hardcoded the Connection class to use that instead (regardless of the host setting). Using this, I can connect to my laptops XBMC instance, get lists of content, most thumbnails, start content playing, etc. It's quite unstable and exception-y at the moment, but that's largely cos I've not been through and cleaned up yet. It also doesn't seem entirely happy that it can't connect to the EventServer at the moment, although that might just be my setup.
Some questions, then:
1 - Nothing else does this yet, right? If it does, I'll give up now
2 - Any objections to me doing this? I've been approaching it as a personal interest project so far, really, but I don't want to get in anyone's way or annoy anyone who's working on a similar feature right now.
3 - Does the above plan sound reasonable? It seemed to be a good place to put the abstraction layer, but I'm open to suggestions.
4 - I guess this pattern could be extended to cope with the TCP socket version of the JSONRPC interface - does anyone see any value in that? I'm not sure it would buy you anything that you can't get easily from the HTTP transport edition.
5 - Any further comments, suggestions, queries or open abuse?
Thanks in advance,
Pete
I've got a need for a bluetooth Android remote connection for an in-car system - I'd rather keep my Android handset on it's GPRS data connection and connect to XBMC via bluetooth if at all possible.I started looking at the options, development-wise, and I noticed that some kind soul patched in a BT transport for the JSONRPC layer a while ago now, but I can't find a remote that's done anything with it (though I'd be thrilled to be wrong).
So - I started a proof of concept hack, and I've got a rough outline of a working implementation - It's a little hard-coded, hacky and unstable right now, but I know why and where things need to change... It's certainly good enough to satisfy me that such things should be possible.
So far, I've created a new org.xbmc.jsonrpc.Transport interface, and a new org.xbmc.jsonrpc.HTTPTransport class that implements it. I've then shifted all the HTTP specifc stuff from org.xbmc.jsonrpc.Connection out into the new HTTPTransport. Most stuff seems to work at this stage (there's a little unpleasantness about some thumbnails downloads, but only cos I've not sorted it out yet). I then added a new org.xbmc.jsonrpc.BTTransport which is the truly hacky bit, and hardcoded the Connection class to use that instead (regardless of the host setting). Using this, I can connect to my laptops XBMC instance, get lists of content, most thumbnails, start content playing, etc. It's quite unstable and exception-y at the moment, but that's largely cos I've not been through and cleaned up yet. It also doesn't seem entirely happy that it can't connect to the EventServer at the moment, although that might just be my setup.
Some questions, then:
1 - Nothing else does this yet, right? If it does, I'll give up now
2 - Any objections to me doing this? I've been approaching it as a personal interest project so far, really, but I don't want to get in anyone's way or annoy anyone who's working on a similar feature right now.
3 - Does the above plan sound reasonable? It seemed to be a good place to put the abstraction layer, but I'm open to suggestions.
4 - I guess this pattern could be extended to cope with the TCP socket version of the JSONRPC interface - does anyone see any value in that? I'm not sure it would buy you anything that you can't get easily from the HTTP transport edition.
5 - Any further comments, suggestions, queries or open abuse?
Thanks in advance,
Pete
