I am currently trying to migrate a software and i encountered the following problems. In the current implementation, the graphical user interface makes use of a simple swing application.
Inside that class a special actor is created to listen to messages from other actors elsewhere.
Following is a small snippet of the codebase:
class App extends SimpleSwingApplication {
val actor = new Actor with Publisher {
override val scheduler = new SchedulerAdapter {
def execute(fun: => Unit) { Swing.onEDT(fun) }
}
def act() {
loop {
react {
case EXIT => exit
case msg: Event =>
println("Publishing This Msg: " + msg)
publish(msg)
case msg => println("Unknown Msg in GM: " + msg)
}
}
}
}
App.actor = actor
App.pub = actor
As you can see this actor extends the publisher trait which is used to capture reactions
from the user such as the selection of a menu item. The following snipet illustrates this:
listenTo(actor)
reactions += {
case st:State =>
playMenuItem.enabled = st match {case _:App.Playing => false; case _ => true}
stopMenuItem.enabled = st match {case App.Stopped => false; case _ => true}
}
Now the actual problem is how can i possibly migrate this to follow the akka-actor style. To my understanding the use of the publisher trait should be eliminated as it is a reactor itself and be replaced by messages.
(Note: this group is mainly for the Scala language per se – there’s a separate forum for Akka, and you might want to ask over there. But while you’re here…)
It’s not strictly clear, honestly. If the factoring with Publisher makes sense for the application, you can keep that, but you’ll have to go to a little extra work to use it.
An Akka Actor can only have one receive method, but that’s just a partial function, and you can basically combine two partial functions together (using the orElse method), to get a single partial function that handles all of the cases from both. So you could define a partial function (of type Receive) in Publisher, which handles the State message, and then in your Actor you define receive as the combination of the one from Publisher, plus another one that defines the higher-level messages like EXIT and Event.
The syntax details are a bit different, since you need to combine them into a single partial function. But conceptually, you could keep a pretty similar structure if that’s appropriate for the program…
First of all thank you very much for your answer and the tip-note. I already created a new topic over Akka’s forum. Since i’m here as well, let me see if i understood that correctly.
The Publisher trait is actually a reactor itself, so doesn’t this mean that in newer versions of scala, this should be eliminated and replaced by akka?
Furthermore in this class as is, a new actor is created to handle all these messages from other threads. How do i achieve the same functionality in akka? Do i need to make the whole App class extend akka actor, or is there a way to create an actor inside but still be able to reference and send messages to it from another class?
No, sorry – it absolutely has to be rewritten from scratch: Akka isn’t at all compatible with old-style Scala Actors. (The old Scala Actor library has been completely dead for many years – I last used it back in 2009.) I just meant to say that you could keep this pattern, of a Publisher trait that is inherited by your actual Actor, if that was appropriate.
That’s a big question, and honestly, I’d recommend reading one of the Akka books, or at least reading through the online docs. (Which are pretty good, and up-to-date.)
The very quick summary (but this is just the tip of the iceberg) is:
Your App creates an ActorSystem.
You use the ActorSystem to create one or more top-level Actors.
Those Actors can create child Actors under them, if needed.
When you create an Actor, that gives you an ActorRef, which is the “address” of that Actor.
You use the tell() method (which is usually aliased to !) on an ActorRef to send a message to that Actor.
You can use the ask() method (which is usually aliased to ?), which is an extension method for ActorRef, to send a message to an Actor and get a Future that will resolve to the response to that message.
Finally, note that Akka is in the process of a major migration right now: the new Akka Typed system, which provides a good deal more type-safety but works rather differently, is gradually supplanting “classic” Akka. So if you need to move to Akka at this point, I’d probably recommend learning Akka Typed. (The above notes are for classic Akka; the details are a little different in the new world, but I don’t know Akka Typed as well yet.)