Chrome, google maps and scrolling

[itb]

Hi,

We have an app with some tabs, one of them is a Google Maps tab. Since v3.51 of Google Maps is served by default, we experience problems with mouse scrollwheel events in Chrome.

If the user tries to scroll in a SmartGWT ListGrid, the mousewheel scroll no longer works. Scrolling with the scrollbar still works. This problem occurs in Chrome latest, not in FireFox. If we manually downgrade to v3.50 of google maps, scrolling works again. As I cannot seem to find any maps users with scrolling problems, I think there might be an interference between SmartGWT and google maps scrollwheel event handling here. Does anyone use this combination and experience this too? It does not matter if there is actually a map or not, loading the library from https://maps.googleapis.com/maps/api/js already breaks scrolling.

regards, Iwan

[Isomorphic]

We've just added new maps demos in the latest Showcase and grid scrolling does not seem to be affected - please try it out yourself.

You haven't mentioned what version or product you're using, but you might simply need to get the latest patches (from smartclient.com/builds).

[mathias]

Just saw this, great stuff!!

I've used GWT/branflake maps/my own code since 2010, so great to have built-in support. This coming to smartGWT as well? didn't find anything in the showcase. If I can remove at least some of all of my homegrown code It would be a win for me.

[mathias]

Guys, any input here? I saw that the maps examples in the smart client showcase are still not available in the smartGWT showcase.

[Isomorphic]

Hi Mathias,

Google Maps are a Google-provided component and service.

Google has chosen to make Google Maps available as JavaScript components and Google has not provided them via Google's own GWT technology.

This is a very big hint: if Google is not willing to themselves maintain a GWT wrapper for their own technology, then presumably, they mean to rapidly evolve the JavaScript API for Google Maps, such that Java/GWT backwards compatibility would be an issue.

We are not going to fight Google on this and try to create a backwards-compatible Java maps API, where we commit to future support regardless of what Google does.

And, as you have previously mentioned, various projects have tried to wrap the JavaScript APIs in Google Maps, and have been rendered obsolete quickly.

So, if you are really excited about SmartGWT support for Google Maps support, here are your possible approaches:

1) you can take our SmartClient-based examples and use the same code via JSNI yourself in SmartGWT, so as to replicate the functionality in our samples.

This is relatively straightforward, and there is a lot of other relevant sample code around too, as well as AIs that can help write this kind of code.

.. or ..

2) you can ask us to build #1 for you - and we can do it as component examples and add it to the SmartGWT Showcase, via our Feature Sponsorship program. However, we will (of necessity) mark it as example code that may break if Google changes things.

.. or ..

3) you can contract with us to maintain a set of GWT Google Maps components that continuously adapts to the latest Google Maps APIs, including rapidly adapting to API changes that may cause widespread deprecations, and perhaps helping you to adjust your calling code, etc. Basically, Isomorphic maintains an application module for your team. We've done this successfully in many different variations over the years, for many different customers.

The only thing we can't do is force Google to conform to an API we design, such that we can offer forward compatibility at minimal cost.

Outside of that, we can provide whichever level of service you would like.

[mathias]

1. I disagree . Google doesn't really spend time maintaining *any* GWT-related tech anymore, so them not having a GWT maps component is hardly indicative of anything in my opinion. (also, they've never had maps in GWT, ever)

2." Obsolete quickly"?? "tried" to wrap? The most prolific third-party GWT maps library, Branflake maps, has not been updated in NINE YEARS yet works fine today. I have been using it
for about as long.

3. Googles Javascript library hasn't "evolved quickly" in many, many years, it's a mature library. Of course they won't break backwards compatibilty, that would be absurd with their install base. Also, any changes and handling "forward compatibility", as you say, would surely affect your SmartClient library too?

---

All you write boils down, to me, is that you simply don't feel it's worth doing. *Very* disappointing. I was very much looking forward to using smartGWT maps components and I was sold on smartGWT always having the same functionality as Smartclient.

[Isomorphic]

SmartGWT does have the same components as SmartClient, in fact, it's automatic (it just happens when we add SmartClient APIs).

There are no SmartClient Google Maps components. There are just samples. So there is no lack of parity in functionality, as you seem to think, and indeed, if SmartClient ever adds maps components, you will see them in SmartGWT too.

It's great that branflakes still works for whatever functionality it provides, but obviously, you want something more - probably some new API that is available from the Google Maps JavaScript API, that branflakes didn't wrap? That's what we're talking about in terms of backwards (and forwards) compatibility.

To explain it a bit differently, we haven't built maps components because we don't see it as providing a lot of value to our customers:

1. there's no inherent added value in relaying calls from one JavaScript API to another

2. as Google Maps adds or changes APIs, customers have to wait for us to add new corresponding APIs, and if they aren't on the latest version, they would be stuck without access to the underlying API. This is negative value.

3. as the underlying Google Maps API changes, we might find that the way we built a wrapper API might need a total rework to accommodate new capabilities. Then customers using our APIs would have to rework their calling code, but they wouldn't have had to do that if they were just directly using the Google Maps API. This is again, negative value.

Hopefully this way of phrasing things helps you understand the problem. These issues mean that we should concentrate our efforts elsewhere, because we can create more value for customers in other areas.

So, Google Maps has an API already, and we recommend you use it. If you want help doing that, we can provide that help, and we've explained the options above.

[mathias]

Oh, then I am mistaken. I thought you were adding kind of an equivalent to Branflake maps into smartGWT. That library is, more or less, JSNI I think.

Even though as I said Branflake works just fine: It IS third party and hasn't been updated for ages, so I was hoping taking the potential risk of having to spend time in the future to update it out of the equation If you included some classes to smartGWT. It would for sure make me upgrade to the next version ;)


Thanks for explaining in more detail, I had misunderstood the samples. I guess I'll march along with Branflake as my sole companion in the darkness, for now. Cheers!