More explicit async example

[savente93]

Hi Folks,

First of all, thanks for all the hard work. I'm just getting started with Iced, but it looks incredible!

Secondly, I am building my first GUI and am trying to use iced for it. I am trying to build my own Todo MVC for all intents and purposes but with more of a server-client architecture as a personal project. I'm hoping to separate the server and UI into separate binaries at some point, but they aren't at the moment for ease of testing. I am reasonable at rust but have never worked with async before, so this is very much from a newbie's perspective.

currently, my main function pretty much looks like this:

1. read init commands from CLI
2. setup the server struct and hand it off to a separate Tokio thread
3. run the iced application

The iced part doesn't interact with the server yet; I'm just trying to get things up and running. It builds and runs fine. However, I have two problems:

Firstly, It is not obvious to me at all how to handle other tasks in the background from this application because the documentation about Application::run says:

On native platforms, this method will take control of the current thread and will NOT return unless there is an Error during startup.
It should probably be that last thing you call in your main function.

So if it will not yield control back at all, how can my other thread do its work?

Secondly, When I try to run the application, it works okay, but once the programme exits, I get the following error:

thread 'main' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.'

I understand that the application tries to spawn its own runtime, but it's not clear to me how to set up the thread for the server part because of this?

So my question is, could there be some more documentation/examples of properly handling async setups? Async workloads and runtimes have been a very steep learning curve for me, and I suspect I'm not the only one, so some more explicit help in this region would be much appreciated. I'd love to do some of the writing. Still, obviously, I'd need some help to understand how it all works first 😅 I know this has been mentioned in #313, but since I'm asking for documentation instead of changes, I thought a separate discussion would be useful. I hope I'm not missing anything too obvious. Thanks for all your time regardless :)

[13r0ck]

Yep. I'm already working on it. Currently commands are a 10/10 fantastic experience to program with, subscriptions are not easy. I am working on simplifying the api for some common subscriptions then I will create a better example.

Basically if you want to send a message to a server, return a Command to the iced runtime

[hecrj]

The todos, pokedex, game_of_life, and download_progress showcase different kinds of async setups.

However, I agree it's not quite clear how to run long-lived tasks in the background and establish communication with the iced application. A lot of users seem to struggle with the concept of a Subscription.

I have some ideas to improve the learning curve by providing additional function helpers.

[yusdacra]

IMO ideally it would be very nice to be able to have widgets load when a Future resolves, and the widget can use that data. Something like this:

enum State<R, P> {
	Resolved(R),
	Polling(P),
}

// get_motd returns `State`
fn view(&mut self) -> Element<Message> {
	Async::new(async { server.get_motd().await })
		.on_resolve(|result| { // result is R
			let msg = match result {
				Ok(motd) => motd,
				Err(err) => format!("error when fetching motd: {}", err),
			};
			Text::new(msg).into()
		})
		.on_poll(|_poll| Text::new("Loading...")) // _poll is P
		.into()
}

(though, this does not really fit into the current architecture... it's just that doing something like this currently is very verbose)