According to Google's app lifecycle docs
When the event page has no executing JavaScript, no pending callbacks, and no open windows, the runtime unloads the event page and closes the app.
I am seeing in my app that an onSuspend is being triggered, which also has the side effect of invalidating any FileEntry or DirectoryEntry references (an as-of-yet undocumented "feature"), only the onSuspend is triggered when I still have pending callbacks and open windows. Does anybody know which other conditions will trigger an onSuspend? Does it have to do with the app using too much memory?
It makes sense that onSuspend will be called when the event/background page has no activity and there are no windows open, but when else would onSuspend be called?
Is there a secret permission that I can use to disable onSuspend from being called? A background permission API in the works?
It should not be triggered if you have open windows unless something atypical is under way, like the user upgrading chrome.
If you are seeing onSuspend events at other times, that sounds like a bug. Please report at crbug.com with steps to reproduce.
Related
I would like to know if AssistiveTouch is enabled or not, because my App wants to give the user instructions how to set it up properly for a certain use case.
I tried getting UIAccessibility.isAssistiveTouchRunning but it never returns true. I even put it in a timer and switched AssistiveTouch on and off but it always returns false. I then added UIAccessibility.assistiveTouchStatusDidChangeNotification like so:
NotificationCenter.default.addObserver(forName: UIAccessibility.assistiveTouchStatusDidChangeNotification, object: self, queue: OperationQueue.current, using: { notification in
print(notification)
})
but this never gets triggered.
What am I missing? Is this feature not available?
Greetings krjw
EDIT 1
I tried isVoiceOverRunning and it works. I can't seem to get further with this.
I've encountered same behaviour. I've opened a TSI with Apple and as for their response - It only works if Guided Access is also turned on and active. I'm trying to figure out if there's any way we can determine if only assistive touch is running. Will update ...
UPDATE
Apple has responded that in order for it to work, the settings option "GUIDED ACCESS" has to be also enabled. Which makes no sense as there's no relation between the two features.....
I'll send a feedback via Feedback Assistant and request an option to know if ONLY assistive touch is running.
I am trying to port a WinForms app for use with Mono, and I've recently noted that calling Form.Show() from another form will either do nothing or cause the new form to flash and disappear. I read something about the new form needing a message pump, which is accomplished with Application.Run(), but that's already been called. Any idea why this doesn't work? I can't use ShowDialog because my program relies on events fired by completed async tasks, and I don't want to block a ton of extra threads that will be done right after the Show call.
Have you tried to hide your current form before showing/displaying your new one?
Seems to me like your form is indeed being displayed but for some strange reason it's being delegated to the background. Worth a shot.
Part 1: Expected behaviour?
I'm seeing some inconsistent browser behaviour between Firefox and Chrome in relation to the onclose handler being called.
It seems that Chrome does not trigger an onclose if it was caused by a user page navigation/refresh. However, Firefox does trigger the onclose.
It seems to me that Firefox may be behaving correctly here:
When the WebSocket connection is closed, possibly cleanly, the user agent must create an event that uses the CloseEvent interface, with the event name close, which does not bubble, is not cancelable, has no default action, whose wasClean attribute is set to true if the connection closed cleanly and false otherwise, whose code attribute is set to the WebSocket connection close code, and whose reason attribute is set to the WebSocket connection close reason; and queue a task to first change the readyState attribute's value to CLOSED (3), and then dispatch the event at the WebSocket object.
Source: http://www.w3.org/TR/2011/WD-websockets-20110419/#closeWebSocket
Even though it can lead to some sneaky code/unexpected behaviour.
Can anybody confirm the expected behaviour?
Part 2: How to implement auto-reconnect?
If you have a library that auto-reconnects for the user how do you know if you should try to reconnect? Do you check the CloseEvent.wasClean property? I'm having to assume that 'clean' means that the close was supposed to happen through either an API call to WebSocket.close() or the server sending a close frame? If a network error causes the close I'm guessing the wasClean would be false?
In the Pusher JavaScript library we assumed (onclose -> waiting -> connecting) that a close should trigger a reconnect unless we are in a closing state - the developer has chosen to close the connection. It would appear that the socket.io client library makes the same assumption.
Based on this the Firefox onclose event caused by user navigation/refresh triggers an unwanted reconnection because neither library check the CloseEvent.wasClean property.
Example and Video
Here's an example that you can use to demonstrate the inconsistency:
http://jsbin.com/awonod/7
Here's a video of me demonstrating the problem:
http://www.screenr.com/vHn8
(it's late, ignore the couple of slip-ups :))
One point to note is that my hitting the Escape key could also be causing the WebSocket connection to close. However, if you watch closely or try for yourself you will see the close event being logged just before the page refreshes.
The unexpected behavior is due to the way in which Firefox and Chrome handle the closing of a Websocket. When the page is refreshed, both browsers close the connection, however, Firefox will execute your onclose code, while chrome closes the connection and skips straight to re-loading the new page. So yes, I confirm this strange behavior.
Even stranger is the fact that, from my observations, calling websocket.close() in chrome will immediately close the connection and call the onclose function, while Firefox waits for a close message back from the server.
The wasClean property will be true if a close message was received from the server
If your library is auto-reconnecting without checking the wasClean property then this could cause a problem, as it tries to re-establish the connection as the page refreshes. You should consider not using the library for this and doing it manually, it should'nt be very hard, just call connect in the onclose function with an if statement making sure the onclean property is true. Or to be even more safe set a variable in onbeforeunload that prevents any new connection.
hope this helps!
This is amazingly still the current behavior in 2022. You can demonstrate this trivially by adding a console log in an onclose handler for a websocket, and click a link in Firefox vs in Chrome while watching the console (ensuring you preserve the console between webpages):
ws.onclose = function(e) {
printMsg('CLOSE')
// ... my other code ...
}
Firefox will show you a 'CLOSE' and Chrome will not.
I develop a FB app using Flash using wmode="direct" (for 3D graphics).
In Internet Explorer, every time I popup any FB dialog (e.g Purchase Credits dialog), the flash disappears and when the dialog is closed, the flash does not re-appear...
I tried to set the visibility after dialog is closed:
http://developers.facebook.com/docs/appsonfacebook/tutorial/ (under "Special Considerations for Adobe Flash developers"), but it didn't work.
I've also tried the use FB.Init hideFlashCallback:
http://developers.facebook.com/blog/post/555/ (under "Detecting visibility of Flash objects in Canvas apps"), but it doesn't seem to call the callback function...
Any one had the same issue and manage to make it work?
Any other suggestions?
P.S - I use swfobject to embed the SWF file.
Thank a lot!
Roei
UPDATE: I removed the appId param from the FB JS url:
<script type="text/javascript" src="http://connect.facebook.net/en_US/all.js#appId=XXXX&xfbml=1"></script>
and now the hideFlashCallback is executed, but still - the flash does not re-appear...
I've updated the section Special Considerations for Adobe Flash developers because the code snippet was a bit out-of-date.
The new snippet should give you an idea of how to use the hideFlashCallback, whose semantics have changed since that now out-of-date blog post, in that the function now takes a flash element as an argument. (Unfortunately, we haven't redocumented it yet, but will soon). One thing to note is that the callback does not currently work on IE8, but will after a fix gets pushed next Tuesday.
That said, it should work without that callback. It may be caused by a javascript fatal that stops script execution before the re-showing happens. Look in your javascript console to see if you see any errors.
Otherwise, if you can give me the canvas URL for your application, I can look into it.
Did you try it with other wmodes? what you can try is actually remove the div where you write your flash to, add it with innerHTML and run the swfobject.embed again
Simple question, I guess.
How to trigger mobileinit event at jQuery Mobile?
I get some Ajax response, which is not nicely designed (in jQuery Mobile form). And I guess I have to trigger this event to get it done.
you could try $.mobileinit(); in the jQM Library itself it's called like this:
$( window.document ).trigger( "mobileinit" );
I don't trust mobileinit. I am building a mobile app with Phonegap and jQueryMobile, currently testing on Android 4.0.3, and the event is just not firing. At all. It is correctly set up, since I can trigger it in the Chrome console while testing on desktop.
Binding to window instead of document makes no difference.
Of course I could trigger it in some other event handler like pagebeforecreate on the first page in the DOM. But that's putting the horse behind the cart.