My friend, former co-worker, current co-author, and Yahoo! Maps genius, Chuck Freedman, made an interesting observation about the size of Apollo apps today.
As Flash developers over the years, we’ve had it beaten into our heads to keep apps small. Embed small assets in the swf, load in larger things at run time. Keep things that might change outside the main app.
This is something I’ve been thinking about with Apollo as well. I’m not saying to throw these things out the window, but you really need to rethink them. I was writing up something about embedding vs. loading the other day and realized that what I was saying really didn’t have the importance in Apollo that it does in a traditional app.
Normally, you’d embed smaller things that are less likely to change, and load in larger things or things that are more volatile.
As Chuck points out, file size is largely a moot point. At least to a degree. But even the dynamic nature of application pieces needs some thought. Say you build an app and you distribute it with some skins or other assets. You think, I’ll keep these outside the app, in case I want to change them, I won’t have to recompile the whole thing. But how relevant is that argument in an Apollo app? If the assets are distributed with the app, you’re going to need the user to go through an upgrade anyway – download and reinstall something. So does it really matter if they are are in the app or in a folder next to it?
Note, I’m not saying the answer is a definitive, “no it doesn’t matter.” I’m just saying think about it freshly. You might want to have the assets on a server somewhere and be truly dynamic. Or you might want to be able to just distribute a new set of skins only, or even allow the user to make his own skins. It might even be a better development flow to keep the assets external.
All I’m saying is that a lot of us long time Flash developers are going at things from a web-based development viewpoint, and desktop app building is a different story. Don’t take old habits for granted.
I would say it still matters if you keep several resources outside or put them into the main app. Not like web-based stuff but still you don’t want to create a memory hog. And some applications are huge memory hogs where you start wondering what are they using all this RAM for! For Apollo apps I would eventually try to write as memory-preserving as possible. The loading of external resources is not an issue for me. If the user should not be able to access any of these I user a custom built packer.
Again, I didn’t say it doesn’t matter, but to think WHY you are doing it, if you are doing it. I mentioned several reasons. Yours is another.
I’m confused, are you saying the “traditional” web based model is not really applicable in a desktop application environment? Personally i would say its naieve to approach any application without considering remote upgrade solutions these days. I was involved in a desktop application in flash 4 a number of years ago, and the first version we neglected to consider this, and as a result, when version 1.5 came out, it was all we could do to hope the users didnt mind downloading the whole application again. Surfice to say, breaking the architecture into teers, core components, and asset libraries etc enabled us to provide more fluid upgrades, with a better user experience. The only valid reason i can really think that you wouldnt break your application up is for security.
Maybe i’ve miss read your post here…is it hard to load external assets in Appolo?
Argh… I knew this post would get misinterpreted… 🙂
I’m saying that when I went to to explain some of the reasons we do certain things in Flash, some of those reasons weren’t necessarily applicable to a desktop application. There may be OTHER reasons why you would still use the same techniques, and if you have other reasons, by all means use those techniques. But you don’t have to just blindly use techniques designed for web apps when building desktop apps. I’m just saying think about it! 🙂
I usually find work looking for small studio that work on paper. The problem I have to switch the think of my clients from paper to pixels has the same gap as switching from a “browser” to a desktop (I mean no boundary defined) app.
NOT breaking up application for security is a faux problem for me. I have to find clients, so the better I work, the more clients i can have.
Distribute a client side app on cds or internet is the same as giving out all my work. You can scramble the code, but everybody can decompile it. I have to “trust” (some time) my client.
Dial up clients can take advantage of an interface that loads less “frills” content for example. (or a less defined set of pics.) We needs a new way to think to the application and also to the content to display.
KP- hey, I gotcha man. The post wasn’t a total loss 🙂 The prototype I worked on for our recently-announced system was in the same boat: built in Flash, desktop-based, HUGE supporting assets, distrubuted upgrades. It was definitely a shift for me to clear my mind of all the web-optimizing I’d been doing.
I don’t think anyone is suggesting that because it’s now a desktop app that you can stuff the kitchen sink in there but it does change the way you code and what may have caused hesitation for use in a web served enviro may not be the case on the desktop. The Flex components are a good example….we pretty much have to deal with the fact that dropping one in will creep us up to 300k right off the pop…sure aditional components added only add a fractional amount once the first is added but I know some guys who go nuts trying to keep web based export sizes down and literally treat every movie as if it’s being hit with a 2600 baud modem.
To new users…the differences of coding with Apollo to say Flash/Flex for the web will be a new revelation from concept to deliver. For the vast majority of existing commercial wrapper user (like myself) who use SWF Studio, Zinc and others…it’s nothing new at all and we (well…I) aren’t as concerned with file size as I am with what options/features it brings to the table. The html engine alone makes it worth every drop of anticipation not to mention the myriad of other things it does far and above what current wrappers do so to this crowd is going to be the crowd that right out of the gate is all over Apollo like flies on cowpie and who will be the most familiar with this type of coding. Apollo has to have a few of the big name commercial wrapper vendors worried. It’s priced to kill and sounds like it’s going to have it’s boxing gloves tied tight for competition in the desktop ring as far as features 🙂
2007 is really going to be fun.