Yes, I was a bit too quick about it and compared that to the online docs, which say the current version is 2013.2076.
Looking at the logs I suspect some nil checks are to blame. How would I check a returned timer handle, whether it has been set or not, and how do I check a returned marker id whether a marker has been placed or not?
No, my code checks out. The marker bug is still there in 2013.2100, and it’s a bug. I just discovered that when this marker position goes off, the hitbox for the touch event is still in the correct place and triggers a callout correctly which “points” to the co-ordinates supplied it. I’ve filed the bug.
@nmichaud, I think I’m walking in your footsteps. Would love to hear if you were able to overcome the Android challenges and also how you handle the marker tap events. Thanks for anything and everything you might be able to share.
@Ksan, it seems that on Android, we need to use some timer before calling some of the map api. As for pin that sometime were offset, this is a bug with some Android version only. Corona was never able to replicate this on their side. On our Galaxy s3 we can reproduce any time bad marker position.
I have remove useless code from our app and show you how we deal with marker. I don’t know if this what you are looking for. If not, ask, we have been working with map forever 
– ************************************************************************
– Update all pins in our map
– ************************************************************************
local function _updatePins()
if scene.googleMap then
– We always center the map based on our first visible pin in our table
scene.googleMap:setCenter( .latitude, .longitude )
– our temporary marker lookup table
scene.googleMarkerTable = {}
– method called when a marker is click on
local function markerListener(event)
classStoryboard.gotoScene( “viewMarkerItem”, { params = { markerItem = scene.googleMarkerTable[event.markerId] } } )
end
– Iterate the tabledata
for itrMarker = 1, #tableData do
local markerOptTbl = {
listener = markerListener,
}
local item = tableData[itrMarker]
local result, errorMessage = scene.googleMap:addMarker( item.latitude, item.longitude, markerOptTbl )
if result then
scene.googleMarkerTable[result] = tableData[itrMarker]
end
end
end
end
– ************************************************************************
– Dispatch the update all pins
– ************************************************************************
function scene:updatePins()
if scene.googleMap then
scene.googleMap:removeAllMarkers()
scene.googleMarkerTable = nil
– On Androit only, it seems that we must introduce a delay between
– calling removeAllMarkers and adding new one.
timer.performWithDelay( gGlobalVar.addMarkerDelay, _updatePins )
end
end
– ************************************************************************
– Create the map view, center the map and adjust the zoom
– ************************************************************************
function scene:createMapView()
scene.googleMap = native.newMapView( x, y, w, h )
if scene.googleMap then
scene.googleMap.anchorX = 0
scene.googleMap.anchorY = 0
scene.googleMap.mapType = “standard”
local gpsMap = gGps
scene.googleMap:setCenter( gpsMap.regCenterLat, gpsMap.regCenterLon )
scene.googleMap:setRegion( gpsMap.regCenterLat, gpsMap.regCenterLon, 0.1, 0.1, false)
end
end
Hi @nmichaud, thank you so much for sharing your code.
I am particularly interested in your marker touch listener
-- method called when a marker is click on local function markerListener(event) classStoryboard.gotoScene( "viewMarkerItem", { params = { markerItem = scene.googleMarkerTable[event.markerId] } } ) end
I am doing something very similar but noticing a lot of irregular behavior. Please see my thread on this for more detail :
Particularly, I see that sometimes you get the listener trigger on first tap, especially if you tap on the lower part of the marker and sometimes first tap brings the bubble and you need to tap the bubble to get the listener triggered (preferred behavior). I don’t see any precaution against this in your listener. Do you have another alternate solution or did this issue not surface during your testing?
Thanks once again for sharing and apologies for taking this thread offtopic
You are bringing something that hurt us badly. The Corona implementation of Google marker is quite weak in my opinion. What you are expecting cannot be done unfortunately. Here is what we discover during our initial implementation.
case 1: If in the option table you only define a callback. It will work as expected. Corona will call your callback when you tap the pin. Which is expected.
case 2: If you want to display the Google bubble, you must add the Title/Subtitle in the option table. In this case, we would expect that our callback is only called when we click on the bubble! but NO 
The callback is always called when you click on the marker. Clicking on the bubble has no effect in our test.
This is why that in our code, when a marker is click on we directly go to another page. It is not nice and it is not the best workflow but we had no choice for the time being. We have asked for a better implementation and we are waiting from them to enhance this feature to match a normal workflow and user expectation. We should be able to customize the bubble and put a nice button into it.
We should unite to have Corona fix this as in my opinion this is not good at all.
I completely agree with you. As expressed in my other thread the implementation is very weak and inconsistent to the point that the bubbles are not usable as they are.
In my implementation the bubbles are essential. There are 100+ markers which are all points of interest and people will go tapping on the markers at first to see the bubbles and if they wish to explore further they will tap on the bubbles to get to the detail. Going from marker direct to detail is not that usable. Just to let you know I managed to get this behavior in a little convoluted way. Counting taps and ignoring first tap but going to the detail on second tap does the trick although in a very crude way. Let me know if you wish to see this code although I warn you it is pretty silly.
Meanwhile the IOS and Android behavior is not consistent in how the taps in empty spots are handled. On IOS a tap in empty spot of the map closes all bubbles which is a good outcome for me. On Android when you tap on an empty spot nothing happens. The bubbles are not closed until you tap the X on them. The X is an Android only feature…
I sincerely hope that Corona Labs does improve the mapView in future updates. Currently it is feature incomplete and buggy.
I would be very interested to see how you did manage to do that if you are willing to share that code.
Sure. Here it is. Basically I keep track of which marker is tapped last and how many times it was tapped in 2 global variables. If the same marker is tapped 2 times (or more) I jump to the detail view. This way I find that I can show the bubble but there are inconsistencies in this implementation as well. Maybe you can improve it if you like it. Good luck.
PS. Ignore some additional / unused variables. I’ve been trying lots of things in there.
local markerTapped = false local markerId local markersTable = {} local chosenMarker local markerTapCount = 0 local currentMarkerID = nil local function markerListener(event) markerId = event.markerId if currentMarkerID ~= markerId then currentMarkerID = markerId markerTapCount = 0 end markerTapCount = markerTapCount + 1 if markersTable[markerId] and markerTapCount \>= 2 then chosenMarker = markersTable[markerId].landmarkID local options = { effect = "slideLeft", isModal=true, params = { var1 = chosenMarker } } storyboard.gotoScene( "scn\_landmark\_details", options ) end endThanks we will give it a try and give you some feedback. But quick question. By looking at the code, it is when you click a second time on the same marker that you will go to your scene ? Clicking on the bubble itself as no effect, right ?
Clicking the bubble triggers the listener for me. At least on IOS. This is on 2187 as of today. No guarantees what tomorrow might hold for us!
Edit : cleaned up the code a little above.
Edit 2 : the length of the tap on bubble and the marker seem to have a different effect on the listener. A quick peck vs a longer tap and release. Experiment to see how it works on your side.
Ok, we will try it under iOS and will get back to you soon
@henrik 5, do you have the bug number ? This bug is also killing us. RemovingAllMarker and adding new one is bogus and even on the latest build .2156
After looking on FogBugz we did not see any bugs relate to our problem. We have open a bug as the removeAllMarker and addMarker is currently unreliable.
No, I don’t make notes manually when filing a bug. I trust the team got the bug. (Or a lot of time and my test info has been lost.)
It would be great if you have found a workaround, but I think you have to set it up to work repeatedly and I suspect you may find that waiting doesn’t remove the bug. At least when I tested I would have it working for a few taps and thinking I fixed it. You need to zoom in/out to see the coordinate systems mismatch.
Btw what is limit to add markers to map ?
I load marker data from my server on load (just json data), then create it
local idd = myMap:addMarker( x, y, options )
After approximately 100 or 150 markers my iOS devices crushes
I run publish starter version 2100
Oops. I was just about to start a project where I will need to put in 100+ markers. I hope there is no such limitation at all.
@Bladko, so far we did not see any limit on the number of marker you can add. One of our thematic in our tourism app currently display 205 markers on iOS devices without any trouble.
On Android it is another story, we are working with the dev team to narrow down some unpredictable result when you addmarker after operations like removeAllMarker/SetRegion/SetCenter.
How did it work for you? Any ways to improve it? Thanks for sharing.
@nmichaud, I think I’m walking in your footsteps. Would love to hear if you were able to overcome the Android challenges and also how you handle the marker tap events. Thanks for anything and everything you might be able to share.