09-02-2010 08:17 AM
you have a class that needs to be notified. you pass this class to your thread, and call a method of the class, like resultAvailable, where you process the result.
to make it a bit prettier (and encapsulate) you let the class implement an interface that publishs the resultAvailable method.
take care with ui access, the resultAvailable method runs in the thread and you need invokelater/eventlocksync to access the ui.
09-02-2010 08:28 AM - edited 09-02-2010 08:30 AM
I don't think there is a general one size fits all answer this question.
There are at least two questions you need to ask, the answer to which will change the way you do this processing:
1) Does the main routine need to 'wait' for an answer, or can it exist in a 2question asked but not answered" state?
In other words, do you want the main routine to have three 'states'
a) Not asked
b) Asked but haven't had an answer yet
or just two states:
a) Not asked
B) Is your "main" processing a Ui?
The observer pattern is perfect when you can have three states, and useful when you are running a Ui. So I would review it to have it in your kit bag.
The java constructs wait and notify are also very useful, and in fact essential for the synchronization of background processing. But they don't play well with Ui processing. Neither do wait loops.
If you could answer the two questions for this case, then perhaps we can give you better guidance as to how to handle this processing.
09-02-2010 08:45 AM
The "main" routin, wich is not the GUI, rather a sort of general "action module" that takes orders from the GUI and performs various tasks.
It also handles event coming from the phonelistener. Bot these types of requests comes via Global Events
1, It never needs to "wait" for an answer, Or rather, I definitely do not want it to wait for an answer since there may be other requests coming in.
Since I need it to be "responsive" I have taken out routines that does "sleep" and made them into threads instead.
So a reply that I expect from this new thread would just trigger some new action. The action module never "waits for a reply". So it has 2 states.
1: "Doing nothing" Its a neverending background task.
2: Performig some action. All of them coming via Global events (so far)
09-02-2010 09:35 AM
So one option would be for your Thread to fire a Global Event?
Because of the overhead of this and the fact that all GlobalEvent listeners will see this, then I think I would short circuit the process, by finding your listener (say RuntimeStore) and invoking it directly. That will save you creating another method of interprocess communication.
Your Thread invokes this when it has finished.
Does this work?
09-02-2010 09:49 AM
>So one option would be for your Thread to fire a Global Event?
>by finding your listener (say RuntimeStore) and invoking it directly.
What exactly do you mean by that? I looked at runtimeStore in the API and I do not see any listener there?
I agree in principle that its a good thing to reduce the number o parties that listen
Please elaborate (Like "Seven of Nine" in Startrek says when the doctor makes a pass at her, but that is without the "Please") :-)