You can mail me the doc and I can see if I can post it too. mchotin@adobe.com.<br /><br />Matt<br /><br /><br />On 12/1/08 2:24 PM, "Terry Corbet" <member@adobeforums.com> wrote:<br /><br />A new message was posted by Terry Corbet in<br /><br />Developers --<br /> How to Test AIR 1.5<br /><br />Matt says that on his page he has an option to add an attachment, but that does not appear on mine, so here is Select All, Copy, Paste out of the PDF document:<br /><br />=========================================================================<br />AIR Modularization - One Point of View<br />Background/Preface<br />I have been seeking an answer to just one limited question from a myriad of questions that could fall under the heading of AIR Modularization. Now Alex Harui has replied with some suggestions and has asked for some input concerning a broader set of issues that need to be considered. My intention, in this document, is just to respond to Alex's suggestions within my original, limited scope. I do hope that others will address the broader issues, and I don't minimize them in any sense. But, at the end of the day, I am most comfortable in speaking to the matters that have arisen from my own attempts to develop a workable modularization scheme.<br />The Basic Architecture of the Application<br />When the application is launched the user sees a simple screen that is divided vertically between a left and a right side. The left side displays the functionality of the application in the form of a Menu Tree. The right side uses the TabNavigator control for providing the 'stack' of Functional Features. We previously developed most of the functional capabilities using the Java SWT toolkit, and had essentially the same layout and the same controls.<br />So, that is just to say, that we think this general presentation is clear and open-ended in ways that make it relatively easy to engineer an ever-growing set of Functional Features. Examples of Functional Features are a JukeBox, a Shared White Board, a Content Management System, a Sudoku Game and 3D Books with interactive content. Those are what we consider 'modules'. They are virtually independent sub-applications that might otherwise just be run as fully-separate applications in separate invocations in their own Operating System windows. Of course, we don't want to offer them as separate applications running in separate windows; we want to coordinate things through a common infrastructure, and common look-and-feel.<br />The degree of independence of these types of modules is such that it is usually possible for the engineer to go off and perform most of the development and test as stand-alone code in order to maximize test turn-arounds. Unit testing and even some integration testing can take place without having to bring the whole main application up and down all the time. I think there is nothing very unique about our approach, so I am certain that many other developers work in a similar environment. [That is not to imply that there are not other approaches that may have rather different characteristics and requirements.]<br />AIRness<br />So, as described to this point, we can achieve most of what we want to achieve just with the Flex api, and, indeed, that is basically how we prototype new Functional Features. But there are compelling capabilities that are only available by moving up to the AIR api.<br />With more and more folks having wide screens or dual monitors, it is natural to want to break out of the constraints of rectangular Panels obscuring each other in a stack.<br />Now you might argue that just using AIR for more interesting windows is not a very deep investment in all that AIR has to offer, and that won't hurt my feelings. Of course we also take advantage of many other AIR-only capabilities, but admittedly the driving force is more interesting visual experiences, and stating that may help you understand why there are many other considerations in the topic of AIR Modularization, on which we do not concentrate. Again, that is not to indicate that we are unappreciative of the 'larger issues', but it is to emphasize what we believe, which is that the functional capability we are seeking ought to be made available immediately rather than waiting until 'AIR matures' or 'the whole picture can be understood'.<br />Provisioning and Version Management<br />Rather than answering questions about whether our application runs entirely or primarily 'off-line' we think it is more helpful to describe our requirement for network access in terms of the way the software gets to the desktop. Whether a new Functional Feature ends up being designed and built in such a way that the user can take full advantage of it on-line or off-line is a continuously-changing thing. If today, an inventory of our sub-applications happened to show that 80% of them could be used off-line, the on-line requirement for the remaining 20% would still be there. In short, at least for our business model, we would never be interested in shipping entirely off-line applications, so network traffic will always have to be well managed.<br />Given that, it seems to be more helpful to look at network activity in the context of getting the Functional Features to the desktop from a server. In other words, even though we are devoted to AIRness, from the standpoint of software downloading, we look at lot more like what I think you expect for Flex.<br />Yes, the user should normally start-up our application from his desktop, and he ought to be able to succeed in doing that even when he has no Internet access. He ought always to be able to use the Functional Features that can be used off-line. That said, if the user wants the 'latest and greatest' we expect him to start up with an Internet connection. So, our startup sequence looks like this:<br />A.<br />Read a VersionManifest from the Application Directory.<br />B.<br />On a module-by-module basis compare the Version in the Version Manifest with the Currently Installed Version List that is stored in the Application Storage Directory. If the VersionManifest says there is newer code available, download it.<br />So, as you can tell by reading-between-the-lines our process for 'pushing out an update' does not involve pushing out the new code. We just push the new VersionManifest, the code will be fetched later. That gives us lots of flexibility in terms of different configurations of our application at each customer site. While a test/release cycle will<br />likely update many 'modules', not all users may need, or even have access to all 'modules'. Moreover, if all we need to update is a small amount of code in only one Functional Feature, we can easily do that without holding up the whole release cycle for some sort of magic - integrated everything. Our modularization allows more responsiveness to the customer and to the competition.<br />So, are we concerned about bandwidth? Yes we are. It's not that we are looking to save a couple of megabytes every time any user runs anything, it's that we are looking to save a couple of megabytes every test/release cycle. And that is probably the main point of all of this. Whether it is because we are dumb, or because we are clever, the frequency of test/release cycles is NOT anything like 'once in a while', it is more like 'every two weeks' for 'production'. For rapid prototyping, and maybe premature bug-fixing, let's face it, our needs are often something like 'every night'! [Not to mention the fact that it is important to have geographically-disbursed development centers - if you are larger and more successful than we are - and so saving a couple of megabytes of data traffic to 'refresh' a remote development/test location is something that might easily occur several times an hour.]<br />Please may we use Dynamically-Linked, Cached Frameworks<br />For now, that's all we are asking. You already have engines - I am not sure whether all the logic is in the Flash Player, or whether the AIR runtime just shares some source code from the Player build stream in its own stream, but wherever it lives, it already knows how to recognize when a swf file needs to be linked to a .swz file. In the Flex case, the engine knows where to look for the necessary .swz file, and so should it quite as easily know where to look in the AIR case. It is, as far as I can tell, just a ma<br /><br />________________________________<br />View/reply at How to Test AIR 1.5 <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/25><br />Replies by email are OK.<br />Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to cancel your email subscription.
36
Replies
AdChoices