2012-02-15, 12:26
Well the event server is an UDP receiver, we just send command without acknowledge or all that TCP adds. So it's very fast but we can't get any information from that service and no result about send commands.
The Json part is more elaborated and can be used over raw TCP or via HTTP that adds a little overhead but simplify coding :p
The way the Json Api works for remote controls we need to first get the active player then send command to the active player via an ID.
This with announcement that the Json part can send about starting or stopping media is not so bad for full apps that are launched and can listen announcements all the time.
The problem is that since i use a widget that works all the time, i need to be conservative with the battery so i do stop all when phone screen is off for example.
Since i'd have to open a server , tell xbmc to get annoucement, do a check for current state and then start to behave like a full app, this would have make a lot's of cpu and things to do that would slow down the app on phone wake up. Even more problematic if you just shut the screen 2 sec later
.
And it worst when responding to call event, since i register the event, i must act very very quickly for the system to continue the normal call action like start ringing (since this event can be used by app to do filtering and stop ringin). So i can't take time to get Xbmc status before acting. Since getting the status if Xbmc is not available can take up to 2,5 sec (The actual timeout).
Hope it's more clear now
The Json part is more elaborated and can be used over raw TCP or via HTTP that adds a little overhead but simplify coding :p
The way the Json Api works for remote controls we need to first get the active player then send command to the active player via an ID.
This with announcement that the Json part can send about starting or stopping media is not so bad for full apps that are launched and can listen announcements all the time.
The problem is that since i use a widget that works all the time, i need to be conservative with the battery so i do stop all when phone screen is off for example.
Since i'd have to open a server , tell xbmc to get annoucement, do a check for current state and then start to behave like a full app, this would have make a lot's of cpu and things to do that would slow down the app on phone wake up. Even more problematic if you just shut the screen 2 sec later
.And it worst when responding to call event, since i register the event, i must act very very quickly for the system to continue the normal call action like start ringing (since this event can be used by app to do filtering and stop ringin). So i can't take time to get Xbmc status before acting. Since getting the status if Xbmc is not available can take up to 2,5 sec (The actual timeout).
Hope it's more clear now
