It has been a long time and if you look closely, the pattern becomes apparent. The frequency of posts depends on the variable 'isFinalsWeek:Boolean'. If true then you might see a load of new snippets. A lot of things have changed since my last post. I refactored the whole Grid code, with better TCP server akka actors implementation(put it in a trait/interface, nothing much), and also an observable which can monitor any changes to a variable. The first part of this post talked about using an actor inside an observable so that the actor remains in the observable's scope and is able to push whatever it wants to. Flawed, utterly flawed. I limited my test run to a single listener(one which subscribes to receive notifications about an event), and that was my mistake. What seems to happen is that, the actor class inside the observable binds only to the most recent subscription and that makes my code explode. No matter how many listeners are there, only one of them would be able to listen and react. This is the biggest flaw in my previous implementation.
How I overcame it is a fairly simple question to answer. I zeroed in on the fact that my only requirement is to check for a change in my input buffer(or a variable which stores the incoming message). And my refactoring came to the rescue. My ChatServer.scala replaced Chat.scala and became an actor. I added an observable to check for any change in the input data(inData). The last thing to cover is to subscribe to the observable. Since it is inside an actor class and hence inaccessible, I must send my event handle functions(something which should be called if a listener gets a notification) to the actor and it will then create a subscription corresponding to the function.
Nothing explains better than code. Providing you another sneek peek into our framework.
TLDR; I have an actor which hosts a TCP server and receives messages. This is my implementation of invoking a function whenever a text is received.
No comments:
Post a Comment