I agree with Daniel almost 100% again, I think what he was meaning to say though was make a sub-class of the Camera concrete class, which unfortunately you don't have a handle on from the API. Working with this API after having worked with quite a few open source APIs I can definitely agree there's some places it's lacking (and I would far prefer to have the source and would contribute like mad) but as Daniel said for the most part there's a lot of people who can get access to and use these maps for their mom and pop sites for free which is pretty "nice" of Google though as always I'm sure they have their financial motivations. I understand you're working in the corporate world where money isn't the issue but rather features and exposure of said features, I'm in the same boat so I understand the frustration and need to rant on occasion. Honestly though your best bet is to break down your issues into something more digestable and to direct them appropriately to really make progress. For example as Daniel stated, I also haven't had any of the security issues you're talking about, if you provide the appropriate key or clientId and sensor parameter and ssl setting as is required then I haven't seen any issues (well sparingly when trying to do funky things like taking thumbnails of the current map position, which ultimately they provided a method for, getPrintableBitmap). Extrapolate on that here on the forum we can probably help you to diagnose and pin down what is causing your security violation errors, however the Camera issue is possibly one to search for in the gmaps API issues database and vote for it or enter it if it's not there already, also you could contact your premiere account handler at Google and voice your complaints and see if they have any resolution to offer you. As is, the only way to fix this problem is to do some very illegal business (think decompiler, but don't do it :) which I'm sure would not fly in the corporate world, there is no good way I've found by using event listeners and adjusting (the map creeps as though it's panning when you attempt to reset the attitude) or by trying to stop propagation of those events (since I'm getting them from outside the map there's no way to stop the internal mechanisms from catching them first that I've seen so far).
Also although this is in the online reference documentation Attitude(yaw:Number, pitch:Number, roll:Number)<http://code.google.com/apis/maps/documentation/flash/reference.html#Attitude.Attitude> It probably wouldn't kill them to spend a day properly commenting at least the public API code for ASDoc generation and to be visible in Eclipse, I think this is a completely valid point (or at least update the parameter names to match whats shown in the reference). Google should just hire me... but I like my job :). I think basically they took some guys who write Python or Javascript all day and forced them to write the AS3 API and it shows. Not to say AS3 programmers are the best in the world in terms of writing efficient code etc. but it seems we do understand the importance and usefulness of documenting code and using variable names that mean something (I guess we're just more used to working with artists and other non-technical types). It is actually Google's fault that the arguments have ridiculously dumb names that are meaningless to anyone but those with the source, or those with enough patience to search through the documentation, also they don't seem to document anywhere that these properties are read only nor do they state the set values anywhere. I gotta say I'm usually a defender of the Google name (for whatever reason I generally like their products and general demeanor) but in this case I have to agree with the original poster that they really do neglect the Flash maps API. I believe Flash is basically just caught between Google and Apple and Google would like Flash to survive if only to hurt Apple's products for not supporting it and Apple would love for Flash to die so that Google has no major advantage in the public's eye with regard to the Android platform, of course Adobe doesn't want to see their adopted child die but they're making moves like Edgy to prepare... okay now you spun me off into my own rant, look what you did :). Anyhow point being if Flash is ultimately replaced I'll be somewhat sad to see it go since I think it's a pretty sweet platform and makes developing lots of fun vs lots of javascript debugging for everyone's "innovative" browsers and I think you're right on about the lack of attention this API gets, I basically understand that they will keep the Javascript API a step ahead since it's what they use on maps.google.com and they will keep the Java version a step ahead since it's what they use on Android, but not supporting the Flash API and community is like flipping us all the bird. It makes me not want to use this API and even pushes me to re-consider using Flash/Flex (though honestly I'd have to see some compelling editors for HTML5/Javascript that could really allow a team of developers to work as efficiently as I can with a team of developers doing AS3/MXML code, the division of responsibility is just so simply clear with service layer done in Java with Spring and iBatis or Hibernate, AMF via BlazeDS, and AS3/MXML/CSS on the front end and no need to worry about browsers, not including iOS of course). -- You received this message because you are subscribed to the Google Groups "Google Maps API For Flash" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-maps-api-for-flash/-/0DBPiSTlzwgJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-maps-api-for-flash?hl=en.
