Idea: Map UI Library

[isaac]

We could probably get some ideas from React Native:

https://facebook.github.io/react-native/docs/mapview.html
https://github.com/lelandrichardson/react-native-maps

Thoughts?

[MarkVillacampa]

This is definitely something we should app.

I will add this little library I made to abstract Google/Apple maps api on iOS. It might me useful as inspiration for the Ruby api.

https://github.com/cabify/motion-maps-wrapper

[jjaffeux]

@MarkVillacampa should it use default map sdk on each platform (apple map on iOS/google map on android) ? use google map sdk on both (we would have to vendor map sdk on iOS, or introduce cocoapods) ? leave the choice and build an abstraction on top of it?

[isaac]

@jjaffeux IMHO by default it should use the native map SDKs on iOS and Android - that way it wouldn't require any extra dependencies. I hadn't thought about supporting the Google Maps SDK on iOS as well but maybe that would be nice.

@MarkVillacampa thanks - motion-maps-wrapper looks good. Are you pretty happy with that API or would you make some changes if you were starting again from scratch?

[lrz]

I looked into that recently. It appears that Android does not have a map API builtin, you have to vendor a giant library to get google maps. On iOS of course there is MapKit but indeed some users may want to use google maps instead, especially in the case of a Flow app where cross-platform (and consistent UX) is key.

So my recommendation would be to provide a Flow map API that is based on google maps and make it optional because of the huge dependency (we probably don't want to bundle the google maps library by default).

[jjaffeux]

agreed

Envoyé de mon iPhone

Le 15 juin 2016 à 17:53, Laurent Sansonetti [email protected] a écrit :

I looked into that recently. It appears that Android does not have a map API builtin, you have to vendor a giant library to get google maps. On iOS of course there is MapKit but indeed some users may want to use google maps instead, especially in the case of a Flow app where cross-platform (and consistent UX) is key.

So my recommendation would be to provide a Flow map API that is based on google maps and make it optional because of the huge dependency (we probably don't want to bundle the google maps library by default).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[jjaffeux]

@MarkVillacampa Could you give me your opinion on this please ? as a big map user, what do you think of dropping apple map support?

The biggest cons I see is related to licenses, api key rate limits, and things like that...

[isaac]

@lrz I can understand that some developers may want their Flow app to have a consistent UX cross-platform. For me it is more important that my apps integrate well with the native OS. More iOS users use the Apple Maps app than Google Maps app and they are already familiar with the Apple Maps UX.

[isaac]

What is the best way forward here?

On iOS I can see how it would be useful to support both Apple and Google maps. I am happy to start working on an abstraction that supports both APIs but I have no plans to actually use Google maps in my own iOS apps.

[jjaffeux]

@isaac I'm waiting for mark point of view, and then we will see what we can do on this subject.

[lrz]

Maybe we could have 2 implementations for the Map API on iOS? One that uses MapKit and one that uses Google Maps? Obviously you would need to select which one you wanna use in the Rakefile.

That sounds like extra work, but if the API is simple enough maybe it won't be such a big deal. And it will please everyone.

[isaac]

@jjaffeux - thanks - I am definitely keen to hear from @MarkVillacampa too

@lrz - sounds good - I just want to clarify what you mean - this is my understanding:

We have one abstract public Map API that is usable from Flow. This API has 3 implementations - which one is used depends on the platform and Rakefile configuration:

1. Google Maps on Android
2. Google Maps on iOS
3. Apple Maps (MapKit) on iOS

Does that sound right? (sorry if this is obvious - I just wanted to double-check we are talking about the same thing)

[lrz]

Yep that would be it :)