Open aporat opened 9 years ago
Hmm. This is problematic, but UIAlertView is deprecated, so not supporting UIAlertController isn't really a long-term solution. I guess I can add an option to not use UIAlertController for now, but at some point it will probably become mandatory.
no doubt at some point UIAlertView
will have to go. However, the issues with presenting a UIViewController
instead of an UIAlertView on app launch might break logic in many apps, and the developers won't be even aware of these changes.
I doubt developers will know they need to turn off a flag to prevent this issue from occurring. perhaps there's a way to auto dismiss iRate controller if another viewcontroller is trying to be presented?
OK, I've added a property "useUIAlertControllerIfAvailable", and set it to NO by default.
I can imagine this will cause some pain in future, but it should solve the problem for now.
thanks for the quick fix! the fact the flag is NO by default makes sense.
I wonder if UIAlertViewController
can be used safely within irate in the future, as presenting view controllers "outside" the app logic can be tricky.
on app launch, i'm displaying a standard UIAlertView which it's main purpose is to present a
UINavigationController
when the user clicks on the UIAlertView's positive button.If iRate already presented it's
UIAlertViewController
, the app will fail to present theUINavigationController
as iRate'sUIAlertViewController
is already being presented. this is a major issue, as iRate usually fires on app launch. The user can't even dismiss iRate'sUIAlertViewController
, as my UIAlertView is displayed on top ofUIAlertViewController
.It would be wise to revert the
UIAlertViewController
and reconsider the effects of presenting a UIViewController instead of using a standard UIAlertView.see warning below:
my workaround is to revert to version 1.10.3