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

Style.java #13484

Merged
merged 31 commits into from
Dec 10, 2018
Merged

Style.java #13484

merged 31 commits into from
Dec 10, 2018

Conversation

tobrun
Copy link
Member

@tobrun tobrun commented Nov 30, 2018

This PR introduces the concept of Style.java to mimic style.hpp from core. All style related methods are moved to the style class vs mapboxmap. OnMapReady will now be invoked when the map surface is created. Styles are composed together using a builder class and allow for a more flexible build up of your style.

For example the following code snippet allows you to only define a background and symbol layer with a geojson source (this without loading another style as mapbox-streets).

mapboxMap.setStyle(new Style.Builder()
         .withLayer(
           new BackgroundLayer(“bg”)
             .withProperties(
               backgroundColor(rgb(120, 161, 226))
             )
         )
         .withLayer(
           new SymbolLayer(“symbols-layer”, “symbols-source”)
             .withProperties(
               iconImage(“test-icon”)
             )
         )
         .withSource(
           new GeoJsonSource(“symbols-source”, testPoints)
         )
         .withImage(“test-icon”, markerImage)
       );

Generates the following output:

image 2 2

Todo:

  • add javadoc style.java
  • add sdf support to Style.Builder#withImage()
  • add below/above layer support to Style.Builder
  • fix LocationComponentTest
  • decouple style from NativeMapView

Tailwork after merge:

@tobrun tobrun added the Android Mapbox Maps SDK for Android label Nov 30, 2018
@tobrun tobrun added this to the android-v7.0.0-iowaska milestone Nov 30, 2018
@tobrun tobrun self-assigned this Nov 30, 2018
Copy link
Member

@LukasPaczos LukasPaczos left a comment

Choose a reason for hiding this comment

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

This looks great, thanks a lot for the huge lift @tobrun!
A couple of notes:

  • It'd be great to check the code for missing nullability annotations.
  • Can we guard all of the add/remove methods on the Style object from being called before the style has been loaded? We can go as far as throwing an exception. Exposing the Style#styleLoaded flag could be useful as well.
  • Since we are coupling the concept of adding images via the Style, would it make sense to remove all of the images added with this style during the cleanup? Or should we rather separate those concepts?
  • Assuming there is no other way of handling the detached state besides the flag, would there be a way of keeping this flag in the core, and having it set on all of the sources within the style during the cleanup? This would guard all of the sources/layers, not only those added in the runtime.

}

// TODO add SDF support!
public Builder withImage(String name, Bitmap image) {
Copy link
Member

Choose a reason for hiding this comment

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

Now that I think about it, it'd be great to expose a Drawable overload of this method and generate a bitmap out of it just before adding it to the map to possibly minimize the time we are keeping bitmaps in the Java memory.

Copy link
Member Author

@tobrun tobrun Dec 4, 2018

Choose a reason for hiding this comment

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

Let's ticket this as follow up work once the base version of this has landed

@@ -1139,7 +1062,6 @@ public void cancelAllVelocityAnimations() {
OnCameraIsChangingListener, OnCameraDidChangeListener {

private final List<OnMapReadyCallback> onMapReadyCallbackList = new ArrayList<>();
private boolean initialLoad = true;

MapCallback() {
Copy link
Member

Choose a reason for hiding this comment

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

I believe MapCallback can be reworked to use a provided MapboxMap object and avoid null checks.

Copy link
Member Author

@tobrun tobrun Dec 4, 2018

Choose a reason for hiding this comment

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

I wasn't able to workaround the nullability, MapCallback needs to be created when MapView is created and at that point MapboxMap isn't created yet. This is needed to hook up the onMapReadyCallbackList. Only way forward afaik is to decouple MapCallback into a couple of concrete classes that have different lifespan/scopes.

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't feel this is worth picking up now but we should ticket this out and pick up in near future. This is an internal refactor that won't impact the public API.

@@ -1337,6 +1345,11 @@ public void run() {
});
}

// TODO remove dependency of Style on NativeMapView
Copy link
Member

Choose a reason for hiding this comment

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

I'm in favor of this. Maybe we can move it to the MapboxMap?

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 must addressed before merging this PR! Still need to look into this.

* @param image the image to be added
* @return this
*/
public Builder withImage(String id, Bitmap image) {
Copy link
Member

Choose a reason for hiding this comment

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

We are missing withImages method.

Copy link
Member Author

Choose a reason for hiding this comment

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

Atm we also don't support withLayers or withSources either but could make sense.

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe postponing this into a follow up ticket as well? trying to cut some corners to merge this before our branch cut.

Copy link
Member

Choose a reason for hiding this comment

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

Sounds good.

@tobrun
Copy link
Member Author

tobrun commented Dec 4, 2018

t'd be great to check the code for missing nullability annotations.

Can we guard all of the add/remove methods on the Style object from being called before the style has been loaded? We can go as far as throwing an exception. Exposing the Style#styleLoaded flag could be useful as well.

I went with a different approach, style remains null until it has fully loaded (see #13484 (comment)).

Since we are coupling the concept of adding images via the Style, would it make sense to remove all of the images added with this style during the cleanup? Or should we rather separate those concepts?

This would be indeed a good idea, this would also allow us to call recycle on the bitmaps passed to the builder.

Assuming there is no other way of handling the detached state besides the flag, would there be a way of keeping this flag in the core, and having it set on all of the sources within the style during the cleanup? This would guard all of the sources/layers, not only those added in the runtime.

Yes, 💯 this needs to be added to the jni layer and not java.

@tobrun
Copy link
Member Author

tobrun commented Dec 4, 2018

With 134a8bb4b4281020486b3ac5b7c98dae7931bb1a I'm removing the dependency of Style.java on NativeMapView (see #13484 (comment)). This however also results in adding MapView as dependency on MapboxMap, which I'm not happy about either. MapboxMap can't be used as it doesn't have access to the required listeners..

Alternative might be to introduce a new interface that is used in NativeMapView to at least decouple Style.java from NativeMapView but I'm torn...

@tobrun tobrun force-pushed the tvn-style-java branch 2 times, most recently from 1159877 to ac6f912 Compare December 5, 2018 13:21
@tobrun
Copy link
Member Author

tobrun commented Dec 5, 2018

Revisited #13484 (comment), with ac6f912

Copy link
Member

@LukasPaczos LukasPaczos left a comment

Choose a reason for hiding this comment

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

I've looked through all of the demo activities and it seems like most of them could use a local Style field to avoid all of the null warnings from the IDE. This is not a high priority and can be tackled separately.

What I also noticed, is that setting a style via MapboxMapOptions is not really useful anymore as we are not restoring the style anyway. Can we drop that option as a part of this PR?

Otherwise, it looks great!

Copy link
Member

@LukasPaczos LukasPaczos left a comment

Choose a reason for hiding this comment

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

I think we're done here, thanks for the awesome work @tobrun! 🎉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Android Mapbox Maps SDK for Android beta blocker Blocks the next beta release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants