Yeah… fingers crossed.
I’ve been working on a big project since the last June… a lot of effort poured into it. I hope I can migrate my current project before I make an initial release in a few weeks.
I’m gonna be building an app with Google Maps and tracking functionality in the following months. I would really like to try out Capacitator and I’m wondering if anyone here already used the Capacitators Google Maps plugin in a real-world app? Does it have any drawbacks, bugs, etc.?
P.S. Josh Morony has an tutorial about using GMaps with Capacitator and I’m gonna try it out tommorrow. Here’s a link to the tutorial: https://www.joshmorony.com/using-google-maps-and-geolocation-in-ionic-with-capacitor/
Let me know how it goes with capacitor and Google maps I’ll jump on it too
There isn’t any “Capacitators Google Maps plugin” I think. You don’t need one, you could/should just display a google map with the help of Javascript
There is a “Capacitor Geolocation Plugin”, I didn’t tested it, can’t give you a feedback about it.
I did test successfully the Camera and File plugin, so far so good 
Great… can’t wait for Capacitor beta version release.
Some more information on that:
- Capacitor also has “external” plugins - but there is none for Google Maps yet.
- Capacitor also support Cordova plugins, but the Google Maps Cordova plugins are pretty complicated so it is very probably that those won’t work (yet).
- But yes, of course you can just use the JS variant of Google Maps if this is good enough for your app (it is in 90% of all cases).
@Sujan12 totally correct, thx for giving more information
Regarding of the member of Capacitor project, they does not want to support the compatibility with cordova fully.
Because of this, the maps plugin having troubles, the maps plugin author (me) decide it does not support the Capacitor.
Sorry to hear it @wf9a5m75 . Your Google Maps plugin is light years ahead of the standard JavaScript plugin as far as quality. Bummer.
Tell me if I’m wrong, but with Cordova user has to intall the map plugin submitting --variable while installing the plugin or has to add manually these variables in config.xml right?
In Capacitor, there isn’t any config.xml, so instead user would had to configure these variables, again manually, not there but direct in the AndroidManifest.xml of his/her project (platform which is created only once, not like in cordove where often we remove/add our platforms again)
Do I understand something wrong? If not, for me it’s just meant that as a user I would had to modify something in file B instead of file A and that the plugin is supported, but mabye I totally don’t understand and miss the point?
What I said, the Capacitor ignores <config-file target="..."> definition on installing.
I didn’t talk about variable.
The variable $API_KEY_FOR_ANDROID is specified in package.json.
But if you say the Capacitor keeps the compatibility with Cordova, Cordova plugin developer expects the Capacitor follows the same rules from the plugin.xml.
That’s why I reported.
However the member said the Capacitor is capacitor, not Cordova. So this won’t be implemented.
I don’t want to ask to modify the AndroidManifest.xml to users. That’s why I don’t support the Capacitor.
I could understand that to some extension
Well in case of this plugin, again if I understand correctly, it’s just about adding a couple lines manually in AndroidManifest.xml. If it’s indicated in the README I don’t see the big deal in this special case, I would be ok to live with that. Your plugin your choice, maybe one of your users someday will provide a PR to enhance the README about it
Btw. I mark this thread I opened as solved. Version Alpha is out, so alpha is out
Yes, “my plugin is my choice”, that’s why I didn’t test Capacitor. I don’t care it.
But there are many people who use ionic framework because of @ionic-native/google-maps (my plugin wrapper) is also true.