-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor native Map and Style to log error and not throw exception #1230
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we validate if having these strings inline doesn't result in a bunch of allocations/de-allocations with each function invocation? Else we need to make them constants instead
Should we also remove WeakRefs from NativeObserver and StyleObserver ? |
@tobrun I do use |
Yeah I was recently looking at that code and I was yikes this doesn't look good |
In any case it should not matter - hitting that |
extension-style/src/main/java/com/mapbox/maps/extension/style/sources/Source.kt
Outdated
Show resolved
Hide resolved
extension-style/src/main/java/com/mapbox/maps/extension/style/sources/Source.kt
Outdated
Show resolved
Hide resolved
0ef4224
to
1bacb77
Compare
1bacb77
to
01fd8f2
Compare
6978eee
to
e59e356
Compare
@@ -15,6 +15,12 @@ interface StyleInterface : StyleManagerInterface { | |||
*/ | |||
val pixelRatio: Float | |||
|
|||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're 100% sure that interface is not implemented with any customer, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
StyleInterface is implemented in the SDK module itself, we allow user to overwrite the plugin implementations, but the SDK module itself shouldn't and couldn't be implemented by the end users.
The cases I can think of user use the StyleInterface is that they could mock it in their tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pengdev sounds a bit strange to me still as we're operating with Style
in our public API. Mostly it's one place:
/**
* Callback to be invoked when a style has finished loading.
*/
fun interface OnStyleLoaded {
/**
* Invoked when a style has finished loading.
*
* @param style the style that has finished loading
*/
fun onStyleLoaded(style: Style)
}
so for an end user guess it makes sense to mock Style
then... In any case I'll drop instructions in PR description for that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 didn't remember we return Style async instead of StyleInterface
sdk-base/src/main/java/com/mapbox/maps/extension/style/StyleInterface.kt
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a question, others LGTM. Thank you for taking this.
28cdc18
to
f26c591
Compare
if (!styleDelegate.isValid()) { | ||
delegate = null | ||
return@let | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to add some error logs here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's non-error situation - map destroyed while we were parsing so see no need in logs here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that code is not correct when using persistent layers, rollbacked in #1324
@@ -17,11 +17,11 @@ import com.mapbox.maps.extension.style.utils.silentUnwrap | |||
fun StyleManagerInterface.getSource(sourceId: String): Source? { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not in this release, but would consider to directly extend StyleInterface
in the next major release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with 1 comment, really like the documentation updates to the MapboxMap
and Style
, great work!
Summary of changes
Add
MapboxMap.isValid()
andStyle.isValid()
methods. Map and style become invalid whenMapView.onDestroy
is called: after that map and style objects are treated as not valid and accessing any method will cause printing error log and introduce a memory leak in user's code.Another thing worse to mention - for async geojson parsing we do check for style being valid when parsing is over and we're about to send geojson to core.
Additionally going thru all our example activities to fix potential leaks.
User impact (optional)
That PR enhances public
StyleInterface
with a new methodisValid(): Boolean
. Technically that's a breaking change but this interface is not intended to be actually overwritten by user (and we do not provide any APIs to register such interfaces) so we treat this as an enhancement or bug fix.That PR may break existing tests in case mocking
StyleInterface
in some very specific cases, this should be easily fixed with:Pull request checklist:
@JvmOverloads
,@file:JvmName
, etc).make update-api
to update generated api files, if there's public API changes, otherwise theverify-api-*
CI steps might fail.check changelog
CI step will fail.v10.[version]
release branch fix / enhancement, merge it tomain
firstly and then port tov10.[version]
release branch.Fixes: < Link to related issues that will be fixed by this pull request, if they exist >
PRs must be submitted under the terms of our Contributor License Agreement CLA.