Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
Posts: 16,997
Registered: ‎07-29-2008
My Device: Z10 LE, Z30, Passport
My Carrier: O2 Germany

Re: Java thread question

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.

----------------------------------------------------------
feel free to press the like button on the right side to thank the user that helped you.
please mark posts as solved if you found a solution.
@SimonHain on twitter
Developer
Posts: 516
Registered: ‎07-23-2010
My Device: 9900

Re: Java thread question

I agree with simon hain. Encapsulation is very important and makes code easier to read. I personally always use an interface when dealing with something like that.

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Java thread question

[ Edited ]

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

c) Answered

or just two states:

a) Not asked

b) Answered

 

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. 

 

 

Developer
Posts: 554
Registered: ‎10-31-2009
My Device: Torch 9800, Bold 9700
My Carrier: Movistar, Telenor

Re: Java thread question

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)

 

If everything seems to be under control, you're just not driving fast enough
-Mario Andretti-
Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Java thread question

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?

Highlighted
Developer
Posts: 554
Registered: ‎10-31-2009
My Device: Torch 9800, Bold 9700
My Carrier: Movistar, Telenor

Re: Java thread question

>So one option would be for your Thread to fire a Global Event?

 

Yes

 

>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")  :-)

 

 

 

 

If everything seems to be under control, you're just not driving fast enough
-Mario Andretti-