The issue occours after ca. 2 minutes passed (about 1800 times updated). TextViews simply stop to update with no reason, even if accelerometer updates are still working. Our team is working on multithreaded aplication where we have to update some UI control values on UI thread (thats problably the reason why the issue occours). We have spent amount of time trying to figure out what might be the problem and finally we have decited to report it as an issue. I have prepared some sample code based on accelerometer functionality, but in fact the same problem occours when we are trying to use other hadrware devices or sensors (e.g. bluetooth). Here is the link to the sample app repository:
https://mvvmlightbug.visualstudio.com/DefaultCollection/_git/MVVM%20Light%20bug#path=%2F&version=GBmaster&_a=contents
During debug process I've found out that Garbage Collector is somehow removing my bindings. It was because of WeakReference usage in MVVMLight for Android library. I've lust replaced all WeakReferences with object types and since then there is no more problem.
For MVVMLight creatrors: please ensure that WeakReferences are the best solution - you should rather replace them, because Android's GC is removing bindings with no reason.
Related
I'm relatively new to JavaFX and have written a small applet which launches a number of (typically between 3 and 10) sub-processes. Each process has a dedicated tab displaying current status and a large TextArea where the process output is appended to. For simplicity all tabs are generated on startup.
javafx.application.Platform.runLater(() -> logTextArea.appendText(line)))
The applet works fine when workloads on sub-processes are low-moderate (not many logs), but starts to freeze when sub-processes are heavily used and generate a decent amount of logging output (a good few hundreds of lines per second in total).
I looked into binding the TextArea to the output, but my understanding is it effectively calls the Platform.runLater() method so there will still be hundreds of calls to JavaFX application thread per second.
Batching logging outputs isn't an ideal solution either because I'd like to keep the displayed log as real-time as possible.
The only solution which I think might solve the problem seems to be dynamic loading of individual tabs. This would definitely prevent unnecessary calls to update logging textareas that aren't currently visible, but before I go ahead to make the changes, I'd like to get some helpful advice from you here. Thanks!
Thanks for all your suggestions. Finally got around to implementing a fix today.
The issue was fixed by using a buffer coupled with a secondary check for time lapse (maximum 20 lines or 100 ms).
In addition, I also implemented rolling output to limit the total process output to 1,000 lines.
Thanks again for your invaluable contribution!
My question is plain and simple. Can i run custom code in the updateHandler when I´ve executed a HKWorkoutSession and is listening for HeartRate samples? (Even when the Watch is locked from "wrist down" movement)
If this i possible what are my limitations?
I´m interested in processing the HeartRate data when my code receives them. I don´t have a device yet so I haven't been able to test it yet.
Would love your thoughts on this if anyone have experimented with an actual device.
Yes you can do this, I've had it append every HKSample that came back from my query onto an array, so when I resume the array is much larger. However UI won't update this way, on resume you need to update to the values you've received from the updateHandler.
Whether I should be doing this, or how far it can be pushed, I'm not sure.
Update
In the latest Xcode 7 beta you can get simulated workout data, so you won't need to install the Watch OS 2 beta on your device.
I'm developing a mobile app using Flex and I have run into some problems using BlazeDS. Some users request a (relatively) pretty large amount of data from my server, which returns in about 2 seconds. The data consists of some pretty simple objects (Client, which has a name/phone/email, and a few other properties, some of which are other nested objects with more properties). The largest requests consist of no more than about 10,000 of these objects, which is only a few MB in size. The problem I am running into is that as soon as the server sends its response, the mobile screen locks up while the data is being processed. For 10,000 objects, this can take several minutes and sometimes even crash the device, and at best leave the user with a frozen screen the entire time. For the average user, it is at least 2-5 seconds of frozen screen. This is not only an issue for devices with limited capabilities. This also happens on my PC (i5 processor, 8GB RAM). From what I can tell, this downtime is taking place somewhere between when the device receives the response and when I can access the data. Setting a breakpoint on the first line of the following RemoteObject result handler has the screen lock up BEFORE it reaches the breakpoint:
protected function myResultHandler(event:ResultEvent):void
{
var result:ArrayCollection = event.result as ArrayCollection;
//Do other stuff here
}
I know very little about BlazeDS and AMF, so my only guess is that the freezing happens while the objects are being created on the device. Is there any way to speed up this process at all? Should I normally expect to see really poor performance like this? Any help would be greatly appreciated.
After a couple of hours digging around, I found the solution to my problem: On the server side, the objects I was sending had a ton of extraneous properties unrelated to the information I needed on the mobile app. In addition, there were helper methods on those classes in the form getMyHelper() which would attempt to generate a property on the Flex side. This resulted in a huge list of reference errors being thrown during the download since no properties with those names existed in the AS objects. I created stripped down 'lite' versions of the objects I needed sent across with no extra properties or methods. The massive lists now display nearly instantaneously after receiving the response from the server.
I spent hundreds of ours developing an Adobe AIR Application with Flex 4.0 and now I thought I should have finished, but after letting the application run for more than a few hours the UI-responsiveness begins to lack...
What I do:
My application uses custom chromes by setting backgroundImages with transparency to BorderContainers within Window-modules. I open up many different popups, which all are based on the Window-Class (not TitleWindow!) and created and closed dynamically in ActionScript. By using the Flex Profiler I certainly know, that the garbage collector destroys all the allocated ressources correctly, and the memory consumption does not rise with application uptime. Further the profiler shows me, that none of my methods occupate extensive cpu-time, so this also should be ok.
What is really interesting:
If I continously interact with the application (click buttons, write text,...) nothing happens and everything is fine, BUT if I do not interact with the application for several minutes and then come back - the UI-responsiveness is really poor!
Really poor means, that if I type some text into a TextInput-Control, I can watch every single letter being written with a delay of at least 1 second!
Has anyone experienced a similar situation, or someone who knows, what the problem could be?
My suggestion is, that after some activity the flash-player-runtime limits the cpu-usage of the AIR application, and doesn't give back full power when the user returns.
I tested the application with Flex 4.0, Flex 4.1, AIR 1.5, AIR 2.0 with Flash Player 9 and also Flash Player 10 running on Windows XP and Windows 7...
I have finally found the solution!
The new spark-components introduced with Flex 4 added a property called "backgroundFramerate" to the WindowedApplication-class. By default, this property is set to 1, which means that AIR automatically throttles the framerate when the main (!) application-window get's inactive. Unfortunately this framerate is used for the whole application, including all other window-instances which could be in the foreground and active!
After disabling the automatic framerate-throttling by setting the backgroundFramerate-property to -1 all the problems were gone!
Altough, I know, that instiating new window-derived objects to show popup-windows, I believe that this is a bug in the Flex 4 which is still not fixed.
I have been involved in building a custum QGIS application in which live data is to be shown on the viewer of the application.
The IPC being used is unix message queues.
The data is to be refreshed at a specified interval say, 3 seconds.
Now the problem that i am facing is that the processing of the data which is to be shown is taking more than 3 seconds,so what i have done is that before the app starts to process data for the next update,the refresh QTimer is stopped and after the data is processed i again restart the QTimer.The app should work in such a way that after an update/refresh(during this refresh the app goes unresponsive) the user should get ample time to continue to work on the app apart from seeing the data being updated.I am able to get acceptable pauses for the user to work-- in one scenario.
But on different OS(RHEL 5.0 to RHEL 5.2) the situation is something different.The timer goes wild and continues to fire without giving any pauses b/w the successive updates thus going into an infinite loop.Handling this update data definitely takes longer than 3 sec,but for that very reason i have stopped-restarted the timer while processing..and the same logic works in one scenario while in other it doesnt.. The other fact that i have observed is that when this quick firing of the timer happens the time taken by the refreshing function to exit is very small abt 300ms so the start-stop of the timer that i have placed at the start-and-end of this function happens in that small time..so before the actual processing of the data finishes,there are 3-4 starts of the timer in queue waiting to be executed and thus the infinite looping problem gets worse from that point for every successive update.
The important thing to note here is that for the same code in one OS the refresh time is shown to be as around 4000ms(the actual processing time taken for the same amount of data) while for the other OS its 300ms.
Maybe this has something to do with newer libs on the updated OS..but I dont know how to debug it because i am not able to get any clues why its happening as such... maybe something related to pthreads has changed b/w the OSs??
So, my query is that is there any way that will assure that some processing in my app is timerised(and which is independent of the OS) without using QTimer as i think that QTimer is not a good option to achieve what i want??
What option can be there?? pthreads or Boost threads? which one would be better if i am to use threads as an alternate??But how can i make sure atleast a 3 second gap b/w successive updates no matter how long the update processing takes?
Kindly help.
Thanks.
If I was trying to get an acceptable, longer-term solution, I would investigate updating your display in a separate thread. In that thread, you could paint the display to an image, updating as often as you desire... although you might want to throttle the thread so it doesn't take all of the processing time available. Then in the UI thread, you could read that image and draw it to screen. That could improve your responsiveness to panning, since you could be displaying different parts of the image. You could update the image every 3 seconds based on a timer (just redraw from the source), or you could have the other thread emit a signal whenever the new data is completely refreshed.