[android-developers] Re: Threads for networking and DatagramSocket
Thank You for your advice, Roman. There's a detailed post about my issue on the Java Sun Forum: http://forums.sun.com/thread.jspa?messageID=10779608#10779608 Lex On Jul 29, 5:06 pm, Roman roman.baumgaert...@t-mobile.com wrote: I recommend to keep your data communication separate from the UI. The UI should be responsive as possible and you don't want to have any blocking on this level. In general data connectivity is not predictable and in worse case you are waiting for a response from the network and blocking your whole UI. For example how would you interrupt your data communication from UI perspective when you handle data communication within the UI and your UI is blocked? -- Roman Baumgaertner Sr. SW Engineer-OSDC ·T· · ·Mobile· stick together The views, opinions and statements in this email are those of the author solely in their individual capacity, and do not necessarily represent those of T-Mobile USA, Inc. On Jul 29, 3:42 am,Lexhakkinen1...@gmail.com wrote: My Android app is exchanging traffic messages viaUDPwith a server - binary messages of up to 60 Bytes. The server I'm using (external, don't have access to code nor can I convince the developer to change stuff :( ) is identifying the clients solely through sockets (no other type of client ID whatsoever), so I need to use the same socket for receiving and sending. My initial plan was to use separate Threads for receiving and sending data. The network load depends on the traffic situation - sometimes there might be a lot of messages coming in, sometimes only a few. The client also needs to send periodic keep- alive messages, which are simple, 10 character strings. Now the problem is that Java's DatagramSocket.receive method() is synchronized and also blocking as long as there is data to receive, so my sending thread cannot use the socket for sending anything, which results in the server kicking off the client because there's no response coming. My question is, how bad (or not bad) do you think will rejecting the threads and doing all the networking as described above in the UI thread be? Of course, if you also have suggestions on how to overcome the issue, it will be greatly appreciated! Cordialement Lex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads for networking and DatagramSocket
Um... it looks like the people there already answered your question: only the receive() call is synchronized, so you can freely send data while your reader thread is blocked waiting for new data to arrive. I don't understand at all why you are suggesting doing networking on the main thread, since that will just make your problem worse, as now you somehow need to keep the reading from blocking so you can make the UI responsive. There is nothing magical about the main thread that lets it do networking in a way that can't be done in another thread. On Thu, Jul 30, 2009 at 6:46 AM, Lex hakkinen1...@gmail.com wrote: Thank You for your advice, Roman. There's a detailed post about my issue on the Java Sun Forum: http://forums.sun.com/thread.jspa?messageID=10779608#10779608 Lex On Jul 29, 5:06 pm, Roman roman.baumgaert...@t-mobile.com wrote: I recommend to keep your data communication separate from the UI. The UI should be responsive as possible and you don't want to have any blocking on this level. In general data connectivity is not predictable and in worse case you are waiting for a response from the network and blocking your whole UI. For example how would you interrupt your data communication from UI perspective when you handle data communication within the UI and your UI is blocked? -- Roman Baumgaertner Sr. SW Engineer-OSDC ·T· · ·Mobile· stick together The views, opinions and statements in this email are those of the author solely in their individual capacity, and do not necessarily represent those of T-Mobile USA, Inc. On Jul 29, 3:42 am,Lexhakkinen1...@gmail.com wrote: My Android app is exchanging traffic messages viaUDPwith a server - binary messages of up to 60 Bytes. The server I'm using (external, don't have access to code nor can I convince the developer to change stuff :( ) is identifying the clients solely through sockets (no other type of client ID whatsoever), so I need to use the same socket for receiving and sending. My initial plan was to use separate Threads for receiving and sending data. The network load depends on the traffic situation - sometimes there might be a lot of messages coming in, sometimes only a few. The client also needs to send periodic keep- alive messages, which are simple, 10 character strings. Now the problem is that Java's DatagramSocket.receive method() is synchronized and also blocking as long as there is data to receive, so my sending thread cannot use the socket for sending anything, which results in the server kicking off the client because there's no response coming. My question is, how bad (or not bad) do you think will rejecting the threads and doing all the networking as described above in the UI thread be? Of course, if you also have suggestions on how to overcome the issue, it will be greatly appreciated! Cordialement Lex -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads for networking and DatagramSocket
I recommend to keep your data communication separate from the UI. The UI should be responsive as possible and you don't want to have any blocking on this level. In general data connectivity is not predictable and in worse case you are waiting for a response from the network and blocking your whole UI. For example how would you interrupt your data communication from UI perspective when you handle data communication within the UI and your UI is blocked? -- Roman Baumgaertner Sr. SW Engineer-OSDC ·T· · ·Mobile· stick together The views, opinions and statements in this email are those of the author solely in their individual capacity, and do not necessarily represent those of T-Mobile USA, Inc. On Jul 29, 3:42 am, Lex hakkinen1...@gmail.com wrote: My Android app is exchanging traffic messages via UDP with a server - binary messages of up to 60 Bytes. The server I'm using (external, don't have access to code nor can I convince the developer to change stuff :( ) is identifying the clients solely through sockets (no other type of client ID whatsoever), so I need to use the same socket for receiving and sending. My initial plan was to use separate Threads for receiving and sending data. The network load depends on the traffic situation - sometimes there might be a lot of messages coming in, sometimes only a few. The client also needs to send periodic keep- alive messages, which are simple, 10 character strings. Now the problem is that Java's DatagramSocket.receive method() is synchronized and also blocking as long as there is data to receive, so my sending thread cannot use the socket for sending anything, which results in the server kicking off the client because there's no response coming. My question is, how bad (or not bad) do you think will rejecting the threads and doing all the networking as described above in the UI thread be? Of course, if you also have suggestions on how to overcome the issue, it will be greatly appreciated! Cordialement Lex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
