ROADMAP / Plans for the next major release - 2.0.0

[cusspvz]

Project Collaborators:
@EddyVerbruggen @cusspvz @Anothar @dagatsoin

Refactoring:

• [Issue #] Base native events trough an initial event listener callback for each map instance
• [Issue #] Use latest ES methods on JS file

Features:

• [WIP [WIP] [Next version] #29] overlay DOM html elements
• [Issue #] Map / Marker class API exposure

Maintenance:

• [Issue #] Move iOS code to Swift

[dagatsoin]

• I propose to add multi maps on the feature list as it is almost done.
• You can also add offline maps as it already works.
• As the api surface will be extended and the implementation will be bigger, I think unit test could be useful.
• A bit of doc will be useful to explain how the plugin work. (cf. "google map box cordova plugin" as my implementation is globally the same.

[dagatsoin]

I would like to talk about the motivation of what I have done on #29 to synchronise (or not) our goals.

Motivations

• I needed an offline map plugin for Wizar, an HTML 5 game (only in french for now, sorry):
  So basically, I overlay the Mapbox view with a webview within I run the game interface (with React) and Pixi.js (and I aim Three.js in the futur). The good thing is you can use any DOM element as marker.
• I needed offline map functionality. So I needed to bump the Mapbox API.
• I also need to display two maps at the same time (game map + mini map). So I have developed my plugin by looking at [WIP] MapboxGL Android 4.x.x #22.

Architecture overview

• I stick to MapboxGL JS naming to have a drop in replacement.

• The plugin controller: CDVMapbox.java:

  1. receives the command
  2. retrieves or creates a Map through MapsManager.java
  3. treats the command through the Map
  4. sends the result

• The maps manager: MapsManager.java:
  creates/retrieves/deletes a Map

• The map: Map.java + MapController.java
  Those two files will be certainly merged in just Map.java
  They handle the Mapbox API.

• PluginLayout.java
  Responsible to arrange the views to have a webview overlay (cf google map plugin wiki)

Remaining

• iOS conversion (Swift is a good idea, but what about the futur version ? Is there any risk of retro incompatibility? I heard major swift versions are not compatible)
• Unit test
• Docs
• Finish multi maps (the overlay touch part)
• A better UI demo
• MarkerCallbacks per marker.

Here it is. Is the direction I took is OK for you?

[risinghero]

Absolutely okay! You 've done so much funtionality... Maybe you can provide some guidance on smooth transition from current state of the art to functionality implemented by you? Damn-github answer from email is not removing citing previous email.

[risinghero]

Hi @dagatsoin

Swift is a good idea, but what about the futur version ? Is there any risk of retro incompatibility? I heard major swift versions are not compatible

Yes there is although they promised to make full binary compatibility in next major release.
But I think transition to swift worth this risk as coding will become much simpler (as well as studying iOS code). And amount of iOS code will decrease significantly.

[dagatsoin]

Guidance: what do you mean by guidance? Maybe a more detailed doc? On which part exactly?

Swift: OK let do it! Always wanted to try it!

[risinghero]

I mean that you' ve done a lot of work and very large piece of functionality.
For me the problem as I see is how to integrate you branch smoothly in master?
I don' t think that it can be done by one piece. Maybe @cusspvz have some ideas about integration.
What I want is to discuss step-by-step integration of your code in master.
To divide it in small pieces. Maybe you have ideas how it can be divided?

[dagatsoin]

Ok I see but I have not develop my PR for being integrated in the master branch. As a major release, it contains breaking changes both on the JS and native side.

I am not used to versioning management but I guess we should transfer my PR in a next branch and finally completely replace master branch when ready. @cusspvz your thoughts?

[warrenc5]

I agree with dagatsoin - I suggest that the all these experimental MapBox PRs are merged into an experimental/unstableTelerik Branch here.
At least that will be a single integration point for all these changes & refactorings.
Great work so far.