On 4/4/2011 11:18 AM, Dirk Bruere at NeoPax wrote:
Or not.
That BlinkAPI.updateIncomingData(packetStr) eventually gets to call this
from the Data class
public static void setRadioTitleAdapterListView()
{
I don't like the idea that you're suggesting here. Hard baking this
method so it always runs on the UI thread sounds bad. You want to keep
methods flexible so they can be used in a variety of contexts. Too much
specialized behavior results in classes that require too many support
classes or a specialized environment to function at all.
Better to do it where you had it at first. You're already processing the
packet and making a string. It seems fine to allow your Blink routine to
process the resulting string on the UI thread. You don't have to be
manic about removing every last cycle from the UI thread, just keep long
tasks (like IO, or sorting or searching) away from it.
Also, in the code you posted, you set up packetStr once outside of the
loop, then never use that value, so I'm moving packetStr inside the loop
and removing the unused assignment.
And I think you mean !packetStr.equals( "" ), not packetStr != null. It
isn't possible to get null from a constructor.
public void run()
{
try
{
DatagramSocket ds = new DatagramSocket(Constants.LOCAL_PORT);
DatagramPacket incoming = new DatagramPacket(
receiveBuffer, receiveBuffer.length);
incoming.setLength(length);
// not used String packetStr=new String(receiveBuffer, "UTF-8");
while(true) //Run this as an endless loop
{
ds.setReceiveBufferSize(receiveBuffer.length);
ds.receive(incoming);
final String packetStr = new String(receiveBuffer, 0,
incoming.getLength(), "UTF-8");
if( !packetStr.equals( "" ) ) {
Activity.runOnUiThread( new Runnable() {
public void run() {
BlinkAPI.updateIncomingData(packetStr);
}
} );
}
} catch (IOException e1) {
// you really must log errors if you find them
// honestly, you'll be happy you did.
}
}
}
At least we're doing things now that look like actual Java programming.