Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite code to utlilize async/await fully in the SensorVehicle-main app (requires async I2c library) - responsive UI #4

Open
BjAlvestad opened this issue Jun 5, 2019 · 0 comments
Labels
improvement Someting could be improved

Comments

@BjAlvestad
Copy link
Owner

There is a mix of async and synchronous code in the SensorVehicle-main application.
Async/await should be used "from bottom to top".

When the code is running on a PC (against the simulator), the implementation for IVehichleCommunication that is used is "SimulatedVehicleCommunication". This utilizes an AppService to communicate with the simulator, which only offers async methods.

When the code is running on the physical car, the implementation for IVehicleCommunication is "VehicleCommunication" which utilizes the UWP I2c library. This offers only synchronous methods. Async is not an option here.

For this reason, we have been forced to mix async and non-async code.

The way we have solved this:

Inside "SimulatedVehicleCommunication"-class:

When sending data to simulator (setting wheel speed) we send without awaiting the task.
Problem caused by this: any exceptions that occurs behind this method will be swallowed since we are not awaiting them.

When requesting data from simulator we force the method to run synchronously by adding ".GetAwaiter().GetResult();" to the async method.
Potential problem: may cause code to deadlock, however this has not occured while we have been testing the code.

Better way of fixing issue - if async I2C library can be found

If Microsoft releases an async version of the I2C library, then it would be better to rewrite all the code to async, since this would also ensure that the GUI remains responsive.
(If I2c communication fails there will be approximately a seconds delay before an exception is thrown. If the update was initiated from the GUI, this will cause a momentary UI freeze).

PS: This suggestion for fix is only relevant if an async I2c library can be found.

@BjAlvestad BjAlvestad added the improvement Someting could be improved label Jun 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Someting could be improved
Projects
None yet
Development

No branches or pull requests

1 participant