You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when a permission is in the denied state, according to the system, I can not re-display the ISHPermissionRequestViewController. It would be preferred that this is easily over written so a controller can be displayed that is configured to guide them to the application settings, which would essentially be the same controller as the initial prompt but with a "Settings" button instead of "Allow". As far as I can tell I have to subclass a couple different classes to determine if a ISHPermissionRequestViewController should be allowed to be displayed.
The text was updated successfully, but these errors were encountered:
That is a very good idea. However the recovery is only really possible in iOS8, before that opening the settings wasn't really possible, or am I missing something? In that case the view controller should probably provide some instructions for the user on how to open the settings. The content of which would probably be outside of the scope of this framework ... for now.
We could also upon pressing the settings button, check if the user has previously chosen the state ISHPermissionStateDoNotAskAgain. In that case the user must be asked for permissions before the permission even shows up in the settings.
I would suggest to implement this as an optional ISHPermissionsViewControllerDataSource method that provides a recovery view controller. The method would provide a view controller that is a subclass of some new ISHPermissionRecoveryViewController class, which would provide methods indicating if recovery is possible and would "force" ask for permissions (even if the user did not want to be asked) before presenting the settings (if possible).
The data source may choose to return nil for individual permission categories if they are not as important or if the recovery view would be too distracting in some situations. Not implementing that method would yield the same behavior as it does now.
That is correct in regards to iOS 8 being the only version in which an app can open its settings.
It seems a bit much to add a new class to handle the recovery when it could be incorporated into ISHPermissionRequestViewController since it would either give the developer an option to open settings or allow the ISHPermissionsViewControllerDataSource to provide a view with the correct instructions. Possibly - (IBAction)displayRecoveryOption:(id)sender;. No override would run the default for iOS 8 and take the user to the applications settings. The developer could override to then instead display a view with the instructions for iOS 7.
I might not being thinking of this correctly because I currently have an object to bypass the use of the ISHPermissionsViewController class to display a subclass of ISHPermissionRequestViewController to make use of a custom transition.
Currently when a permission is in the denied state, according to the system, I can not re-display the ISHPermissionRequestViewController. It would be preferred that this is easily over written so a controller can be displayed that is configured to guide them to the application settings, which would essentially be the same controller as the initial prompt but with a "Settings" button instead of "Allow". As far as I can tell I have to subclass a couple different classes to determine if a ISHPermissionRequestViewController should be allowed to be displayed.
The text was updated successfully, but these errors were encountered: