Open srmncnk opened 3 years ago
@tobrun @m0nac0 Can we please have some input here? It looks like both iOS and Android SDKs for Mapbox were considerably re-written for v10. What is the planned strategy for Flutter support, will you still drive this or it is now full on community to start the new package?
I have several projects in Flutter relying on Mapbox and would love to see v10 support. I also don't believe that such an initiative can come to success made by community-only without any official support by Mapbox team/company.
To clarify: I do not work for Mapbox (and I never have), I just contribute to this plugin because I find it very useful and I love Mapbox's maps and map services. Therefore, I obviously can't comment on whether Mapbox plans to provide official flutter support.
But I think it has been suggested before that it's a good idea to reach out to them directly and tell them that you would be interested in official Mapbox flutter support. They may consider providing it, if they see that there's enough interest.
Personally, I do hope to be able to continue contributing to this plugin, but it's greatly dependent on how much spare time I'll have for this, and I can't exactly anticipate that, yet.
Tobrun is a Technical Lead of Mapbox Maps SDK for Android, so I assume he can answer these kinds of questions.
Very interested in a v10 upgrade as well.
Thank you all for reaching out and requesting this! Regarding this project, you could say I wear two different hats:
As a Mapbox employee, I can't make any public statement that Mapbox SDKs will officially support Flutter. I would love to see this project adopt the v10 codebase (lot of cool new features!) and current API surface of this repo is too limited (not able to change style properties for example) but I would also love to see a better approach as the current platform plugins setup (see #140). This would make maintenance almost a breeze when compared to current approach. To get that to work however, it would require a Mapbox commitment to invest into the Flutter ecosystem and Dart language.
@tobrun thanks a lot for the answer, although it doesn't give us much understanding on what to do. Should we start the community project for v10 and hope that Mapbox will commit into supporting it? Or should we rather wait until Mapbox officially commits into supporting flutter?
My project depends heavily on flutter mapbox support and I need to understand how to drive it forward. Current implementation has some very important features missing.
@AAverin
I am in the same boat as you, my project heavily depends on the ability to have a performant mapping solution. I am set on using mapbox. What can we do to get this process started? I have no problem with committing my time to helping to bring v10 access to flutter apps. Even if we have to start from the ground up, I am onboard.
When do we start?
@JMNewsome v10 just got production ready yesterday. Maybe now @tobrun can push a bit internally in Mapbox and give us some kind of clarity on next steps for Mapbox on Flutter? In terms of time commitment, for me it will heavily depend on how well my project will perform after release and how much time I will have on my hands to spend on it. Problem is I can't release due to the bug in current implementation on iOS: https://github.com/tobrun/flutter-mapbox-gl/issues/703
This is actually one other problem I have with future v10. While it looks great it doesn't have offline side-loading support, at least it's not mentioned anywhere. My project requires offline side-loading. So now I am on the crossroads – adopt fleaflet and forget about vectors and 3D or invest into v10 and find a workaround for offline side-loading of map packages.
@AAverin
I understand the situation you have. I don’t mind personally committing a portion of my time with making it, because I strongly need mapbox in general for my app concept. The main issue is I don’t exactly know what I need to do to start it, I’m need to making extensions for flutter, but if there is a general guidelines or resource on how incorporating mapbox v10 into flutter. I don’t mind atleast gnawing at it
@AAverin should we not just add V10 here? The API should not be that different right?
@felix-ht We could try to have a separate branch or tag and keep it in this repo. Still, as far as I understood, SDK were completely re-written and many things most likely changed. So our separate tag or branch would be a parallel implementation of same features differently and using another SDK in native layer.
I agree with @AAverin, looking at the SDK a lot of things have changed and, TBH, maybe part of the wrapper should be rewritten to match the underlying SDK.
The API should not be that different right?
It is :) v10 compared with v9 (android) and v6 (iOS) is a completely new SDK, build from the ground up with new internal technology stack. The main difference from consumer point of view is the adoption of Kotlin/Swift instead of Java/Obj-C in previous version. When it comes to public API, we have tried to bring the APIs across platforms closer together (which should help a lot for this project going forward!).
in Mapbox and give us some kind of clarity on next steps for Mapbox on Flutter?
No definitive answer yet atm but will be able to speak about this in upcoming weeks.
No definitive answer yet atm but will be able to speak about this in upcoming weeks.
Can't wait for some news! We're about to start a cool project using this really cool flutter mapbox plugin, and we'd like to know if it's worth investing porting some APIs on this version or wait for a mapbox-supported plugin a do a minimal POC with this plugin version :-)
Thank you all for your awesome job!! 👏
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Any updates, any hints? @tobrun
Hi @AAverin , did you resolve the problem?
@edofritz I have tried reaching Mapbox through every channel I could find but they just don't respond on any emails or request for meetings and sales requests. I guess they are not very interested to talk to potential customers and I will have to make a decision on my own. There is no side-loading support officially anymore and doesn't look like it will be coming.
@AAverin Well you still could run a local tile server that streams the tiles to mapbox as if it where hosted somewhere.
A Raster tile server would be trivial to do for the xyz format.
For Vector data this might be a good starting point: https://github.com/saigontek/dart-vector-tile
Thanks @felix-ht, I will try to investigate a bit more. My use-case at the moment are pre-generated offline packages that user can download. Packages are exactly the same for all users so it doesn't make sense to generate them on the device. Besides, offline packages on device, the way Mapbox provides it, are a bit limited in functionality not supporting merged maps with variable detail – like have a big area map with one quality and small area maps in smaller quality, all merged into the same package. Mapbox also limits number of tiles that you can download and keep offline.
I don't mind paying for the feature, as long as I can still pre-generate offline packs and let users download, but I can't reach to Mapbox to talk about details, they just don't respond.
Do we have to wait for mapbox to do anything ? It's implementable today without any change on their side, isn't it ? It's a bit unclear when reading the comments here what it is that you want from map box.
I see there is a branch already using v10 https://github.com/flutter-mapbox-gl/maps/commits/kl-v10
Also I think it makes sens to keep this repository if the dart public api stays the same (or close to).
I haven't run that branch yet but looking at the diff it's rather small and seems to cover android only. Maybe author @Chaoba can tell us more?
@srmanc That is a test branch, only can load the MapView with a style using v10
I haven't run that branch yet but looking at the diff it's rather small and seems to cover android only. Maybe author @Chaoba can tell us more?
A full migration would be roughly 5000-10000 lines changed including all of the code gen. The good thing is that most of the stuff should actually be easier to do and might not even need code gen anymore.
I guess that it would be roughly two weeks full time for me (one week for each platform) - sadly i do not have the time to do this right now
Just an FYI (I'm sure everyone got the email), but Mapbox is officially stopping support for pre-v10 of the SDK starting April 4th, 2023:
Hi there,
Our records indicate that you’re using an older version of the Mapbox Maps SDK. We’re writing to let you know that we’ll be ending support for the software you’re using on April 4, 2023, and to ask how we can support your upgrade to the current version of our SDK: Mapbox Maps v10.
We released v10 in early October and have been delighted by the response it’s received. Customers who’ve already upgraded are benefiting from an SDK that’s more performant, easier to work with, and which brings new capabilities like 3D terrain, globe view, and faster offline downloads. You can learn more about v10’s advantages here. Or, to get a better sense of what upgrading will require, have a look at our migration guides (iOS, Android ).
Pre-v10 versions of our SDK will continue to work past April 4, 2023, but that is the date at which we will stop publishing bug and compatibility fixes. It’s also the point beyond which we will no longer be able to guarantee support or compatibility.
We realize that your app might be well-served by the SDK version you’re currently using. The move to v10’s modern foundations will deliver real benefits to you and your users, and its modernized architecture will mean we can continue delivering the best mobile maps experience possible.
We’re eager to help you with this transition. Have a look at the migration guides and please reach out with any questions.
Kind regards, Maps SDK Team
That leaves time but not that much
A full migration would be roughly 5000-10000 lines changed including all of the code gen. The good thing is that most of the stuff should actually be easier to do and might not even need code gen anymore.
Honestly I think mapbox, the company, has to do it themselves. It's a bit much to rely on free work here even if there are workers from the company active here. At the end of the day they are the one who will be compensated, even if our own project will benefit too, it's not like there isn't alternatives. That is, if your assessment of time it would take is correct.
After getting the full scope of the story with maplibre, I think Mapbox as the company needs to build flutter package themselves and all the community work should rather make feature parity between mapbox and maplibre solutions with all the codebase shared, only changing the underlying renderer depending on the license.
Yes, I agree. I guess we don't know at what point they consider Flutter a worthy investment.
yeah i got the same message - this certainly puts somewhat of a eol on the current stack.
We could make the the decision to embrace the split of dart code from the plugins. Meaning that one could make their own choice of which plugin to use for which platform. The Plugin architecture of flutter should make this pretty straight forward
@tobrun Any news to share with us about the state of this plugin? It will be nice to have the leadership of Mapbox to help this community for the migration of this plugin and that it can continue.
Would it be possible to leverage the C++ from v10 on the web too ? This is an area I'm not familiar with but I assume it's not as simple as converting it to wasm and use ffi to do the linking. Maybe some graphic api needs to be accessed etc (I have no idea)?
Just asking because it seems like they tried to convert the js api to wasm 2 years ago but eventually dropped it https://github.com/mapbox/mapbox-gl-js/issues/4835 . With the library powered by C++ you wouldn't even need to go through the hoops of each platform too, would it? It would be straight ffi to dart with no multiplatform questions.
Not possible (or feasible). Primary API is in Java / Kotlin / Swift / Obj-C and JS on web. Core underneath GLNative is C++.
Any news on this? Maybe @tobrun can share some insider details?
As my company is also invested heavily in this plugin and the usage of mapbox, we would be happy to contribute dev time to the development of a new version of the plugin to support v10. However, it would be nice to have some organization to this and someone to at least take leadership, hopefully that could be someone from the Mapbox team.
As my company is also invested heavily in this plugin and the usage of mapbox, we would be happy to contribute dev time to the development of a new version of the plugin to support v10. However, it would be nice to have some organization to this and someone to at least take leadership, hopefully that could be someone from the Mapbox team.
I would be happy to participate, I'm also heavily invested. I think @felix-ht and @AAverin are doing a fantastic job running this repo. If they're not available, someone with enough oversight about the new SDK would suffice as well. AFAIK they're not from the Mapbox team. But @tobrun is.
I recently took a more throughout look at the changes required for iOS. It actually seems quite manageable, as most of the code should be reusable - and some parts like the expression parsing are way less complicated.
The poll on Android is still out but as long as we stick with java the situation should be quite similar.
We should be able to keep the API mostly stable - which is great.
Overall I estimate 2-4 weeks fulltime effort from my side to port everything we have right now. Sadly I don't have that kind of time at the moment. I know the library quite well, for others it might be trickier.
That sounds promising. Do you think https://github.com/flutter-mapbox-gl/maps/commits/kl-v10 would be a good starting point or should we do this from scratch?
I can easily contribute for Android and iOS as I know my way around there, with some effort probably web as well. Maybe we should consider including https://github.com/andrea689/mapbox-gl-dart/ into the repository, since web moved ahead and supporting this outside the repo is quite hard? @andrea689
What would it take to come up with a roadmap or a list of tasks to be done which @MatthewPatience and anyone interested could takle? Maybe we could port kl-v10 branch to iOS and start from there?
On a side note my company is committed to flutter and mapbox - so if there is no repose from mapbox I will make sure that the port to v10 happens. @tobrun
If there is support from the community all the better - as we could split the effort. I can take leadership in that case as well.
I think we should wait for some response from @tobrun as my understanding was that Mapbox plans to commit into official Flutter support of v10. Doesn't make much sense to have several implementations. In terms of how to do it, FFI looks like an interesting option and mapbox-flutter could be running on top of mapbox-gl instead of separate android/ios implementations.
My company is also fully committed to Flutter & Mapbox, but we are not yet profitable and run it with my partners as a side-job. So I would be able to contribute, but at a limited extent. Although I don't believe such a big project as maps can be run on a pure community basis, there has to be some backing support of bigger companies, kind of like it works with Blender, for example.
In terms of how to do it, FFI looks like an interesting option and mapbox-flutter could be running on top of mapbox-gl instead of separate android/ios implementations.
AFAIK the 10 API is built entirely (or mostly) in pure Java/Kotlin and Swift code, C++ was largely abandoned.
Any kind of feedback from Mapbox would of course be highly appreciated, but given the current history I have my doubts they would commit to this in the near future. I wish I was wrong though.
I completely agreed and aligned with the above discussion about the v10 upgrade. I am also happy to contribute as per my limited capacity.
Should we try open collective or any other options to fund/support the maintenance and upgrade?
Thank you for reviving this thread and for all the contributions you’ve made to the flutter-mapbox-gl repository. I can share that we are working on a v10 equivalent Flutter SDK and will share an update in the next 2 weeks on timing.
Thank again,
Tobrun
Thank you for reviving this thread and for all the contributions you’ve made to the flutter-mapbox-gl repository. I can share that we are working on a v10 equivalent Flutter SDK and will share an update in the next 2 weeks on timing.
Thank again,
Tobrun
Great to hear! Is this an official SDK from Mapbox, or unofficial like the current plugin?
official SDK from Mapbox,
Yes! :D
@tobrun that's very exciting, can you share at this time if it will also support web?
Any forecast would be highly appreciated :)
I am usually a silent lurker but this is great new to hear, thank you guys so much for the contributions on this project!
@tobrun Sounds amazing, will this plugin cover Navigation SDK? Thank you!
Thank you @tobrun, looking forward to the timeline, as we wanted to rely heavily on mapbox with our new flutter application.
Any plans on supporting v10?
https://docs.mapbox.com/android/beta/maps/guides/migrate-to-v10/ Looking at the migration guide it seems that there is not much sense in migrating but rather creating a new repo to back the v10 API, since the entire codebase had changed significantly.
Or is there anybody else who's doing the migration somewhere else?