I understand for non-iOS targets, using shared libraries can lead to lower memory usage, and also that some companies distribute a library and headers (like Superpin) and a static library allows them to not distribute the source of their product. But outside of those, what are the reasons you'd want to use a static library? I use git for all of my projects, and I usually add external libraries (open source ones) as a submodule. This means they take up disk space locally, but they do not clutter up the repo. Also since iOS doesn't support shared libraries, the benefits of building libraries to promote code reuse seems diminished.
Basically, is there any reason outside of selling closed source libraries that it makes sense to build/use static libraries for iOS?
organization, reuse, and easy integration into other programs.
if you have a library which is used by multiple apps or targets multiple platforms, then you will have to maintain the build for each app. with a library, you let the library maintainer set up the build correctly, then you just link to the result (if it's developed internally, then you'll want to add it as a dependency too).
it's like DRY, but for projects.
libraries become more useful as projects become more complex. you should try to identify what programs (functions, class hierarchies, etc) are reusable outside of your app's context, and put it in a library for easy reuse - like pattern recognition.
once your codebase has hundreds or thousands of files, you will want to minimize what you use, and you will not want to maintain the dependencies manually for each project.
Also since iOS doesn't support shared
libraries, the benefits of building
libraries to promote code reuse seems
diminished.
There's no reason you can't build your own static library to use across multiple projects.
Other than for that purpose and the ones you mentioned I don't think there's much else.
Static libraries allow you to have truly standalone executables. Since all library code is actually, physically present in the executable, you don't have to worry about the exec failing to run because there's a too-old version of some library, or a too-new one, or it's completely missing, etc. And you don't have to worry about your app suddenly breaking because some library got replaced. It cuts down on dependencies and lets your app be more encapsulated.
Related
Just wanted to understand there are couple of code sharing strategies exist to achieve code reusable capability in Xamarin.
Which one should i use ?
Shared Project way OR Portable Class Library way ?
if you can explain with scenarios , it would be very helpful for me.
Thanks much.
Here is the Xamarin explanation.
The question is possibly duplicated but you ask specifically for scenarios.
If you ever wrote c cross platform projects, shared projects resemble the old-school way allowing you to use #if __IOS__ statements to run device platform code in your shared/common code files. A separate assembly is created for each target (say iOS or Android). They give advantages and disadvantages of each.
PCL generates one single assembly for the common code. PCL has some limited number .net features as shown here in this table. However, most of the important .net goodies are there as you can see.
Xamarin says that shared code method is easier but PCL is easier to compile a module and share or sell that with others.
When I make projects, I check what external plugins/components/ etc I want to use and make a decision based from. For example, you may want to use sqlite and there are different options for using shared and PCL projects.
I'm working on a fairly simple OS X app that uses a couple third-party libraries (SoX and TwoLAME) to do some audio converting. TwoLAME relies on libsndfile, and SoX relies on sndfile plus a number of other libraries.
For development, I simply installed the two libraries with Homebrew, which took care of the dependencies, and then linked right to them (ie in /usr/local/Cellar/...). Now that I'm ready to deploy, I need to figure out a way to get everything packaged up.
I know frameworks are a bit ambiguous in Cocoa (fake ones, dynamic ones, etc), but it seems like ideally I would end up with some frameworks of one kind or another that I can drop into the project and everything would work.
I've read through a lot of different docs and tutorials about frameworks, and tried a number of approaches, but I seem to be missing some core concept for getting this all to work together.
I have been able to make frameworks from the libraries that sort of work, in the sense that I compile from source, take the static (.a) library and put it in a "fake" framework with the headers, and the app will run with those. Those static libraries are still referencing the dependencies on my local path, though. So, eg, if I uninstall Lame from Homebrew, the SoX static library in my framework will fail.
I'm really struggling to figure out what the best way cleanly get all these libraries and their dependencies into this app. The tutorials I've seen about building dynamic Cocoa libraries from scratch have been very hard to do with the source code for these pre-existing libraries. The other option I have considered it build dylibs and then use install_name_tool to change paths to be relative just ship everything with the app and try to match everything up.
There's got to be some better way that I'm just missing, and would really appreciate any help.
I want to be able to add plugins for an application I am developing and as it is a development tool I want other people to be able to write their own plugins.
So my questions are what are the real differences between a framework and a loadable bundle? Which are more suited to being a plugin(accessing of headers, ect) ? And if I use loadable bundles how do I load them at runtime and access their functionality during development?
The plugins should not have to rely on other plugins.
Have you taken a look at NSBundle? It has all the methods you'll need to load the executable code at runtime. You'll want to define some sort of plugin interface to which any plugin will conform.
As for the difference between bundles and frameworks... Both bundles and frameworks are file structures that contain various resources that your app can use. A framework is like a library -- it's something your program links against when you build it. A bundle, on the other hand, is essentially a folder structure containing compiled code that you load at runtime.
Elaborating on the accepted answer, a bundle is more designed to be loaded and then potentially unloaded at a later time during program execution. Frameworks, once loaded are designed to stick around for the life of the process.
Frameworks are also designed to be self contained units of code where a caller calls into the APIs the frameworks exports. Bundles can be used when you want to have code call into the caller's public APIs. Check out ld64's man page. You can get hints for the intended usage of bundles with such options like -bundle_loader
What is the difference between a LIB and DLL? I have read plenty of posts on here about it and there are some good, clear answers however I am writing to ask for clarity on one matter.
Is it better to use a LIB (static link library) when there is only one user e.g. for a administration application client installed locally on the PC? and is it better to use a DLL (Dynamic link library) when there are multiple concurrent users accessing a classic asp application that uses vb6 classes?
A LIB file generally corresponds to a static library, which means that all of the library code that your application uses is compiled directly into your application.
A DLL file represents a dynamic library that your application links to, and then when you want to use code from the library, you call into it dynamically while your application is running.
Of course, you'll frequently see a LIB file for a dynamically-linked library as well. That file contains "stubs" that the linker uses to implicitly link to the DLL.
The obvious benefit of a DLL (dynamic linking) is that one DLL with common functionality can be shared with multiple applications that use that same functionality. Bug fixes can be made in a single place, and only one component has to be updated in order for all of the apps to take advantage of those fixes.
If you only have a single application that uses your code, there's little reason to put it into a DLL. Multiple users on multiple computers are going to have to have their own copy of the DLL anyway, so there will be no code sharing going on in that situation.
All of that said, I have no idea what this question has to do with VB 6. To my knowledge, you can only use it to create ActiveX DLLs (which have a different use case) and it can't create static libraries at all.
I'm still not 100% sure with the framework linking process, but from what I've seen here before nobody has asked a similar question, perhaps because this could be a silly question, but I'll give it a go anyway.
In my current X-Code project, I'm using a custom framework, say example.framework. At the moment, as far as I'm aware of, in order for the program to function with the framework, I need to have it either in /Library/Frameworks, or I need to have it copied into the bundle resources in the build phase.
Would anybody know about adding a framework to a project in a way that it gets compiled into the executable, so I don't have to include the raw framework with the app? I'd rather not share the whole framework...
Thank you in advance! Any suggestions are also welcome!
A Mac OS X framework is basically a shared library, meaning it's a separate binary.
Basically, when your main executable is launched, the OS will load the framework/dylib into memory, and map the symbols, so your main executable can access them.
Note that a framework/dylib (bundled into the application or not), does not need to contain the header files, as those are only needed at compilation time.
With Xcode, you can actually decide whether or not to include the header files, when you are copying the framework to its installation directory (see your build phases).
If you don't copy header files, people won't be able to use your framework/dylib (unless they reverse-engineer it, of course).
If you still think a framework is not suitable for your needs, you may want to create a static library instead.
A static library is a separate object file (usually .a) that is «included» with your final binary, at link time.
This way, you only have a single binary file, containing the code from the library and from your project.