Participant

Question

Problem Exiting an AIR application on the Mac

Forum|Forum|15 years ago
March 9, 2011
4 replies
1986 views

Hi,

I work at ICQ, and we develop a client version based on AIR for the Macintosh.

I currently have a problem and I can't find a proper solution.

The application is based on an HTTP client server protocol (AOL's WIM).

When the user wants to exit the application we need to hit a sign off URL, so users on the other side will know the user went offline immediately.

So I've started out by listening to the NativeApplication Event.EXITING, which catches all sorts of user exit methods on the Mac.

If the client is currently logged in, I do the following:

- Call the proper sign off URL request

- Call event.preventDefault(); so the application won't exit before the request complete

- When the event completes (or fails), call NativeApplication.exit();

All fine up to now.

The problem occurs when the user tries to logout from the Mac using Logout / Restart / Shutdown from the Mac's Finder menu.

Calling preventDefault on the event immediately aborts the user's logout operation, indicating ICQ prevents the computer from shutting down.

Unlike windows, which asks applications to close themselves, and then give them some time and check if they are already closed, the Mac probably waits for a response, and the AIR application returns something when preventing the event to complete.

My questions:

1. Is there a way to let the Mac logout operation continue and still wait for the event to complete?

2. On the other hand, Is there a way to make a synchronized URL request in flash? So I will know the request went through, and let the system logout if needed?

3. If there is no way, Is there a way to differentiate between receiving quit events from the system dock quit menu (Which I can't remove), and the top level finder commands (logout, restart, shutdown).

Note: I've tried using both URLLoader and sendToURL. Also tried both GET and POST.

The behavior is inconsistent. Sometimes the url request makes it but usually it doesn't.

Please help,

Thanks,

Asaf

Performance issues

This topic has been closed for replies.

A

Anonymous

HI asafkoski,

I have exactly same problem u have this. Do u got any solution regarding it.

Please provide solution if u have it regarding MAC os. Also Oliver please provide also u have it.

Thanks.

A

Anonymous

No, there is no way to let the logout continue and still get asynchronous work done. As you note, sometimes asynchronous work will complete, but the timing really depends on when Mac OS shuts down the application and how long the work takes.

To the best of my knowledge, Mac OS does not have an option for the application to request additional time before shutdown. Although it sounds like a simple idea, it quickly gets complicated in practice. How long is it reasonable to wait for? What if the application doesn't wrap up its work in the allotted time? Ultimately, there's always a scenario in which the application can be terminated before it's ready.

Unfortunately, there is also not a way to issue a synchronous URL request. This would be a good addition to our APIs, however, and I anticipate it will eventually come along. Not soon enough to address this post, however.

Finally, no, there is no way to distinguish the source of the exit event. I agree that would be handy. Please consider posting both this idea, and the synchronous network call idea, to ideas.adobe.com/air.

regards,

Oliver

Oliver Goldman | Flash Platform Architect | Adobe Systems | ogoldman@adobe.com

A

asafkoskiAuthor

Participant

Hi Oliver,

Thank you for the quick and comprehensive response.

I will post a link to this post and your answer to the air ideas forum, and maybe will get lucky getting one of these into a future version of AIR.

For now, We've replaced the top level Quit and CMD+Q behavior to exit the application gracefully.

In logout etc. we try to make the request and sometimes we make it.

Thanks again.

Cheers,

Asaf

A

asafkoskiAuthor

Participant

Hi.

Sorry for Bumping this subject.

any update on that?

A

Anonymous

We saw this same problem with our application. When we investigated it, it turned out that the act of calling event.preventDefault() is the culprit - it singals the OS that you won't be letting it shut down so easily. We did was to hook Event.CLOSING on the main window and deal with our logic from there. That seemed to have the desired effect. I'm not 100% certain that it covers all of the possible shutdown cases, but it seems to be close enough for jazz.

A

asafkoskiAuthor

Participant

Thanks for the response Brister.

Actually, we do catch the CLOSING event, but we do not close the application, but rather only hides the window.

We use it to handle pressing the 'x' button.

But I think I don't understand completely.

To my knowledge, The CLOSING event arrives after the EXITING event. The application is already at shutdown mode.

Let's say I raise a flag at the EXITING event, and then do the logic in the closing event. Will the preventDefault on the CLOSING event won't yield the same behavior?

I must prevent the application exit until the URLLoader.load action complete successfuly.

Do you make a URL request on your shutdown procedure, or only do synchronic cleanups?

A

Anonymous

Ah, good point. Hadn't thought of that. No, we are only doing local cleanup - no puts to the server.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded