In my BlackBerry app, the Locator.geocode(...) request is inside a Thread but it still blocks the UI in OS 5 devices. In OS 6 and 7 devices it works fine. The UI is not blocked.
From the moment Locator.geocode(...) is called till it finishes the UI is blocked and user can't interact with the application.
I guess this is a OS 5 issue. Is there a solution for this?
Update: First of all, thanks for quick replies.
I replaced Locator.geocode(...) call for Thread.sleep(...). The UI gets slowed down but not blocked. The simulator I'm using is 9300.
The Locator.geocode(...) request is inside a try..catch() block and it throws no Exceptions. After the call finishes it returns null (I'm using simulator) but no exception are being thrown.
For your information, this is what the console prints: (Using 9300 simulator)
**** Number of threads before creating Geocode class: 4
**** Number of threads inside Geocode class just before calling Locator.geocode: 5
**** Running on event thread: false
Locator.geocode(...) // UI blocks at this point(OS 5) till this
request finishes
Are you sure you have it running on a thread properly? It may be that OS 6+ is just responding faster, so you only notice the problem on OS 5. Try replacing the call to Locator.geocode() with a call to Thread.sleep(60000) to make sure the background thread is working properly.
From the Locator documentation:
*Requests for geocode information are synchronous, but can be interrupted by invoking cancel(). An application can use the Locator class to make only one request at a time. Making more than one request results in a MapServiceException. *
So thats one thing to check in your code. Make sure you don't make multiple request. Another possible problem:
If the LBS Map API is not installed on a BlackBerry device, requests for geocode information will throw a MapServiceException.
In both cases, an exception being thrown in a thread will terminate that thread, but this wont affect other threads like the event thread. So, without reading the code, I'd say your problem is not related to locator. It will be really helpful if you pasted some code or an exception trace.
Related
My lead developer chatted with me about an issue we are running into with Flutter. We are building a mobile app and now we have hit a potential issue regarding threading. He said that Flutter by design is normally single thread. He thinks he can get more than one thread to work, but he can't wrap his head around how to get the threads to communicate with each other.
What we need is true background processing where something can be totally handed off to a separate thread to function then no matter where the app is at something can receive a notification from that thread to be able to correctly refresh the UI state.
A simplified example of this is:
User uploads an image
Image gets processed in a different thread
Badge shows up saying something like "image is processing"
Image processing thread gets completed
Badge goes away
The badge / UI thread would have to be send something from the image processing thread in this example. How could we tackle this with Flutter?
You can use isolates with send port and receive port to communicate between the Ui thread and the isolate.
Flutter Isolate Example
Here is a greater plugin to help you use plugins in an isolate flutter_isolate: ^2.0.0
I'm developing an application to track online Xbox Live, PSN, and Steam friends. The application performs a series of QNetworkRequests using a QNetworkAccessManager. The Xbox Live and PSN code use a QWebView to simulate a browser environment. The requests are performed correctly, but it slows down the main GUI thread until each request is finished.
Here's some example code:
void Steam::fetchFriends(QString username)
{
QNetworkRequest userXml("http://steamcommunity.com/id/" + username + "/friends/?xml=1");
m_nam->get(userXml);
}
I've created a signal to tell the GUI that friends have been downloaded and processed. Then the friends list is updated in the GUI. Some of my other code is more complex and it's possible that I need to move the processing code to another thread.
Can someone confirm that QNetworkAccessManager and QNetworkRequest are multithreaded or if they should be moved into separate threads?
QNetworkAccessManager is not threaded in its implementation. It is asynchronous and uses the event loop.
Those who claim they have needed to use it in a threaded state for performance reasons have noted that they need to create the instance specifically in the thread, and not try and move it to a thread. Here is a link to someone posting an example of such.
Before creating it in a separate thread, be sure first that you aren't doing any blocking operations that might cause the main thread to slow down.
when I test my app in cocoa I can read some "[Switching to process XXXX thread 0xXXXX]" that I'm not understanding...
When app creates a thread?
For example, when I mouseover some main menu items, I get [Switching to process XXXX thread 0xXXXX]
Why?
Apple can reject my application of app store for this reason?
Thx!
It's neither an error, nor a problem. It's a normal part of an application running in the debugger.
Do the menu items have a custom image, or use any animation effects?
The messages in the debugger are only showing that the application has switched to another thread to handle the processing and unless I am missing something, I don't think there is any need to worry about them.
Our app, which has been in the app store for a few months uses images and animation on certain sections and gets process switching notifications in the debugger and has never been rejected for that fact.
I haven't used threading in my program before. But there is a problem I am having with this 3rd party application.
It is an offsite backup solution and it has a server and many clients. We have an admin console to manage all the clients and that is where there is a problem.
If one of the client side application gets stuck, or is running in a broken condition, the admin console waits forever to get a response and does not display anything.
$for(client= client1; client < last_client; client++){
if (getOServConnection(client, &socHandler)!=NULL) { .. }
}
I want two solutions to this. I want to know if there is anyway, I can set a timeout for the function getOServConnection, so that I get a response within X seconds.
And, I want to know how to call this function in parallel for all clients, so that I get the response from all clients within X seconds.
the getOServConnection contains a WSAConnect call, and I don't want to use any options on the socket, since it is used by other modules and it will affect the application severely.
First.. If you move the call that hangs into a separate thread you can use the main thread for starting a timer an waiting for the timeout. If you are using Visual C++ and if you are in Win32 you can use the (rather old) MFC based timer. Once this timer expires it will launch a function call OnTimer. This timer does not affect your application's main thread as it works in a different system based thread.
Second.. If you need to start any number of threads with that connection you should start thinking of a design pattern to use for that. You could use a fixed number of threads, and in that case you may want to use a object pool. Or if the number of threads is (relatively) limitless you may want to use a factory method
How do you handle update refresh rate from your worker function to your UI ?
Sending everything to the UI or maybe using a timer (from which side ? worker or UI ?)
In Windows apps, you generally want to use a Timer object in your GUI thread to poll for worker status -- it's easier, unless you have a really good reason to do something else...
You can't just make a function call to a UI routine from a worker thread in Windows. Undefined behavior will result, so watch out!
If your platform and development environment supports it some sort of asynchronis messaging system works well. Under Win32 I just use normal windows messages which I "post" (so they don't block the thread) and the standard main message thread of the UI picks up the messages and processes them. I usually define custom messages as well.
Using Timers is suboptimal, there should be no need to "poll" this sort of information.