Okay I think I'm gonna have to take it back, this isn't a problem
with the maps swc directly, what I said is still somewhat valid,
mixing SDKs is not a good thing and results in very confusing
scenarios when attempting to determine the source of problems, as such
I would still love to see the maps swc re-compiled against the newer
versions of the SDK, but I haven't been able to produce a simple
scenario to show the problem, they always end up being complicated
sets of projects. I was able to produce the blendMode issue without
using the maps so I know it's not purely an issue with using the maps
swc but I've seen a couple of forum posts regarding the blendMode
issue with google maps, the solution was to move the project back to
being compiled against 3.2, perhaps the original issue was fixed in
updates to the maps swc, but I don't think so.
When I do a little inspection on the maps swc I see that there's
references in the catalog.xml to the mx framework this worries me
(results from searching for "mx" in the catalog.xml of the 1_17.swc):
<dep id="mx.managers:IFocusManagerComponent" type="i" />
<dep id="mx.core:UIComponent" type="i" />
<dep id="mx.utils:Base64Encoder" type="e" />
<dep id="mx.utils:Base64Encoder" type="s" />
<dep id="mx.events:ResizeEvent" type="e" />
<dep id="mx.events:ResizeEvent" type="s" />
<dep id="mx.core:UIComponent" type="e" />
<dep id="mx.events:FlexEvent" type="e" />
<dep id="mx.core:UIComponent" type="s" />
<dep id="mx.events:FlexEvent" type="s" />
That's everywhere I find mx in the file, what's this mean to me? That
compiled versions of this class may be pulled in from the swc if the
map swc is compiled at a later time (with changes) than the framework
swc my new project depends on, if that's the case I'll get the classes
compiled in your swc rather than the ones from the framework. I'll
still get classes from the framework that I intended on using if they
weren't referenced in the project I depend on, therefore I'll end up
with x y classes from framework 2.0.1 and class z from 3.4, now lets
say z uses x, if z's implementation has changed from 2.0.1 to 3.4
where it expects x's implementation to be different as well then
errors will occur.
So basically what I'm saying is 1 of 2 things needs to happen to
guarantee there's no issues. Option 1 is that the maps SWC depends on
absolutely nothing from the Flex framework and operates completely
independent of the SDK (which it seems is feasible since there was
originally only Flash support, actually now that I think of it I may
try to just use the Flash version of the swc and wrap it up in a
UIComponent myself... if this solves it I'll post back). Option 2 the
flex swc is re-compiled against every version of the SDK you intend to
claim to support.
Thanks for any help you can offer again, I can show test cases if
you'd like of the blendMode error occurring if compiling a project
against the 3.2 SDK that has a dependency on a 3.4 compiled SWC though
I haven't been able to simply re-produce the original problem of using
the maps with a project compiled against 3.4 (as I stated above maybe
this got fixed from the time I started using the maps swcs).
Thanks again,
Shaun
On Mar 18, 12:24 pm, Shaun <[email protected]> wrote:
> Hi Luke,
> Thanks for the nearly immediate response I'll file a bug when I have
> time to put together a test project to show the setup that causes this
> problem it's kind of complicated so I think an example will really
> help but I don't have time to create one outside of our project at the
> moment but I'll post the bug as soon as I can and drop a link in here
> to the bug when it's filed.
> Shaun
>
> On Mar 18, 11:58 am, "Luke (Google Employee)" <[email protected]>
> wrote:
>
> > Hi Shaun,
>
> > Can you please file a bug on the issue tracker so we can track it
> > internally.
>
> > Thanks
>
> > Luke
>
> > On Mar 18, 9:47 am, Shaun <[email protected]> wrote:
>
> > > Hi all,
> > > This question is pretty much directed to google employees as most of
> > > mine are, BTW thanks for all your help I'm highly appreciative of the
> > > SDK and the community around the maps. If I don't get an answer here
> > > I'll try contacting you through our contact with our premiere account
> > > but I figure the community at large could probably benefit from seeing
> > > the conversation.
>
> > > I wonder why the newest releases of the maps API are compiled against
> > > the Flex 2.0.1 SDK. This is causing me major headaches when
> > > attempting to build my application against the 3.4 SDK. I did a lot
> > > of digging and apparently the way Flex resolves where it will get a
> > > particular classes bytecode is based on the time stamp in the
> > > catalog.xml of when the AS was compiled to bytecode into the SWF and
> > > subsequently into the SWC (where the catalog.xml shows the compile
> > > time time-stamp).
>
> > > So here's how it breaks down, my company compiles some library or
> > > framework into a SWC file, say this source code references some
> > > UIComponent that itself depends on a class like say HaloFocusRect
> > > since our library is being compiled against the 3.4 SDK the bytecode
> > > in the produced SWC is all 3.4 and everything is good. Now say my
> > > project uses our library and it uses the flash maps SDK and for
> > > arguments sake lets say the flash maps never referenced the
> > > UIComponent our library referenced but it does have a reference to
> > > HaloFocusRect and it was compiled at a later time than our library,
> > > now when I compile my application it's going to use the UIComponent
> > > (because it isn't in the maps SWC) from our library from 3.4 and the
> > > HaloFocusRect from 2.0.1 because that's what the latest compiled
> > > version is (even though it's not the newest, even so using the newest
> > > wouldn't correct the problem). This causes the blendMode error that
> > > people complain about occasionally because a null check has been
> > > removed from the HaloFocusRect and moved into another class or dealt
> > > with in another way in the 3.4 Flex SDK (3.2 and 2.0.1 seem to handle
> > > this in the same way so compiling against 3.2 works out ok).
>
> > > AHHHHHHHHHH!
>
> > > All this is pretty confusing, a simple remedy (for me :) would be to
> > > have a version of the maps API compiled against 3.4 (3.2 and 3.5 would
> > > be nice but right now we're looking to move to 3.4). Can someone tell
> > > me why this isn't already happening, I know there must be a reason
> > > (testing, budget... something).
>
> > > BTW I was completely lost on how Flex was determining which classes to
> > > use when there's an option (same class in different dependencies) and
> > > finally stumbled on this months after I need it of course, but still
> > > great to know, article is old but the info is
> > > relevant.http://www.adobe.com/devnet/flex/articles/link_load_08.html
>
> > > Thanks for any insight, or other suggestions,
> > > Shaun
>
> > >http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3
> > > 3.4.1 is stable according to adobe as of this writing
--
You received this message because you are subscribed to the Google Groups
"Google Maps API For Flash" group.
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.
