If this occurs, the user has to authenticate every time the app starts or even when the app comes into foreground, depending on the `restrictionEnforcementFrequency` setting
If there would not be any rootViewController (which iOS now requires though), it could happen that the auth window would not disappear upon successful authentication. The app would have had to be killed and started again to proceed.
remove dispatch_once. It should be safe to call this multiple times.
Although in the default use case this makes pretty much no sense,
but for the demo app it's nice to have.
* factor out common validate method
* call it in authenticate and after validation-error was dismissed
* don't reset identification if validation failed - it might have only been
a short network outage.
This solves multiple issues:
- Possible crashes at startup because the app is already in the process of presenting another modal view. This way the developer can make sure that only one modal view is being presented
- If the app is showing e.g. a login view on startup, it is now not needed to turn off automatic mode and setup the complete auth workflow manually and simply invoke `authenticateInstallation` after the login view is either fully presented (`viewDidLoad` finished) or the user did log in
This helps especially in case of a custom URL scheme, so that
BITAuthenticator doesn't reset the identification token if a URL
is passed in that wasn't meant to parsed by BITAuthenticator.
fixes#70
given the good feedback we got, this is take 2
of the BITAuthenticator interface.
It's simplified, cleaned up and now allows full
control over the authentication process.
Major changes:
* manual mode
Authenticator provides the bits to show the
viewController to identify the user as well as to
trigger validation on behalf of the developer.
* process separation
identification and app-usage-restriction are now
2 completely separated things.
* public identifier
Authenticator now allows the developer to query
parts of the information, e.g. the UDID or the user's
emailaddy once identified
instead of doing the presentation ourselves, use the
provided functionality in the HockeyBaseManager.
This also allows developer to provide their own viewController
by implementing
- (UIViewController *)viewControllerForHockeyManager:componentManager:; as
HockeyManager's delegate.
fixes#58
when startManager is called, it doesn't mean the app is actually active,
e.g. in iOS7 when a background download finished.
So check for active state in startManager and potentially wait for an
didBecomeActive notification.
