On 14/05/15 16:46, Daniel Martí wrote:
On Thu, May 14, 2015 at 11:55:29 +0100, Michael Rogers wrote:
Sorry if my comments yesterday came across as blunt - it was a long day. :-)
No problem. It was me who was asking for help.
Thanks man!
Yup, waiting on a background thread is the important
On Mon, May 18, 2015 at 22:43:00 +0100, Michael Rogers wrote:
Yup, I had a similar thought about adding a no more results method to
the interface. It's something I missed in the Bluetooth LE API when
playing with it recently.
In the last few days I went with this implementation, works just
On Thu, May 14, 2015 at 11:55:29 +0100, Michael Rogers wrote:
Sorry if my comments yesterday came across as blunt - it was a long day. :-)
No problem. It was me who was asking for help.
Yup, waiting on a background thread is the important part. I agree that
futures work just as well as a
Hi Daniel,
Sorry if my comments yesterday came across as blunt - it was a long day. :-)
On 13/05/15 15:00, Daniel Martí wrote:
On Wed, May 13, 2015 at 12:25:25 +0100, Michael Rogers wrote:
A few quick comments:
1. You're calling a blocking method from the UI thread. Don't do that.
Instead,
A few quick comments:
1. You're calling a blocking method from the UI thread. Don't do that.
Instead, call the blocking method on a background thread and post the
results back to the UI thread when it returns. That's how the code I
posted yesterday works. If you want to collect all the results
On Wed, May 13, 2015 at 12:25:25 +0100, Michael Rogers wrote:
A few quick comments:
1. You're calling a blocking method from the UI thread. Don't do that.
Instead, call the blocking method on a background thread and post the
results back to the UI thread when it returns. That's how the code
You could use a CountDownLatch to manage the counter, but I'd probably
do something like this instead:
public void getReachableClients(final ReachableClientListener listener,
final int timeout) {
ListClient clients = getClients();
if(clients == null) return;
Executor executor
This looks promising, thank you Michael! Will test it out :)
On Tue, May 12, 2015 at 20:45:47 +0100, Michael Rogers wrote:
You could use a CountDownLatch to manage the counter, but I'd probably
do something like this instead:
public void getReachableClients(final ReachableClientListener
I haven't done much fancy concurrency, but one idea that came to mind is this:
* have a counter for instances of your probe thread
* have `synchronized` increment/decrement methods
* as each thread starts, it increments the counter
* as each thread finishes, it decrements the counter
*
Daniel Martí:
I haven't done much fancy concurrency, but one idea that came to mind is
this:
* have a counter for instances of your probe thread
* have `synchronized` increment/decrement methods
* as each thread starts, it increments the counter
* as each thread finishes, it decrements
and the diff:
diff --git
a/libaccesspoint/src/main/java/cc/mvdan/libaccesspoint/WifiApControl.java
b/libaccesspoint/src/main/java/cc/mvdan/libaccesspoint/WifiApControl.java
index ca3c0fe..95d09db 100644
---
a/libaccesspoint/src/main/java/cc/mvdan/libaccesspoint/WifiApControl.java
+++
11 matches
Mail list logo
