-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[ios] Added "pending" completion blocks #15122
Conversation
Another FYI @astojilj |
That would be convenient to user, but don't think we can guarantee it now in general case,... we would need to wait for all the tiles to get loaded and collision index updated. Given the multithreading plans (placement, render, upload, split to threads), I don't think we can count that the approach with pending completion would work with the failing MGLAnnotationViewIntegrationTests.testSelectionMove*** tests. How about using dispatch_group to wait in internalTestOffscreenSelectionTitle? |
@astojilj is there a callback when the collision index is updated? |
@friedbunny @astojilj Thinking about this further - I believe this is sufficient for view annotations. @friedbunny would you mind checking my logic please? |
Conceptually this looks OK to me, but do we have a way of verifying this in tests? |
We could add that - would it be preferred.
@julianrex , I agree - and we'll have all integration tests passing to verify it. |
See #15440 for @pozdnyakov's POC
Yep, this fixes the 3 failing integration tests ( EDIT: Also looking at adding some tests to ensure the completion block is called as expected. |
89853dd
to
878c402
Compare
|
…) annotation views are in the position they are expected to be at the end of an animation.
6caf818
to
93fd2ed
Compare
Draft PR to experiment with pending completion blocks.Without this several annotation selection integration tests were failing:
This is because the completion blocks introduced in #14381 are called before the annotation view's positions have been updated.
I think the user's expectation will be that when the completion block has been called, that the annotations are in their correct and updated position.
This same mechanism could be use for camera/region changes, but we need to investigate @pozdnyakov's #15086 first.
@friedbunny would love your thoughts here.