Plans on creating library about react-native-maps

[lelandrichardson]

Hey @christopherdro, as I mentioned in the other issue, the goal here is to get this merged into RN proper. If that does not happen, I have no problem exposing this as a library. In fact, it might make sense to do so anyway?

[christopherdro]

I could imagine it taking some time to get merged into RN proper. Have you already talked to anybody about that already? @nicklockwood Would be the best person to reach out to if you haven't already.

I'm just stuck on making a choice on what to use moving forward with this project since we need something that will be production ready in 4-5 months.

Exposing it as a library would help just to get more people to use it and test it out and help get it ready for RN proper.

[nicklockwood]

It looks like you support a similar feature set to our existing iOS MapView, but with a bunch of functionality not yet available in Android.

To merge it in, we'd first need to try to unify the API with what we already have in iOS, so we don't break existing apps. After that we could probably merge in the Android stuff fairly painlessly.

[lelandrichardson]

I discussed it a bit with brent vatne and some others, and they seemed okay with merging this in as a breaking change with a code mod to upgrade apps. The feature set should cover everything that's currently in the MapView, it's just a different API. I know that Vjeux has mentioned that a child-based API like the one this one has would be preferred moving forward.

There is a possibility we could write some code in the mapview js file to look at the props passed in, and if they are passing in annotations, we could throw a deprecation warning, as well as map the annotations prop to children in the correct way.

[lelandrichardson]

nevertheless, I do think that publishing this repo on NPM in the near-term is not a bad idea. The main thing is that animations will not work properly, as AnimatedRegion is required to be added to AnimatedImplementation.js

[christopherdro]

@lelandrichardson Going to be looking through this today. Let me know if I can help in any way.

[lelandrichardson]

@christopherdro right now there are two things that are missing/broken on the android side:

1. The image prop on the <Mapview.Marker /> component is supposed to work like this:

<MapView.Marker coordinate={...} image={require('./path/to/some-icon.png')} />

This currently works for iOS, but doesn't for android. I've tried but can't seem to get it working.

1. When rendering views to bitmaps in android to be placed on the map, it seems to render views with transparent borders incorrectly. The custom callout view and marker views are examples of this, where the "carrot" at the bottom is made by having a view with one colored top border, and the rest of the border sides transparent. This works fine if the views are outside of the mapview.

[christopherdro]

@lelandrichardson I get error when trying to load an example from android.
Attempt to invoke virtual method 'void com.google.android.gms.maps/GoogleMap/sms/maps/GoogleMap$InfoWindowAdapter)' on a null object reference

Error is coming from:
https://github.com/lelandrichardson/react-native-mapview/blob/master/android/app/src/main/java/com/rn_mapview/AirMapView.java#L66

Are you on discord or slack at all?

[lelandrichardson]

@christopherdro which example are you loading?

[christopherdro]

All examples besides "Custom Markers" and "Animating with MapViews".

Error on Animated is what we discussed earlier.

Custom Markers throws:
undefined is not a function (evaluating 'resolveAssetSource.getPathInArchive(asset)'
https://github.com/lelandrichardson/react-native-mapview/blob/master/examples/MarkerTypes.js#L56

[lelandrichardson]

The animated stuff will break in examples that use AnimatedRegion at all. When i get a sec, I'll update the readme with detailed instructions on this. Essentially, you need to make sure that AnimatedRegion is added into AnimatedImplementation.js and exported as Animated.Region. Further, Animated.multiply and Animated.add are both likely needed, which can be found on RN's master branch in AnimatedImplementation.js.

The resolveAssetSource issue in CustomMarkers... is this only throwing on android? or ios too? Some of this code is there from me experimenting with the android image prop.

[christopherdro]

I'm currently on master. I'll try and add AnimatedRegion.

The resolveAssetSource is on both platforms.

[christopherdro]

@nicklockwood Thanks for chiming in!

[lelandrichardson]

@christopherdro i can set up a gitter room for this repo if you want to discuss more real-time there?

[christopherdro]

👍 Sounds great!

[nicklockwood]

@lelandrichardson resolveAssetSource is called automatically for image props in iOS thanks to the machinery in requireNativeComponent.js - I don't think that's the case for Android.

[nicklockwood]

@lelandrichardson I take a stricter view on breaking changes than some, because I feel that it's important to the success of the project for people to have confidence that we won't break their apps or workflow unnecessarily.

That doesn't mean that we should be afraid to make improvements to the API if we see the opportunity to do so, but we should try to maintain continuity where possible by having at least a period of overlap where both the old and new APIs will work concurrently.

That will be a little more work for us, but if it reduces confusion and frustration for other users of the project then I think it's worth it.

My criteria for success here are:

1. No functionality is lost
2. All existing code that uses maps will preferably continue to work unmodified, but failing that will at least produce a clear error explaining the necessary steps to get it working again
3. All API changes are better for the developer experience, not just more expedient for the implementation

[mkonicek]

Does the Android implementation use both Google Maps and Mapbox? https://github.com/lelandrichardson/react-native-mapview/blob/master/android/app/build.gradle#L80

Are both of them needed? The internal one we use in Ads Manager only uses Google Maps.

[christopherdro]

@mkonicek Google maps, the mapbox library just needs to be removed.

The main issue we came across yesterday is using the deprecated getMap instead of getMapAsync.

According the @lelandrichardson, this will be a show stopper because the props would already be sent over before we receive the OnMapsReadyCallback.

[christopherdro]

@satya164 Could you maybe offer some input with your Android expertise on how we might be able to replace getMap with getMapAsync?

Here is line where it gets called.

[lelandrichardson]

Using getMapAsync is doable, but complicates the implementation quite a bit. I had gotten everything working with getMap, so I thought we were in the clear - but it seems that some devices this will not work for.

The problem is if it is async, then we need to build the component in such a way that none of the props are set on the component until the map is present. I think the best approach is to handle this in JS with an isMapReady state variable or something, and then not pass in the props until we know it is ready... This could be done just for android.

[lelandrichardson]

@nicklockwood totally agree about breaking changes. If this is decided to be moved in, I think we can minimize the damage by doing the following:

1. building a code-mod to fix deprecated code
2. make a best-effort to making props on the old version (namely annotations) deprecated with a yellow-box warning, while attempting to make them still work in the same way by mapping annotations => children. Include a link to the codemod in the deprecation warning.
3. remove deprecation-fixing code in next release.

That said, I think a lot of the react-native team seems to be in the camp right now where we just gut the RN MapView implementation entirely, forcing people to rely on 3rd party libs (like this one).

[nicklockwood]

@lelandrichardson

I think we can minimize the damage by doing the following...

Agreed

That said, I think a lot of the react-native team seems to be in the camp right now where we just gut the RN MapView implementation entirely, forcing people to rely on 3rd party libs (like this one).

That doesn't really make sense from an FB perspective, as we rely on MapView in several of our internal apps, and we don't currently have a good way to use 3rd party RN modules in our own codebase, other than forking them and maintaining our own copy anyway.

I agree that for components that we aren't using and have no interest in maintaining, it makes sense to remove them from the core. I just don't think MapView falls into that category :-)

[christopherdro]

I think the best approach here might be to work on making the proper changes to get this merged into RN, especially if current MapView is going to stay in core.

To avoid having the maps library included with every installation, we can have developers manually add it, similar to PushNotificationsIOS.