Event that notify a light is discovered

[fabianoriccardi]

Event that notify a light is discovered

[roddone]

Hi,
Great idea, I will add an event "OnDeviceFound" thrown by DeviceLocator when DeviceLocator.Discover() finds a device.

[BionicCode]

@roddone @fabiuz7 Sorry, I just came across this ticket. await DeviceLocator.Discover() is definitely not synchronous. If not used in conjunction with Task.Wait() this method never executes synchronously. The fact that code seems to "wait" synchronously until completion of await DeviceLocator.Discover() is the asynchronous behavior. There only seems to be waiting time. In reality execution context is switched to the calling thread. If you are awaiting this method inside a button's event handler the calling thread is the UI thread (main thread). Until the asynchronous method ran to completion, the UI thread continues to execute ( e.g. rendering, event handling) and UI remains responsive. The truth is that events execute synchronously.

An event-driven approach is effective when developing GUI,

This may be right, although you have to realize that it is an old fashioned approach. Asynchronous execution is the modern version of event driven development. sync/await primarily targets UI context or development. The UI thread is the thread you want to keep responsive, without introducing the overhead of multithreading. So async/await is a powerful alternative to event driven development. Async/await is the preferred solution since it enables the asynchronous execution down the complete depth of the otherwise blocking operation. Events don't allow to execute truly asynchronous which is a design choice made by Microsoft. An event is the equivalent to an interrupt on hardware level. it is supposed to interrupt executing routines and therefore executes synchronously. i.e. blocking the executing thread.

There are no asynchronous events. You only cant execute the code of the handler asynchronously. But since event don't return a value by definition, they can't be awaited. They have to be void. Which means although you can execute code inside a handler using async you introduce more problems e.g. exceptions are no more thrown into to the context of the caller. This leads to fragile code which allows the application to transition into undefined states.

The decision to introduce an DeviceFound event based on the claim that an asynchronous method executes synchronously is a bad choice based on lacking understanding. I mean asynchronous and synchronous describes opposite behavior. An asynchronous method can never execute synchronously, it contradicts itself. The method Discover should rather accept a callback: public async Task<List<Device>> Discover(Action<Device>). This would solve the problem that the caller has to "wait" until the complete result was populated but omits the event driven approach in favor of asynchronous driven design.