On Mar 30, 2012, at 1:54 AM, Joar Wingfors wrote: On 29 mar 2012, at 11:19, Don Quixote de la Mancha wrote:
And the only benefit, really, is that you save some disk space. Most frameworks aren’t big enough that this makes any measurable difference.
Using shared frameworks or shared libraries has the added benefit that the user saves memory when they are running two or more clients of the frameworks simultaneously.
Perhaps. But: [1] Very few developers ship suites of apps that could benefit from that in theory or practice, and [2] we're in any case not talking about a lot of memory to be saved (vs. what's installed on modern machines and vs. what the apps would dynamically allocate).
The pros. of embedded frameworks FAR outweighs the cons. in my book.
I agree. My frameworks for writing assistive applications <http://pfiddlesoft.com/frameworks> started out many years ago as frameworks designed to be embedded in the application package, and I used them in several application products that I have sold for several years. Two or three years ago I did some minimal redesign so that the frameworks could optionally be used as shared frameworks, and I updated all of my products to use shared frameworks instead of embedding the frameworks. Since then, some other developers have begun using my frameworks with their products, too, but as far as I know they always embed them in the application package.
I am going to revert all of my own products to embed the frameworks, over the course of the next year or so. Here's why:
1. Because my frameworks have undergone revisions over the years, many of which required interface changes that I did not (and maybe could not) have anticipated, I have had to increase the major version of the frameworks several times. As a result, in order to ensure that the shared frameworks continue to support older application products that may still be installed on the customer's disk, the frameworks now contain several versions of the object code (A, B, C, etc.). As a result, the frameworks, though shared, undoubtedly consume more memory on disk in the shared frameworks location all by themselves than would be true if half a dozen applications were installed that all embedded separate copies of some major version of the frameworks.
2. By requiring a shared framework, all of my applications must be installed using an installer package instead of drag-and-drop. Personally, I don't mind installer packages, but lots of people adamantly prefer drag-and-drop installation.
3. By requiring a shared framework, my applications are barred from the Mac App Store. My products happen to be barred from the store for other reasons, too, but for most developers this might be a killer.
Although writing and packaging frameworks that are capable of being used as shared frameworks, and writing installer packages, is not all that hard -- and my frameworks will continue to offer that option -- I have concluded that in the general case, and thinking long-term as an application product developer, it makes much more sense to embed frameworks in the application package. |