Thanks Shaun, I have shared this with the team.

 - Luke

On Mon, Apr 5, 2010 at 10:08 AM, Shaun <[email protected]> wrote:

> 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]<google-maps-api-for-flash%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-maps-api-for-flash?hl=en.
>
>

-- 
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.

Reply via email to