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
I found this question in Stackoverflow. Then i realize that in this package documentation, there's a miss sequence of how user implement this package in their project. And this most likely lead the user thinks there is a problem even though the user has not completed all the steps.
In the Stackoverflow question, there's user that has a problem with this package debug in iOS, i see the error is:
*** Assertion failure in -[CLLocationManager setAllowsBackgroundLocationUpdates:], CLLocationManager.m:972
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: !stayUp || CLClientIsBackgroundable(internal->fClient) || _CFMZEnabled()'
So it means the user has not added the key to info.plist as a permission for iOS even though it is mentioned in the last section of documentation.
In this example, as the permission is very important to make sure this package running well, i suggest to move the permission section documentation to the first step to start.
Actually it's fine as long as the documentation mentioned it, but i guess it's much better if we can minimize the unnecessary errors.
If the maintainer don't mind i'd like to contribute create a pr about this one:)
The text was updated successfully, but these errors were encountered:
I found this question in Stackoverflow. Then i realize that in this package documentation, there's a miss sequence of how user implement this package in their project. And this most likely lead the user thinks there is a problem even though the user has not completed all the steps.
In the Stackoverflow question, there's user that has a problem with this package debug in iOS, i see the error is:
So it means the user has not added the key to
info.plist
as a permission for iOS even though it is mentioned in the last section of documentation.In this example, as the permission is very important to make sure this package running well, i suggest to move the permission section documentation to the first step to start.
Actually it's fine as long as the documentation mentioned it, but i guess it's much better if we can minimize the unnecessary errors.
If the maintainer don't mind i'd like to contribute create a pr about this one:)
The text was updated successfully, but these errors were encountered: