Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
A new message was posted by Terry Corbet in
Developers --
How to Test AIR 1.5
01. Thanks, I will continue testing with ADL and hopefully be able to move up to a web-base, remote installation/update scenario in a couple of weeks.
02. I'm sorry you feel that my failure to accept what may be 'intuitively obvious to you' -- that I can design and test a 3D front end to FMS that works the same in a native window as in a browser window -- indicates any lack of faith in what will be delivered. So far, I have found subtle, important differences, and I am sure there will be others that will just have to be patiently tested before I get it right.
03. So, I'm glad you asked about swz in an AIR environment because that is a whole topic for which I have not been able to find any discussion on any of the many fine forums you have. I understand product marketing and product development, but I can't say that I ever managed those activities in the environment you have in which several large projects co-exist with lingering dependencies and even 'cultures' as diverse as you have with the various acquisitions that come together in the suite of products you have today.
So, I will simply state that I think no one seems to have recognized that your paradigm for 'desktop' versus 'web-based' software -- the essential distinction which seems to describe Adobe's description of an AIR versus a Flex application -- does not always hold. I understand the general dichotomy, but it does not hold for my user base.
You have lots of design papers and lots of software devoted to 'reducing the burden' of ever-growing executables in the Flex framework by caching of your or our rsls. That's a good idea. Why do you think it is not just as good an idea for an AIR application? Probably because you think that an AIR application will either be shipped on a CD, or sent over the Internet, but relatively infrequently, so who cares if you have to ship out 10MBs or 2MBs? My user cares.
My user will get frequent updates to an ever-growing body of software called an application, and he will get them over those same slow bandwidth network links that the Flex user sees. What's "good for the goose is good for the gander". There is simply no reason not to architect the library of code that we use to cobble together the application and use the same intelligent caching mechanism in both environments. I looked for a month for a white paper or discussion of how to 'modularize' an AIR app but all that you wanted to publish were white papers on how to 'modularize' a Flex app.
I'm sure that you guys have a bunch of object diagrams and product architecture blueprints that you have memorized -- but that is not what we see 'outside the black box'. What we see is a confusing distinction between the AIR efforts and the Flex efforts although the code base and efforts are substantially the same. And if that is true from an internals point of view, put on your end-user hat and look at how we view a AIR/Flex app -- it is all one.
So, I develop the worlds greatest Juke Box and get it all going in Flex, then I move that into one Tab on one Screen in the AIR 'shell'. Then some guys go off and mostly use AIR-unique code to add a Tab that allows Drag and Drop creation of Slide Shows accompanied by voice overs, and another set of my guys go off to add the 'Sudoku' module in just plain old Flex. At some point in time in some ant task, we've got 10MB of code and X MBs of that is in one of our present [or future] swz files. Where is the distinction that says I should just ask my users to download the whole shooting match, when what he really wants to do is just download whatever updated or new application modules [including any upgrades to your frameworks] when required.
So, it took some time, but today, my application is compiled with dynamic linking to the framework.swz, and when the user launches his AIR application on the desktop, the Flash Player, embedded in the AIR environment, is smart enough to find that it already has the necessary framework code and does not need to go back to the network to get it refreshed. Actually, since I could never figure out how to use Module and ModuleManager, the method for solving the framework caching problem ended up just being an extension of what I developed for version management 'with continuous update' of my own swf files. So, when the AIR shell starts up, it needs to test to see whether there is any updating to be done, or whether it already has locally available the 'latest and greatest' and that works the same for MyCute3DWizBang.swf or framework_3.1.0.2710.swz or framework_4.0.0.3988.swf.
If you take the point of view that a 'desktop application' doesn't need to do anything special to solve the problem of 'large file downloads', you end up thinking that there is no reason for an AIR application to take advantage of the frameworked cache when, in fact, almost all of that code is needed whether the execution thread starts in a 'WindowApplication' or just a plain old 'Application'. At least thats the cockamaymee point of view that I came to in the absence of any 'best practice' discussion of these key topics -- so far, it seems to be working pretty well, but as you can guess, testing across a network to a remote host that may or may not have the right version of AIR, or the right version of framework, or the right version of MyCute3DWizBang is really more important than just testing against ADL.
----- Original Message ----- From: "Matt Chotin" < member@adobeforums.com>
To: < flexsdk-dev@adobeforums.com>
Sent: Monday, November 03, 2008 8:39 PM
Subject: Re: How to Test AIR 1.5
A new message was posted by Matt Chotin in
Developers --
How to Test AIR 1.5
The badge install doesn't work with debug, you can only use adl.exe right now. But this should show how the whole system would work and really allow you to evaluate. You know how the AIR install works with Air 1.1 (if not, use Flex 3.1 to target 1.1), I don't think seeing it with AIR 1.5 is critical to evaluate the features of the runtime at this point.
Air and the Flash Player are runtimes, and we've made it clear that AIR 1.5 would include FP10 features. So when we say Flex will enable FP10, it should be obvious that when AIR 1.5 comes out Flex will support it in the same way.
I don't really understand what you're doing with the SWZ and AIR, there's no real need to use a cached framework when the whole app is going to be installed.
In any case, Air 1.5 should be out in 2 weeks hopefully so you'll be set then.
Matt
On 11/3/08 8:07 PM, "Terry Corbet" < member@adobeforums.com> wrote:
A new message was posted by Terry Corbet in
Developers --
How to Test AIR 1.5
Thanks for the quick turnaround. Pardon my ignorance, but exactly what .exe
file will install Air 1.5 on a system? I don't find it anywhere. I guess I
can try to tear the ADL source apart to see how it mimics that behavior, but
that is, at best, just a local test. I think testing the whole Badge
install sequence is essential, and would like to give it a try. The longer
we put this off, the longer we all just sit here trying to decide whether to
stay with Papervision, Away, Sandy, or to use the graphics support in the
Player.
I am busy making the dynamic link to the framework.swz work for Flex modules
running under an AIR shell, and I doubt that I am alone. There must be many
of us who really see no distinction between AIR and Flex -- they just
provide us two different ways to slice a problem, that's why it is so
disconcerting to try to follow the threads on rapid Flex advancement with FP
10, but almost nothing pertaining the doing the very same things with the
AIR toolkit.
I hope you can tell me where to get the standalone AIR 1.5 installer that
will me keep making progress with the debugging output reasonably well
handled by Allesandros' FireFox tracer. Many thanks.
----- Original Message -----
From: "Matt Chotin" < member@adobeforums.com>
To: < flexsdk-dev@adobeforums.com>
Sent: Monday, November 03, 2008 7:55 PM
Subject: Re: How to Test AIR 1.5
A new message was posted by Matt Chotin in
Developers --
How to Test AIR 1.5
Hi,
We're not doing a public beta of the release runtime for AIR 1.5. You can
use the debug runtimes that are part of the Flex nightly builds though
(check the Flex 3 nightlies) to validate that AIR 1.5 will be right for
you though.
Matt
On 11/3/08 7:38 PM, "Terry Corbet" < member@adobeforums.com> wrote:
A new discussion was started by Terry Corbet in
Developers --
How to Test AIR 1.5
Sorry if this seems slightly off center, but I blame Adobe, not myself.
Trying to determine the true status and positioning of AIR amongst the
various Flex forums and projects for an outsider is practically
impossible. So, I will be brief. In September Mr. Chambers sent opened
the flow by telling us that we could find FP10 integrated with Flex SDK in
something you call 1.5 or Cosmo, or both. He was properly circumspect, so
I didn't rush into it -- there was not even an ADL binary when I checked.
Now it is November, the Trunk is at 4005, and ostensibly, everything we
need to start trying to take advantage of FP support of 3D operations is
out there. But where? Where do we get a version of AIR 1.5 that can be
installed on a target desktop, so that we can try to run the ADT test
cycle?
Call it Gumbo, call it Flex4, call it whatever, but can someone tell us
how to start testing it for AIR application deployment?
Thank you.
________________________________
View/reply at How to Test AIR 1.5
< http://www.adobeforums.com/webx?13@@.59b6ed86>
Replies by email are OK.
Use the unsubscribe
< http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to
cancel your email subscription.
------------------------------------------------------
View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/0>
Replies by email are OK.
Use the unsubscribe form at
< http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to
cancel your email subscription.
------------------------------------------------------
View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/1>
Replies by email are OK.
Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.
------------------------------------------------------
View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/2>
Replies by email are OK.
Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.
------------------------------------------------------
View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/3>
Replies by email are OK.
Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
A new message was posted by Matt Chotin inFramework on our servers is something we're looking into for Gumbo. As for documentation on doing modularization with AIR, you're probably right that we could provide more. I admit to not prioritizing the download size of AIR apps very high compared to the web experience.
Developers --
How to Test AIR 1.5
Something we can look into in the future.
Matt
View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/12>
On 11/25/08 12:43 PM, "Terry Corbet" < member@adobeforums.com> wrote:
A new message was posted by Terry Corbet in
Developers --
How to Test AIR 1.5
Thanks for both replies. I will try to see if I understand LoaderUtils well
enough to at least learn what caused the failure. I can wait for the fix,
but what I most have really been trying to get in response to my flailing
about is some sort of 'best practices' paper talking about the basic issue.
With the Nov 17 roll out, I see a huge effort put into the PDF discussing
"Loading Sub-Applications", but, as with security white papers and other
documents about 'modularization', whenever the author needs adopt his
comments/recommendations to AIR, it is like the sentence falls off the end
of the earth. "Oh, yes, this doesn't quite apply to AIR."
What does apply to AIR? We need a definitive statement concerning caching
of Adobe frameworks when talking about AIR.
Beyond that, somewhere along the way I submitted a suggestion for
enhancement that included the idea that in both environments -- Flex or
AIR -- the URL to which we would really like to point when it comes time to
access the .swz files, is one on your servers. Even if you are dealing with
the complexities of 'sub-applications' that require access to several
versions of the same framework files -- or maybe especially if you are
dealing with the complexities of 'sub-applications' that require access to
several versions of the same framework files -- the best place to host those
download requests is at Adobe.
We have to rely on your servers for Security anyway, so there is already a
built-in co-dependence between what any developer develops and what you are
supporting. Putting the framework on an Adobe server and letting the AIR
runtime and the Player 'go there' whenever it sees that it is about to load
a 'chunk of code' that was compiled for dynamic linkage, would just make the
cross-over from Flex to AIR almost transparent. Right now that whole topic
is so opaque that I am sure there are not 10 people who are trying to take
advantage of the framework cache from an AIR application.
Thanks again -- both Flex and AIR are superb facilities, but those Redmond
guys still have a lot of clout and we have to do everything possible to stay
in front of that pack.
----- Original Message -----
From: "Matt Chotin" < member@adobeforums.com>
To: < flexsdk-dev@adobeforums.com>
Sent: Tuesday, November 25, 2008 8:45 AM
Subject: Re: How to Test AIR 1.5
>A new message was posted by Matt Chotin in
>
> Developers --
> How to Test AIR 1.5
>
> Oh, and it's something you could probably patch yourself by looking at how
> LoaderUtils works if you don't want to wait.
>
>
> On 11/18/08 5:22 PM, "Terry Corbet" < member@adobeforums.com> wrote:
>
> A new message was posted by Terry Corbet in
>
> Developers --
> How to Test AIR 1.5
>
> 01. OK, thanks for keeping the promise of something to work with in a
> couple of weeks. I downloaded the 3.2.0.3958 source last Friday and
> started some more aggressive testing. I did not see any official
> announcement of the availability of the 1.5 runtime, but at least the
> spate of releases yesterday, spurred some other network traffic that
> resulted in my becoming aware that I could get that piece of the puzzle to
> go along with the adt code.
>
> 02. So, now with another full day of testing, I think I can state my
> problem, but I don't seem to be able to find the forum or format that will
> get the message I think needs to be sent. So, here's just a parable that
> should sum it up.
>
> A. I write five killer Flex applications.
> B. I compile them all with dynamic linkage to the Flex framework for the
> obvious of advantage of NOT asking my users to download an average of
> about an additional quarter megabyte each time. Caching of the framework
> [let's ignore the possibilities of their being at different release
> levels, just to keep this simple] even if my users don't happen to have
> other Flex applications from other sources, is just plain smart in this
> use case.
> C. Now, I create a shell using the AIR platform, and take advantage of
> some of the AIR-special facilities, but basically, all I want to do is
> give my users access to the same, original five Flex applications in a
> more convenient manner. Let's just say that 'provisioning the desktop'
> via one integrated AIR window, is in some ways nicer than 'provisioning
> that desktop' via the five independent browser windows.
> D. So, with the previous SDK releases [even when switching from Player 9
> to Player 10] on the user's systems, I could continue to use the
> dynamically-linked .swf files for the five Flex-based applications via a
> SWFloader in the AIR shell. Obviously, this savings of a quarter of a
> megabyte times five, was the smart thing to do.
> E. With the 3.2.0.3958 release, the Runtime [or the Runtime's interaction
> with the Player, I have no idea what that internal architecture looks
> like, since you don't document or disclose it] will no longer work that
> nice way. Now I am required to link the five Flex-based applications
> statically and incur the five times a quarter of a megabyte overhead when
> provisioning my users' desktop.
>
> 03. Who do I send this to in order to get someone to step back and
> re-think why it is that you [the collective you] seem to think that the
> planning and execution of a modularized application in AIR should not take
> advantage of precisely the same, sensible caching that is built in when
> the application is just plain old Flex?
>
> You can tell me that AIR is going to be able to use the Player 10 graphics
> primitives to stand on its head and sing in Swahili, but you have just
> devalued AIR with these changes. Sex appeal won't make up for solid
> systems engineering of large applicati! ons. I am certain no one wants to
> devalue AIR but just follow the parable of five applications out to a
> dozen or more and look how wasteful the AIR solution becomes. In the
> meantime, folks just staying with Flex and ignoring AIR will watch as that
> runtime library of cacheable infrastructure grows and matures.
>
> ________________________________
> View/reply at How to Test AIR 1.5
> < http://www.adobeforums.com/webx?13@@.59b6ed86/8>
> Replies by email are OK.
> Use the unsubscribe
> < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to
> cancel your email subscription.
>
>
>
>
> ------------------------------------------------------
> View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/10>
> Replies by email are OK.
> Use the unsubscribe form at
> < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to
> cancel your email subscription.
------------------------------------------------------
View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/11>
Replies by email are OK.
Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.
------------------------------------------------------
Replies by email are OK.
Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied