Async actions

[hecrj]

Closes #28.

This PR adds first-class support for asynchronous actions (i.e. non-blocking background work) leveraging the recently stabilized futures! 🎉

A Command can be handed to the runtime for execution. As the futures comprising it finish, the produced messages will be handed back to Application::update.

The todos example has been improved to showcase this feature. Now, it automatically saves and loads its state using serde_json.

Changelog

Added

• Command<T>, which represents a batch of futures producing a result of type T.
• Application::new, which must return a (Self, Command<Message>). This allows applications to perform an async action at startup.

Changed

• Application::update now must return a Command<Message>. Command::none can be used if no async action is needed.
• Application::run is a static method now, thanks to the new Application::new method.

[daxpedda]

I see that you used ThreadPool as the executor. Would you consider making this only the default but allowing to pass a different executor with the help of futures::task::Spawn?

That way a user can implement his own executor or use libraries that support Spawn, hopefully tokio or async-std at some point.

Happy to make a PR for this if you approve.

[hecrj]

Hey @daxpedda, thanks for taking a look!

That way a user can implement his own executor or use libraries that support Spawn, hopefully tokio or async-std at some point.

What would be the use cases for this?

[hecrj]

@daxpedda I have created a new issue referencing your comment in #63. We can keep discussing things there!