I am writing an app that displays some information in a window when incoming call arrives. To do it I have a broadcast receiver which starts the service, then the service gets needed information and opens the window using windowmanager object. I must keep the service running as long as the user doesn't close the window to prevent window closing unexpectedly. The problem is: the window gets closed at unexpected time because the system kills the service. I need that window to stay opened until user closes it. I need your suggestion what can I do to make that window stay opened as long as the user doesn't close it. And if there's a way without keeping the service running it would be awesome too. Maybe I should start a non full screen activity instead of window? Then the system wouldn't kill it so aggressively. Please suggest me something. Thanks in advance!
Related
Why is it recommended to use setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); if there are ways to explicitly close the frame?
Calling setDefaultCloseOperation(EXIT_ON_CLOSE) causes the application to exit when the application receives a close window event from the operating system. Pressing the close (X) button on your window causes the operating system to generate a close window event and send it to your Java application. The close window event is processed by the AWT event loop in your Java application which will exit the application in response to the event. If you do not call this method the AWT event loop may not exit the application in response to the close window event but leave it running in the background.
JFrame.EXIT_ON_CLOSE stops the application from running in background. For example, if you didn't use JFrame.EXIT_ON_CLOSE, if your application has an active database connection, it will stay connected. To check this, you can open task manager and see the jar file still running even if its window is no longer visible.
I'm writing a simple app to enable adb over ethernet on startup of the android, with a cancel button to prevent the enabling of the of the adb on the network. When the pop-up for superuser appears, if clicked immediately everything is fine, but if I wait a few seconds and click ok, the display fails to update.
The onCreate uses a mHandler to start a runnable, which is used for the countdown timer. When I used a mHandler.postDelayed to try to delay past the startup process, the display is never updated. When I use mHandler.postAtFrontOfQueue the countdown display functions properly, but following the superuser dialog the screen fails to update.
The countdown timer uses mHandler.postAtTime to repeatedly call the runnable. I'm thinking I need to put something at the start of the runnable to reset the focus, but am still new to the android and not having any luck figuring out what would make it happy.
When the application is run manually, everything is correct. On a second android, everything is correct.
I've found a workaround to the problem by changing from using "android.intent.action.boot_completed" to using "android.intent.action.MEDIA_MOUNTED".
What I observed was that the boot_completed happened before the full boot was complete. Something, not sure exactly what, stepped all over everything. When I tried to sleep or launch the runnable with a timer, if the sleep or timer crossed over the time things went wrong, the sleep and timer would never return, without ever getting into the runnable. By switching to the media_mounted, whatever was stepping on things had already passed.
I had been thinking of using the startup app to execute an init.rc file from the SD, so trigging off the media mount makes sense for that need.
I know this is almost the same question: ask by Joe
I have a web application. When I close the window (clicking X on browser) it will call the Logout functionality.
The problem is when I open the web application and open the same web application on different window (new window or another tab). And close one of the window it will call the Logout functionality even if there is still an open window for that application.
What I want to do is, check first if there are other window that is using the same jsessionid with the current window I am about to close. And when I close that window, It will only call the Logout functionality if there is no window using the same jsessionid.
The standard way of course would be to have the login cookie expire at browser close and thereby log you out, but I'm guessing this is not an acceptable behaviour in your case?
AFAIK you can't access the content of another browser window unless that window was created using Javascript. Since it sounds like you're using onUnload handlers in Javascript, you could make use of those same handlers to keep track of your windows. It would lead to some overhead though and would not be full-proof (would not handle browser crashes or if the user navigates away from your app for example).
Pseudo-code: (this needs to be a mix of server-side code and client-side javascript since the load handlers are handled in Javascript and the session is server-side)
function OnLoad() {
if (document.referrer != "{identify your app here}")
Session("BrowserWindowsOpen")++;
}
function OnUnLoad() {
if ({your code for if window is closed})
{
Session("BrowserWindowsOpen")--;
if (Session("BrowserWindowsOpen") == 0 )
performLogOut();
}
}
I made a java application that saves data to a .data file. I have a Window Listener that listens for the application to close in order to fire the code to save the data to the file. When pressing the dedicated quit button I have, or pressing the red "X" on the window, everything is fine. However, when the user opts for the command + q route things go sour. The application is quit, but the data is not saved. How do I correctly implement apple's handleQuit(Application Event e) method to fix this?
What you want in that case is a shutdown hook. A shutdown hook listens for the OS signal to close the app and is triggered when this signal is sent. A shutdown hook can run pretty much any code.
You can wire your built-in red "X" button to close the app (instead of saving the file), and the shutdown hook will catch the request and take care of saving the file.
The only caveat is that shutdown hooks are supposed to be made up of code that doesn't take very long to execute. So, the save of your file shouldn't take more than a second or two, and you shouldn't use confirmation dialog boxes that the user must acknowledge in a shutdown hook, because it can take an indefinite amount of time before the user recognizes the dialog.
The reason why shutdown hooks should be short lived is that when an application is requested to shutdown, the OS generally expects it to shutdown in a reasonable amount of time. If it doesn't, for example in Windows, the OS might display one of those, "Application isn't responding..." messages.
Finally, and you might run into this question later, you might wonder how to catch a "Force Quit" request from the Task Manager (or "Force Quit Applications" dialog on OS X). Well, you can't catch those, and you shouldn't try! While it is possible to disable things like listing your app in the Force Quit menu, this is a complete hack and should be avoided at all costs. If you're designing your app in a way that tries to circumvent options that should always be available to users and admins then that's a strong indication that your app is poorly designed, and/or a bad actor. Imagine if you installed an app that behaved in this way - wouldn't you think the programmer was being lazy or possibly malicious in trying to give their app un-killable qualities?
Also, force quitting is a forcible (ungraceful) shutdown that should only be used on applications when they are hung and won't quit normally. OSs need to have a force quit kind of option so that a user or admin has a way to kill a runaway or unresponsive app. If your users are force quitting your app they either misunderstand that force quitting isn't desirable, or there's something about the design of your app that makes force quitting more favorable than quitting your app normally. If this is the case (e.g. you hear from users that they force quit for one reason or another), it's usually an indication that portion of your app is poorly designed to match user's expectations.
I have the main thread from which I start a window using invokeLater. I run my application from command line. So, when application is running I see the window and my command line is "blocked" by the application.
I can stop the application either by closing the window (as a result the command line is unblocked) or by typing Ctrl-C in the command line (as a result the window disappear).
I wanted to be able to stop the application by clicking on a button in the window of the application. I used setVisible(false) for that. But in this way I can achieve the goal only partially. My window really disappear but the command line is still blocked. So, the software is still running.
Well, I assume it's because some other threads are still running. But how can I easily close all these threads (like I do by closing the window of the application manually).
System.exit(0);
If it's a JFrame you're showing, you can tell it to exit the app when the frame is closed - the default is to just hide the frame:
myFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
This will exit the app if the user closes the window (top right [x] button often) , in addition you could have a Quit button whose event handler closes the window using myFrame.dispose();
You must finish all threads in order to stop your application. Just hiding the GUI will not finish the AWT-Thread. Have a look at the API of the GUI classes you use like the dispose-methods.
Try Window.dispose()