How to use actors of akka.net in MVVM?
up vote
0
down vote
favorite
It seems that it is very easy to use akka.net in a console app or in unit tests.
But I wanted to try out some actors for a simple login method: open a splash screen, send a login command, close the splash screen when login was ok. Now the answer is sent to the sender, which is an actor. Awaiting the answer of an Ask call would block the UI. The MainViewModel is already derived from a base class, so make it an actor is not an option.
public void OnStartupCommand(EventArgs args)
{
_splashScreen = new SplashScreenView();
_splashScreen.Show();
// [1]
_actorSystem.ActorSelection("/user/system").Tell(new Login("Me"));
// [2]
var mainWindowActor =_actorSystem.ActorOf(Props.Create(() => new
MainWindowActor(this)), "mainwindow");
mainWindowActor.Tell(new Login("me"));
// [3]
var result = await _actorSystem.ActorSelection("/user/system").Ask(new Login("me"));
}
- Call the responsible actor directly, answer is send to deadletters. Are there more complex examples?
- Would receive the answer and could call callbacks of the mainviewmodel, but gives me InvalidOperationException "Call from invalid thread"
- Seems to be the only way to get the result of the call
I am wondering how to fill ListViews or ComboBoxes by Actor messagings.
.net wpf xaml akka.net
add a comment |
up vote
0
down vote
favorite
It seems that it is very easy to use akka.net in a console app or in unit tests.
But I wanted to try out some actors for a simple login method: open a splash screen, send a login command, close the splash screen when login was ok. Now the answer is sent to the sender, which is an actor. Awaiting the answer of an Ask call would block the UI. The MainViewModel is already derived from a base class, so make it an actor is not an option.
public void OnStartupCommand(EventArgs args)
{
_splashScreen = new SplashScreenView();
_splashScreen.Show();
// [1]
_actorSystem.ActorSelection("/user/system").Tell(new Login("Me"));
// [2]
var mainWindowActor =_actorSystem.ActorOf(Props.Create(() => new
MainWindowActor(this)), "mainwindow");
mainWindowActor.Tell(new Login("me"));
// [3]
var result = await _actorSystem.ActorSelection("/user/system").Ask(new Login("me"));
}
- Call the responsible actor directly, answer is send to deadletters. Are there more complex examples?
- Would receive the answer and could call callbacks of the mainviewmodel, but gives me InvalidOperationException "Call from invalid thread"
- Seems to be the only way to get the result of the call
I am wondering how to fill ListViews or ComboBoxes by Actor messagings.
.net wpf xaml akka.net
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
It seems that it is very easy to use akka.net in a console app or in unit tests.
But I wanted to try out some actors for a simple login method: open a splash screen, send a login command, close the splash screen when login was ok. Now the answer is sent to the sender, which is an actor. Awaiting the answer of an Ask call would block the UI. The MainViewModel is already derived from a base class, so make it an actor is not an option.
public void OnStartupCommand(EventArgs args)
{
_splashScreen = new SplashScreenView();
_splashScreen.Show();
// [1]
_actorSystem.ActorSelection("/user/system").Tell(new Login("Me"));
// [2]
var mainWindowActor =_actorSystem.ActorOf(Props.Create(() => new
MainWindowActor(this)), "mainwindow");
mainWindowActor.Tell(new Login("me"));
// [3]
var result = await _actorSystem.ActorSelection("/user/system").Ask(new Login("me"));
}
- Call the responsible actor directly, answer is send to deadletters. Are there more complex examples?
- Would receive the answer and could call callbacks of the mainviewmodel, but gives me InvalidOperationException "Call from invalid thread"
- Seems to be the only way to get the result of the call
I am wondering how to fill ListViews or ComboBoxes by Actor messagings.
.net wpf xaml akka.net
It seems that it is very easy to use akka.net in a console app or in unit tests.
But I wanted to try out some actors for a simple login method: open a splash screen, send a login command, close the splash screen when login was ok. Now the answer is sent to the sender, which is an actor. Awaiting the answer of an Ask call would block the UI. The MainViewModel is already derived from a base class, so make it an actor is not an option.
public void OnStartupCommand(EventArgs args)
{
_splashScreen = new SplashScreenView();
_splashScreen.Show();
// [1]
_actorSystem.ActorSelection("/user/system").Tell(new Login("Me"));
// [2]
var mainWindowActor =_actorSystem.ActorOf(Props.Create(() => new
MainWindowActor(this)), "mainwindow");
mainWindowActor.Tell(new Login("me"));
// [3]
var result = await _actorSystem.ActorSelection("/user/system").Ask(new Login("me"));
}
- Call the responsible actor directly, answer is send to deadletters. Are there more complex examples?
- Would receive the answer and could call callbacks of the mainviewmodel, but gives me InvalidOperationException "Call from invalid thread"
- Seems to be the only way to get the result of the call
I am wondering how to fill ListViews or ComboBoxes by Actor messagings.
.net wpf xaml akka.net
.net wpf xaml akka.net
asked Nov 19 at 21:03
Slesa
8518
8518
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
By default most of akka actors are scheduled in background threads, therefore they cannot make direct updates on the UI (only UI/primary thread of the application is allowed to do that). If you want to spawn an actor on UI thread, you need to configure it to use SynchronizedDispatcher.
Yes, understood. The threading thing is solvable. But how would I really create an actor, which wants to, let's say, get the content of a listview? Would the Form/Widget/Whatever be an actor on its own to be able to receive the answer? Or would I use eventing to redirect the incoming data? But then it probably won't fit with the streaming stuff, would it? I am looking here for a good/best practice, you know
– Slesa
Nov 23 at 21:52
This is more design issue (not fit for StackOverflow question), but general intuition is to keep the Single Responsibility Principle. If you want to use an actor for updating UI controls, don't use it for managing i.e. business domain logic.
– Bartosz Sypytkowski
Nov 25 at 8:57
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
By default most of akka actors are scheduled in background threads, therefore they cannot make direct updates on the UI (only UI/primary thread of the application is allowed to do that). If you want to spawn an actor on UI thread, you need to configure it to use SynchronizedDispatcher.
Yes, understood. The threading thing is solvable. But how would I really create an actor, which wants to, let's say, get the content of a listview? Would the Form/Widget/Whatever be an actor on its own to be able to receive the answer? Or would I use eventing to redirect the incoming data? But then it probably won't fit with the streaming stuff, would it? I am looking here for a good/best practice, you know
– Slesa
Nov 23 at 21:52
This is more design issue (not fit for StackOverflow question), but general intuition is to keep the Single Responsibility Principle. If you want to use an actor for updating UI controls, don't use it for managing i.e. business domain logic.
– Bartosz Sypytkowski
Nov 25 at 8:57
add a comment |
up vote
0
down vote
By default most of akka actors are scheduled in background threads, therefore they cannot make direct updates on the UI (only UI/primary thread of the application is allowed to do that). If you want to spawn an actor on UI thread, you need to configure it to use SynchronizedDispatcher.
Yes, understood. The threading thing is solvable. But how would I really create an actor, which wants to, let's say, get the content of a listview? Would the Form/Widget/Whatever be an actor on its own to be able to receive the answer? Or would I use eventing to redirect the incoming data? But then it probably won't fit with the streaming stuff, would it? I am looking here for a good/best practice, you know
– Slesa
Nov 23 at 21:52
This is more design issue (not fit for StackOverflow question), but general intuition is to keep the Single Responsibility Principle. If you want to use an actor for updating UI controls, don't use it for managing i.e. business domain logic.
– Bartosz Sypytkowski
Nov 25 at 8:57
add a comment |
up vote
0
down vote
up vote
0
down vote
By default most of akka actors are scheduled in background threads, therefore they cannot make direct updates on the UI (only UI/primary thread of the application is allowed to do that). If you want to spawn an actor on UI thread, you need to configure it to use SynchronizedDispatcher.
By default most of akka actors are scheduled in background threads, therefore they cannot make direct updates on the UI (only UI/primary thread of the application is allowed to do that). If you want to spawn an actor on UI thread, you need to configure it to use SynchronizedDispatcher.
answered Nov 23 at 8:55
Bartosz Sypytkowski
4,946924
4,946924
Yes, understood. The threading thing is solvable. But how would I really create an actor, which wants to, let's say, get the content of a listview? Would the Form/Widget/Whatever be an actor on its own to be able to receive the answer? Or would I use eventing to redirect the incoming data? But then it probably won't fit with the streaming stuff, would it? I am looking here for a good/best practice, you know
– Slesa
Nov 23 at 21:52
This is more design issue (not fit for StackOverflow question), but general intuition is to keep the Single Responsibility Principle. If you want to use an actor for updating UI controls, don't use it for managing i.e. business domain logic.
– Bartosz Sypytkowski
Nov 25 at 8:57
add a comment |
Yes, understood. The threading thing is solvable. But how would I really create an actor, which wants to, let's say, get the content of a listview? Would the Form/Widget/Whatever be an actor on its own to be able to receive the answer? Or would I use eventing to redirect the incoming data? But then it probably won't fit with the streaming stuff, would it? I am looking here for a good/best practice, you know
– Slesa
Nov 23 at 21:52
This is more design issue (not fit for StackOverflow question), but general intuition is to keep the Single Responsibility Principle. If you want to use an actor for updating UI controls, don't use it for managing i.e. business domain logic.
– Bartosz Sypytkowski
Nov 25 at 8:57
Yes, understood. The threading thing is solvable. But how would I really create an actor, which wants to, let's say, get the content of a listview? Would the Form/Widget/Whatever be an actor on its own to be able to receive the answer? Or would I use eventing to redirect the incoming data? But then it probably won't fit with the streaming stuff, would it? I am looking here for a good/best practice, you know
– Slesa
Nov 23 at 21:52
Yes, understood. The threading thing is solvable. But how would I really create an actor, which wants to, let's say, get the content of a listview? Would the Form/Widget/Whatever be an actor on its own to be able to receive the answer? Or would I use eventing to redirect the incoming data? But then it probably won't fit with the streaming stuff, would it? I am looking here for a good/best practice, you know
– Slesa
Nov 23 at 21:52
This is more design issue (not fit for StackOverflow question), but general intuition is to keep the Single Responsibility Principle. If you want to use an actor for updating UI controls, don't use it for managing i.e. business domain logic.
– Bartosz Sypytkowski
Nov 25 at 8:57
This is more design issue (not fit for StackOverflow question), but general intuition is to keep the Single Responsibility Principle. If you want to use an actor for updating UI controls, don't use it for managing i.e. business domain logic.
– Bartosz Sypytkowski
Nov 25 at 8:57
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53382582%2fhow-to-use-actors-of-akka-net-in-mvvm%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown