Ported from V2: ArcGISLink, closure compiled
33 views
Skip to first unread message
Nianwei Liu
Jul 13, 2010, 4:24:06 PM7/13/10
to google-maps-utility-library-v3
Hello group,
I've just completed porting a relatively large library from v2's
util lib: ArcGISLink. Although it's an interface lib to a commercial
product, it can still might be of interest to other lib developers in
several aspects:
---- Like many other well known js libs, the code is wrapped in an
anonymous function scope to hide all private functions variables, in
order to protect the globe namespace. This also helps the JS
compressors to shorten the private names.
--- I picked namespace "gmaps", which is simple and easy to
understand. Also a sub namespace "ags" to contain all public classes
inside the lib. If there is a different namespace everyone agrees for
this project, I can change that.
--- This lib heavily uses a couple classes that are less commonly
customized: Projection, MapType, it also added the TileLayer concept
in v2 to handle multiple tilesets per map type. Other developers may
find some of the code helpful to work with this type of
customization.
--- I spent a great deal of time on the closure compiler. (Thanks
Chad Killingworth for contributing the extern file). Simple
optimization is quite straightforward. As to the advanced
optimization, exporting class is easy, followed by exporting public
methods. Since the compiler does not rename strings, there is a trick
to avoid exporting methods in extra code using this syntax:
MyClass.prototype["myMethod"] = MyClass.prototype.myMethod; instead,
write the method directly using this syntax:
MyClass.prototype["meMethod"] = function(){...}; The downside is
compiler complains about "this" because it does not know it's a
prototype method, also current JSDOC does not reorganize it (maybe
tweak the JSDoc tool can help).
The nightmare came with the property names along with heavy usage
of json in my lib. In my opinion the compiler should not rename
properties if it is not declared in a class with "this". Unfortunately
the compiler choose to rename everything that is not in subscript
notation. That means I have to change many code from dot notation to
subscript notation. When all was done, I found the code is much less
readable than original.
Finally I compiled the code with Dean's packer, and closure compiler
with simple and advanced optimization. The original size is 130K,
Packer 24K, Simple Op 29K, Advanced 27K. When served with gzip
(Hopefully googlecode.com can gzip js files some time), the size were
12.4, 11.5, 10.9K, respectively.
My personal feeling after the comparison of all three option is that
the simple optimization is the best choice considering it's quite safe
and also does a pretty good job in compressing. It may be different if
the lib does not use many external json objects.
--- Most sample code uses full screen as to fit mobile device.
samples are tested on Nexus one, and most work except a few issues
that may related to Android browser. I also made a "phone size"
version of most examples to kind of fake a phone screen.
http://google-maps-utility-library-v3.googlecode.com/svn/trunk/arcgislink/examples/nexus.html?u=mercator.html.
Although the actual device got more screen pixel because of higher
DPI, this is a fun experiment.
The example index page is at
http://google-maps-utility-library-v3.googlecode.com/svn/trunk/arcgislink/docs/examples.html,
one interesting one is routing with barriers.
Comments welcome,
Nianwei
I've just completed porting a relatively large library from v2's
util lib: ArcGISLink. Although it's an interface lib to a commercial
product, it can still might be of interest to other lib developers in
several aspects:
---- Like many other well known js libs, the code is wrapped in an
anonymous function scope to hide all private functions variables, in
order to protect the globe namespace. This also helps the JS
compressors to shorten the private names.
--- I picked namespace "gmaps", which is simple and easy to
understand. Also a sub namespace "ags" to contain all public classes
inside the lib. If there is a different namespace everyone agrees for
this project, I can change that.
--- This lib heavily uses a couple classes that are less commonly
customized: Projection, MapType, it also added the TileLayer concept
in v2 to handle multiple tilesets per map type. Other developers may
find some of the code helpful to work with this type of
customization.
--- I spent a great deal of time on the closure compiler. (Thanks
Chad Killingworth for contributing the extern file). Simple
optimization is quite straightforward. As to the advanced
optimization, exporting class is easy, followed by exporting public
methods. Since the compiler does not rename strings, there is a trick
to avoid exporting methods in extra code using this syntax:
MyClass.prototype["myMethod"] = MyClass.prototype.myMethod; instead,
write the method directly using this syntax:
MyClass.prototype["meMethod"] = function(){...}; The downside is
compiler complains about "this" because it does not know it's a
prototype method, also current JSDOC does not reorganize it (maybe
tweak the JSDoc tool can help).
The nightmare came with the property names along with heavy usage
of json in my lib. In my opinion the compiler should not rename
properties if it is not declared in a class with "this". Unfortunately
the compiler choose to rename everything that is not in subscript
notation. That means I have to change many code from dot notation to
subscript notation. When all was done, I found the code is much less
readable than original.
Finally I compiled the code with Dean's packer, and closure compiler
with simple and advanced optimization. The original size is 130K,
Packer 24K, Simple Op 29K, Advanced 27K. When served with gzip
(Hopefully googlecode.com can gzip js files some time), the size were
12.4, 11.5, 10.9K, respectively.
My personal feeling after the comparison of all three option is that
the simple optimization is the best choice considering it's quite safe
and also does a pretty good job in compressing. It may be different if
the lib does not use many external json objects.
--- Most sample code uses full screen as to fit mobile device.
samples are tested on Nexus one, and most work except a few issues
that may related to Android browser. I also made a "phone size"
version of most examples to kind of fake a phone screen.
http://google-maps-utility-library-v3.googlecode.com/svn/trunk/arcgislink/examples/nexus.html?u=mercator.html.
Although the actual device got more screen pixel because of higher
DPI, this is a fun experiment.
The example index page is at
http://google-maps-utility-library-v3.googlecode.com/svn/trunk/arcgislink/docs/examples.html,
one interesting one is routing with barriers.
Comments welcome,
Nianwei
William
Jul 13, 2010, 9:34:21 PM7/13/10
to google-maps-utility-library-v3
excellent work thanks Nianwei! I was wondering about ArcGIS Server
versions and wanted to confirm whether the ESRI API is backwards-
compatible? The doco says your library is for ArcGIS 10, but will it
work with 9.3?
versions and wanted to confirm whether the ESRI API is backwards-
compatible? The doco says your library is for ArcGIS 10, but will it
work with 9.3?
nianwei
Jul 13, 2010, 10:18:09 PM7/13/10
to google-maps-uti...@googlegroups.com
ESRI's REST API is backward compatible. I have made reasonable effort to make it work on both version when there is a difference. In fact, most of the sample in this lib works against 9.3 server.
--
You received this message because you are subscribed to the Google Groups "google-maps-utility-library-v3" group.
To post to this group, send email to google-maps-uti...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-utility-l...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-utility-library-v3?hl=en.
Reply all
Reply to author
Forward
0 new messages