Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

[android] - Refactor dependencies, introduce focused components #7189

Merged
merged 2 commits into from
Dec 6, 2016

Conversation

tobrun
Copy link
Member

@tobrun tobrun commented Nov 25, 2016

WIP to refactor all gesture related code into a separate wrapper.

  • extract code from MapView and make it work
  • minimize internal dependencies on GestureDectector
  • remove MapView related methods, talk to NativeMapView directly.

update: intent has changed from initial creation see below

@tobrun tobrun added Android Mapbox Maps SDK for Android refactor ⚠️ DO NOT MERGE Work in progress, proof of concept, or on hold labels Nov 25, 2016
@tobrun tobrun added this to the android-v5.0.0 milestone Nov 25, 2016
@tobrun tobrun self-assigned this Nov 25, 2016
@mention-bot
Copy link

@tobrun, thanks for your PR! By analyzing the history of the files in this pull request, we identified @ljbade, @bleege and @cammace to be potential reviewers.

@ivovandongen
Copy link
Contributor

@tobrun There are indeed a lot of inter-dependecies. And also some 2-way dependencies. It might be helpful for the clarity of the architecture to abstract some things a little bit more. For example,

  • The MapGestureDetector has a dependency on MapView, which actually is only passed to the ZoomButtonsController as far as I see which only expects a View, not a concrete class like MapView.
  • In case of the MapboxMap dependency, it's actually the Transform, Projection and UISettings you're after.
  • The NativeMapView dependency is needed for 2 things; to get the pixelRatio/pitch and to control and to effect the gestures on the Map. You might want to abstract the second repsonsibility in an Interface.

There might be a couple of places where interfaces/choosing the highest applicable abstraction might help to clear up the dependencies a bit.

@tobrun
Copy link
Member Author

tobrun commented Nov 30, 2016

The MapGestureDetector has a dependency on MapView, which actually is only passed to the ZoomButtonsController as far as I see which only expects a View, not a concrete class like MapView.

Thinking about this again, the zoombutton controller is more like a widget shown on top of the map, I moved this back to MapView with the other widgets. These will be extracted as part of #6570.

In case of the MapboxMap dependency, it's actually the Transform, Projection and UISettings you're after.

I tried to limit the amount of arguments but not assigning mapbox to field in the MapGestureDetector. I have now changed this to take each dependency seperatly.

The NativeMapView dependency is needed for 2 things; to get the pixelRatio/pitch and to control and to effect the gestures on the Map. You might want to abstract the second repsonsibility in an Interface.

I'm now working to remove the NativeMapView in total, the second responsibility should be made a part of the transform class since they transform the map.

Thanks for some initial 👀, will ping again for second round.

@tobrun tobrun force-pushed the tobrun-refactor-gestures branch 2 times, most recently from 0858b86 to 09dd4b8 Compare December 2, 2016 11:52
@tobrun tobrun changed the title [android] - introduce GestureDetector wrapper [android] - Refactor dependencies, introduce focused components Dec 2, 2016
@tobrun tobrun removed the ⚠️ DO NOT MERGE Work in progress, proof of concept, or on hold label Dec 2, 2016
@tobrun
Copy link
Member Author

tobrun commented Dec 2, 2016

The goal of this PR has diverged from it's initial intent, changes made cascaded in changes elsewhere. This PR is now more focused on a general refactor and taking apart the big dependencies into smaller single focused dependencies. This PR adds a lot of todo to the code but current state is acceptable to merge. (we are only missing the snapshot feature, the jni code needs to be refactored and can be picked up with #6238). Focus of Review would be MapboxMap, MapGestureDetector, MapKeyListener, Transform, TrackingSettings and UiSettings. To make the refactor possible I had to remove some unit tests.

Copy link
Contributor

@ivovandongen ivovandongen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work @tobrun! Cleans things up nicely. Just a few minor details.

If at all possible, it would be nice to re-implement the removed unit tests on top of the new abstractions.

public MarkerViewManager(@NonNull MapboxMap mapboxMap, @NonNull MapView mapView) {
this.mapboxMap = mapboxMap;
public MarkerViewManager(@NonNull ViewGroup container) {
this.markerViewContainer = container;
this.markerViewAdapters = new ArrayList<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The initializations that have no dependencies might as well be done in the field declaration. That also enables us to make them final and maybe skip some null checks here and there.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this.iconManager = iconManager;
this.infoWindowManager = manager;
this.iconManager = new IconManager(nativeMapView);
this.infoWindowManager = new InfoWindowManager();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initialize in field declaration

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (view != null) {
// null checking needed for unit tests
view.addOnMapChangedListener(this);
}
}

// TODO refactor MapboxMap out for Projection and Transform
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's note these things on #6912 as well. I'm planning to pick that up soon.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*/
boolean onGenericMotionEvent(MotionEvent event) {
// Mouse events
//if (event.isFromSource(InputDevice.SOURCE_CLASS_POINTER)) { // this is not available before API 18
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stray comment?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems not.. after that line it indicates: // this is not available before API 18, so it's there waiting for us to bump the minSDK requirments? IDK, this code is from before my time.

if (isInEditMode()) {
// if we are in an editor mode we show an image of a map
LayoutInflater.from(context).inflate(R.layout.mapbox_mapview_preview, this);
return;
}

// TODO distill into singular purpose methods/classes
initialLoad = true;
onMapReadyCallbackList = new ArrayList<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initialize in declaration

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tobrun
Copy link
Member Author

tobrun commented Dec 2, 2016

I have worked in the requested changes and working now on getting tests back up and running where possible. BTW biggest issue I had with this was not being able to mock final classes, looking into upgrading to mockito 2 for that.

@tobrun
Copy link
Member Author

tobrun commented Dec 2, 2016

I got the important tests back to run by using mockito 2 configuration for mocking final classes. Though I wasn't able to bring the MapboxMap test since they rely on NativeMapView (which relies on loading the native library). I'm thinking of porting those tests to an instrumentation test equivalent. I think we are covered for now. @ivovandongen can you do another review round?

@ivovandongen
Copy link
Contributor

I wasn't able to bring the MapboxMap test since they rely on NativeMapView (which relies on loading the native library). I'm thinking of porting those tests to an instrumentation test equivalent. I think we are covered for now.

Let's open a follow-up ticket for that then.

@@ -31,512 +34,482 @@
import static org.mockito.Mockito.when;

public class MapboxMapTest {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just use @ignore on the class for now? Or does that make it crash. Makes it more visible that we need to do some work here.

@tobrun
Copy link
Member Author

tobrun commented Dec 5, 2016

@ivovandongen I have actually now have ported all the unit MapboxMapTest to an instrumentation equivalent. Can you review?

update: need to revisit this implementation since they occasionally fail. The reason seems related to the issue we have had with add/remove source/layer test.

@tobrun
Copy link
Member Author

tobrun commented Dec 6, 2016

I'm running the Android job multiple times on Bitrise to ensure we aren't introducing any flaky tests.

update: seeing flaky tests, going to revisit the implementation.

@tobrun
Copy link
Member Author

tobrun commented Dec 6, 2016

Not seeing any immediate fixes, going to ignore the MapboxMapTest and create a follow up ticket.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Android Mapbox Maps SDK for Android refactor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants