I am trying to develop a continuous location tracking app and testing it on W10 phone. It runs fine on background when I hit Back or Windows button.
However, when the app is in foreground and I press power button, wait a while and then power on, the application is gone. The crash dump shows error 0xc0000194 "Possible deadlock condition".
So far I was only able to get this stack info:
STACK_TEXT:
ntdll!NtWaitForMultipleObjects+0x6
KERNELBASE!WaitForMultipleObjectsEx+0x112
twinapi_appcore!PsmRegisterAppStateChangeNotification+0x2a4
twinapi_appcore!PsmRegisterAppStateChangeNotification+0x21f8
twinapi_appcore!PsmRegisterAppStateChangeNotification+0x2232
Windows_UI_Xaml+0x3777a8
Windows_UI_Xaml+0x37750e
0xbb067c
I noticed that when I hit Back or Windows key, VisibilityChanged occurs immediately. However when I press power off, this event is delayed, about 10 secs.
Could the deadlock be related to this? Is there any way to detect power button? I can stop doing UI updates when location is updated as soon as my app goes off screen, but need to know it asap, not delayed.
Thanks.
Related
I have a console app which monitors assorted things 24/7 and will issue warnings if it detects any faults. The other day I noticed that it failed to warn me about something and I later worked out that I accidentally clicked on the app thereby highlighting a single text cell in the console and the app was then locked up waiting for me to perhaps "copy" the highlighted text. This is rather hard to spot and I am concerned that it could happen again. Is there a way to prevent such locking - perhaps disabling any clipboard operations altogether?
I'm inspecting a performance issue with an AngularJS application.
When performing specific actions, the CPU usage goes to 100%, the Chrome window freezes, and I have to manually terminate the process using Chrome's task manager.
I tried to debug the app (DevTools' Sources tab), but the application is quite large and the code is minified, which means that finding the issue won't be easy: I see a lot of code triggered by the digest cycle, and can't figure out which code is the actual culprit.
What could be helpful is to be able to profile the application once it freezes; I'm pretty sure the profiler will immediately show the actual bottleneck. I can successfully start the profiler (Performance tab) before the freeze happens, but once the application freezes, when I click on Stop button, the Loading profile window is stuck at zero percent (I waited for fifteen minutes just to be sure, it's still at zero), so I suppose that it's frozen as well.
Therefore my question is:
How do I find what causes the application to freeze when I'm unable to figure it out by simply debugging the application?
To answer my own question, the solution was to use a different browser. Surprisingly, Firefox let me profile the application during the freeze. The remaining part was easy, as I expected: by comparing the profiling results before the freeze with the ones after it, one could figure which code is executed repeatedly.
Thanks to Aleksey Solovey as well for his comment.
I'm working on an app using geo fences but I'm hitting some issues.
I've been testing on Android predominantly so far.
a) I set up the geo-fence and it triggers fine for enters and exit events.
However, after an extended period time (such as a few hours or overnight) the events stop until the app is opened again.
b) My other issue is the geo-fence exit seems to trigger even when I haven't moved at all, and definitely not outside of the radius (150 meters).
I've looked at https://www.codenameone.com/javadoc/com/codename1/location/Geofence.html, and my code is very similar to the example.
Are there any other build hints I need to make it more accurate and persist in the background?
Geofencing should only be added once, it's a very flaky API in the native OS especially when it comes to background behavior that breaks frequently with OS updates.
Use something like:
if(Preferences.get("AddedGeofence", false)) {
addGeofenceBinding();
Preferences.set("AddedGeofence", true);
}
And see if this works.
I built this app that takes pictures, displays them for acceptance and uploads them to a webserver via post.
It is very simple in concept and execution. But then the app is freezing in the Android handset (I have an Xperia Z3+ which i has a fairly good amount of resources, also tried in a Moto X).
To try and reproduce this I take a picture (it will automatically tried the upload)... push the power button for the screen to shutdown... then when I light up the screen it takes a while for the app to start working again (I can see because I have a background animation). After some retries of these... the app will freeze and I'll have to close it to retry.
Any suggestions on how to troubleshoot this problem?
My thinking is that I can aliviate the problem a little by removing the animation elements from the screen... at least the perceived performance will be far better is the app does not appear frozen on any app switch... therefore I want to be able to use the onPause, onStop from the activity lifecycle events to clear the animations. I guess those objects are serialized, so I will save serialization and deserialization time and also the perceived performance will improve as no freezed app will be seen while the onResume, onRestart events.
Is this posible?
Thank you very much
Chuck
This isn't caused by the animation, it may be caused by an uncaught Exception or poor app performance.
To review your app performance, move any long process that requires feedback to the UI (AsyncTask) to postShow() method of your forms and not beforeShow(). If it doesn't require feedback to UI in real time (IntentService), consider using Display.getInstance().scheduleBackgroundTask() which runs your task on a low priority thread while serializing it and this can be done in the beforeShow() method. If your forms are handcoded (Not GUI), do heavy long process in addShowListener().
Also cut down the amount of images you use in your app as this could also hinder your app performance when loading heavy images.
Avoid unnecessary use of revalidate(), usually by not calling it in a loop, it's a bit expensive, use repaint() instead.
You can also use Android ddms to check if your app is running into some errors.
Locking your screen or minimizing shouldn't affect your app in anyway other than when the app is starting up and the splash screen is shown (This usually freezes the app if you minimize your app when splash is shown). I believe this is a known issue though.
Another option could be the "suspend-resume" behavior. When an app is suspended (power button, incoming phone call etc.) the stop() method is invoked followed by a call to the start() method when it returns.
If you have a progress indicator during the stop() method then the restore call will reshow the progress indicator with the previous form as its "before form". That way when the progress indicator is dismissed it shows the "previous form". You can test this behavior in the simulator using the "suspend/resume" menu.
To workaround it just dispose the progress indicator in the stop() method as such:
public void stop() {
current = Display.getInstance().getCurrent();
if(current instanceof Dialog) {
((Dialog)current).dispose();
current = Display.getInstance().getCurrent();
}
}
I have a requirement where I need to show a Lock screen , when the app remains idle for certain period of time. In WP7 is there any way to get the Idle time(Any OS APIs). I have gone through MSDN documentation of PhoneApplicationService.UserIdleDetectionMode and PhoneApplicationService.ApplicationIdleDetectionMode but it is just for enabling and disabling.I need some method by which I can get the Idle time. Thanks in Advance
To my knowledge, there isn't a way of doing that in the current API version.
You could implement a timer in your application and reset it every time there is an user interaction (with your controls) within your application.
The bigger question is how you should handle the OS lock screen? I mean, if your application has an in-app custom lock screen that has kicked in, and then the OS lock screen kicks in, then the user has to unlock 2 screens. Not especially user friendly in that case.