Answers inline. * The criteria for when online/offline events fire (internet
> connection) seem vague, especially with ubiquitous non-Wifi network > options. Do various devices use the same threshold criteria to fire > the event? > > Offline/online is common code in the JS that uses NetworkStatus.getConnectionInfo: https://github.com/apache/cordova-js/blob/2d15c4045aab52f8b2d728bd90244894258b3b47/lib/common/plugin/network.js#L55-L70 Only a connection type of 'none' will trigger the offline event, anything else is 'online' > * Do relevant online/offline events fire when the app starts up, or > only when a change is detected during execution? The text for the > offline event iOS quirk implies the former case: "During initial > startup, the first offline event (if applicable) takes at least a > second to fire." If it fires when the app inits, is the value of > navigator.onLine true or false during that 1-second delay? > > During both startup and when a change is detected. navigator.onLine is tied to the connection API: https://github.com/apache/cordova-js/blob/2d15c4045aab52f8b2d728bd90244894258b3b47/lib/common/plugin/network.js#L30-L34 During that iOS delay, it will be 'unknown' then after it should reflect the right value. > * When navigator.onLine == false, is connection.type NONE by > definition? Are there any known cases of connection type UNKNOWN > when you're offline? > > Yes. navigator.onLine is tied to the connection API: https://github.com/apache/cordova-js/blob/2d15c4045aab52f8b2d728bd90244894258b3b47/lib/common/plugin/network.js#L30-L34 Offline === 'none'. Anything else is online. > * Extraneous question: Are there plans to implement the W3C-spec'd > "change" event for navigator.connection? It would make the feature > more useful in conjunction with online/offline. (Too bad there's no > spec for when your data plan is unlimited...) > > Not in the cards, but please file a feature request at http://issues.cordova.io > * The APIs track closely to the W3C specs, but may lag. Are there > any similar cases where there are spec'd features not implemented > in the corresponding Cordova APIs? > Not sure. We're planning on using the Media Capture APIs I think, not sure where in the roadmap it is, it should be on the wiki. > > * The doc for the "pause" and "retrieve" events say "native code" > takes the app in and out of the background. Yes, but does that mean > it can be controlled by anything other than direct user manipulation? > E.g., an app can't pause itself, correct? > > No, the app can't pause itself. The system throws events that we capture, and translate to pause/resume. > * Extraneous question: Do developers ever use appCache manifests to > update components passively & separately from native update options? > > Not sure for other platforms. In the early days appcache didn't work for iOS UIWebViews, I think that has changed. > * Re "resume" event iOS quirks, do all calls to plugins or the Cordova > API by definition go through Objective-C? > If it's a native plugin, yes. > > * The doc for the searchbutton event says: "The event fires when the > user presses the search button on Android." Does this mean only > Android devices have a search button, or that it doesn't fire on > other devices that may also have a search button? > > An Android dev would be better answering this. > * The same question applies to Android's menu button. Does it appear > only on Android, or is it only supported on Android? > > An Android dev would be better answering this. > For several events the doc says you can "override" default button > behavior, which needs clarification: > > * By default, would pressing the back button return to the home screen > from which you launched the app? Does a "backbutton" handler > disable this, perhaps replaced by behavior tied to the > browser-specific history API? > > An Android dev would be better answering this. > * Would "startcallbutton" & "endcallbutton" handlers actually > interfere with your ability to start and end calls? Otherwise what > does "override" mean in this context? > > An Android dev would be better answering this. > * Would a typical use case for a "searchbutton" handler be for an app > to provide its own search UI? > > An Android dev would be better answering this. > * Would a typical use case for "volumedownbutton" & "volumeupbutton" > handlers be to modify volume for playback of a particular media > file, rather than affecting the overall device volume level? > > I think this would depend on the situation - it's whatever the dev wants it to do. Some apps could use the volumeup to trigger the camera "shutter" for example, on iOS. > * Please confirm: by default, these handlers "override" default button > behavior, but with no need to call event.preventDefault(). > > Not sure.
