Well actually EventClient is also a zone with some things to know
In current implementation there's a timer that sends packet each X seconds to keep the connection up after setup (X needs to be < 60s). So that's quite bad for battery usage for widgets or live paper.
And if you don't do that the first packet Xbmc receive will reactivate it's internal EventServer timer but won't be threated as an actual command.
So one simple way is to send a Ping packet before the actual command to bypass this need. But the way the Xbmc Remote as implemented async commands (needed for ICS and more recent Android). Each packet send generate a new thread and due to Android internal and normal behavior of UDP there's no way to be sure the ping arrive before the actual command.
This way of acting is also problematic when sending quickly lot's of commands to assure they arrive in the correct order.
Here's a part of my implementation that correct this for my needs :
https://gist.github.com/3388636 (still need some modification for more public usage).
Just to be clear, when I told you that you should not start directly to target a reusable library it's by no mean a way to limit the arrival of Android remote but really a real advice to avoid you loosing lot's of time.
You should start by trying to write your apps to learn more and the more problems you rise the more solutions you'll find and after some times you'll start to have something.
Remember that phone dev is really different than other apps, all is about optimizations for memory cpu and battery usage, at expense of perfect code. You'll have to make lot's of compromise to achieve good apps.
I started to learn Android for Yatse Widget 9 month ago and the internals have changed multiple times and even if Yatse is made to work with any media center the Xbmc part while optimized would really make no sense for other ones.
