It has been a while ago that I suggested the lazy-loading of provider apis as a feature in mapstraction v2. "lazy-loading" here means that the google maps/virtual earth/??? api is dynamically loaded when the user decides to switch to that provider. This would mean much faster loading times for multi-provider maps (currently all provider apis are loaded in advance). is there any progress on this issue? kind regards, Franz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090921/2edadce7/attachment.htm>
unfortunately, lazy-loading is not so easy done as it seams. I did some tests on that and the "obvious" approach doesn''t work (i. e. dynamically insert a <script> tag in the head pointing to the provider api src url, then invoke every n milliseconds a function that checks for the presence of VEMap or GMap objects) The problem is that GMap/VEMap are available long before the api finished its loading. Surely, one could reverse-engineer the loading cycles within google/bing maps api, but this will likely be changed in future versions of the api. IMHO there are 2 options: - use an enhanced load checker that embeds the provider api as described above, but actually tries to create a the map with the provider api (try...except). If the map creation fails, the load checker invokes itself with some timeout. - google.load supports dynamic loading of the google maps api (and various other ones). Downsides: it doesn''t support Bing/Yahoo and requires the inclusion of the loader api script. http://code.google.com/intl/de-DE/apis/ajax/documentation/#Dynamic any suggestions? Franz 2009/9/21, Franz Buchinger <fbuchinger at gmail.com>:> It has been a while ago that I suggested the lazy-loading of provider apis > as a feature in mapstraction v2. > > "lazy-loading" here means that the google maps/virtual earth/??? api is > dynamically loaded when the user decides to switch to that provider. > > This would mean much faster loading times for multi-provider maps > (currently > all provider apis are loaded in advance). > > is there any progress on this issue? > > kind regards, > > Franz >
[little known fact] You can load Google Maps API dynamically by appending "&async=2&callback=callBackFunc", and you can create in callBackFunc. The common loader just wraps that for us. More info: http://code.google.com/apis/maps/faq.html#loadasync On Sun, Sep 27, 2009 at 12:32 AM, Franz Buchinger <fbuchinger at gmail.com> wrote:> unfortunately, lazy-loading is not so easy done as it seams. I did > some tests on that and the "obvious" approach doesn''t work (i. e. > dynamically insert a <script> tag in the head pointing to the provider > api src url, then invoke every n milliseconds a function that checks > for the presence of VEMap or GMap objects) > > The problem is that GMap/VEMap are available long before the api > finished its loading. Surely, one could reverse-engineer the loading > cycles within google/bing maps api, but this will likely be changed in > future versions of the api. > > IMHO there are 2 options: > > - use an enhanced load checker that embeds the provider api as > described above, but actually tries to create a the map with the > provider api (try...except). If the map creation fails, the load > checker invokes itself with some timeout. > > - google.load supports dynamic loading of the google maps api (and > various other ones). Downsides: it doesn''t support Bing/Yahoo and > requires the inclusion of the loader api script. > http://code.google.com/intl/de-DE/apis/ajax/documentation/#Dynamic > > any suggestions? > > Franz > > > 2009/9/21, Franz Buchinger <fbuchinger at gmail.com>: >> It has been a while ago that I suggested the lazy-loading of provider apis >> as a feature in mapstraction v2. >> >> "lazy-loading" here means that the google maps/virtual earth/??? api is >> dynamically loaded when the user decides to switch to that provider. >> >> This would mean much faster loading times for multi-provider maps >> (currently >> all provider apis are loaded in advance). >> >> is there any progress on this issue? >> >> kind regards, >> >> Franz >> > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >
Have added an issue to look into this (#28), have got it partially working so far :) Rob 2009/9/26 Franz Buchinger <fbuchinger at gmail.com>> unfortunately, lazy-loading is not so easy done as it seams. I did > some tests on that and the "obvious" approach doesn''t work (i. e. > dynamically insert a <script> tag in the head pointing to the provider > api src url, then invoke every n milliseconds a function that checks > for the presence of VEMap or GMap objects) > > The problem is that GMap/VEMap are available long before the api > finished its loading. Surely, one could reverse-engineer the loading > cycles within google/bing maps api, but this will likely be changed in > future versions of the api. > > IMHO there are 2 options: > > - use an enhanced load checker that embeds the provider api as > described above, but actually tries to create a the map with the > provider api (try...except). If the map creation fails, the load > checker invokes itself with some timeout. > > - google.load supports dynamic loading of the google maps api (and > various other ones). Downsides: it doesn''t support Bing/Yahoo and > requires the inclusion of the loader api script. > http://code.google.com/intl/de-DE/apis/ajax/documentation/#Dynamic > > any suggestions? > > Franz > > > 2009/9/21, Franz Buchinger <fbuchinger at gmail.com>: > > It has been a while ago that I suggested the lazy-loading of provider > apis > > as a feature in mapstraction v2. > > > > "lazy-loading" here means that the google maps/virtual earth/??? api is > > dynamically loaded when the user decides to switch to that provider. > > > > This would mean much faster loading times for multi-provider maps > > (currently > > all provider apis are loaded in advance). > > > > is there any progress on this issue? > > > > kind regards, > > > > Franz > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091114/b283d001/attachment.htm>