This closes#125
Prefer a slightly slower, but bulletproof, way to check for the splashscreen instead of relying on the Cordova preferences. This fixes the splash screen on several phones.
Also made a high z-index the default. This could be added from the user's stylesheets but if that only
gets parsed later, there may be flickering between the application UI and the splash screen itself.
The fading logic exposed a race condition in an edge case when the
plugin was repeatedly reinitialized, e.g. when the WebView tries to load
a new URL. To address this, we add a flag to removeSplashScreen() that
allows the fade logic to be bypassed in certain circumstances --
specifically, when hiding the splashscreen due to onPause or onDestroy
events. By hiding it immediately in this scenario, we can avoid any race
conditions due to the fade delay.
github: close#86
Removes spinnerStop call from onMessage("spinner", "stop") as it is called when webview is shown and we are hiding spinner manually along with the splashscreen dialog.
Changed the spinner to be noncancellable.
Changed the ProgressDialog to custom only-spinner mode (on transparent background, without title/message and dimming).
Removed unused spinnerStart action handler.
Updated the docs.
When the plugin is initialized, the splash screen is shown with an
auto-hide delay. If a subsequent call to show() comes in while the
splashscreen is visible, it will still be automatically hidden, even
though the user expectation is that it wouldn't be.
This fix tracks the "hideAfterDelay" setting of the most recent call to
show() -- and when the auto hide timer goes off, if the most recent call
to show() did not set hideAfterDelay, then the splashscreen will not be
automatically hidden.
This provides a more consistent -- and expected -- behavior based on
user action.
https://issues.apache.org/jira/browse/CB-9094
Github: close#49
Also initializing the splashscreen image irrespective of firstShow because the splashscreen could be shown manually via navigator.splashscreen.show(); after exiting the app using BackButton or via navigator.app.exitApp();
Refactoring, adds support of seconds for fade duration for backward compatibility
Includes fade duration into overall splashscreen duration to be consistent with iOS
Updated the docs
If you have an element that shares the `name`, like <feature
name="SplashScreen">, then the `value` attribute was read of that
instead (since it can appear *before* the preference element). Thus, the
config of `SplashScreen` preference was not settable at all.
This is a port of emarashliev's original fix for CB-3562, cleaned up
to avoid deprecated functions.
Merge branch 'master' of https://github.com/emarashliev/cordova-plugin-splashscreen into CB3562
Signed-off-by: Shazron Abdullah <shazron@apache.org>
The viewController.interfaceOrientation passed to getImageName has not
yet been updated with the new orientation, even when the frame/bounds
change event has fired. Thus, the plugin never actually loads the
correct image for the new orientation. Instead, it poorly scales the
existing image.
This fix uses the statusBarOrientation property of the UIApplication
object to detect the actual orientation, and correctly load the right
image.
Signed-off-by: Shazron Abdullah <shazron@apache.org>
There are two aspect ratios for Windows Phone devices: 15:9 and 16:9. At
the moment, though, there is only one splash screen by default for WP8
Cordova apps. When stretched to fit all possible resolutions, this can
sometimes look bad.
WP supports resolution-specific splashscreens, so this commit adds the
same support to the splashscreen plugin. It uses the same base name for
the splashscreen, but adds modifiers such as ".screen-<res>" based on
the device. If a screen-specific image is found, it is used. If not, we
fall back to the single default image.
Fixes https://issues.apache.org/jira/browse/CB-8750
github close#41
github close#42
When calling hide() from JS, the attempt to access Popup could happen on
a background thread, which ends up throwing an
UnauthorizedAccessException about cross-thread access.
To address this, it's best to check the popup's state from within the UI
thread.
Fixes https://issues.apache.org/jira/browse/CB-8758
