I downloaded TouchDB, a "lightweight Apache CouchDB-compatible database engine suitable for embedding into mobile or desktop apps", which gives me a bunch of .framework folders (CouchCocoa.framework, TouchDB.framework and TouchDBListener.framework).
I've been reading the article on binding Obj-C libraries to MonoTouch, it shows how to bind a .a, but not how to bind a .framework.
How do I make a binding for these .framework? or should I somehow make a .a of these .framework before using them (if that is even possible)?
--EDIT--
related : https://bitbucket.org/LouisBoux/touchdb-monotouchbinding
Bind a .framework in MonoTouch takes several steps, a .framework is a directory that usually houses all the parts of a library package (e.g., the header files, resources and the library file). Here are the general steps needed to bind a .framework.
Create a bindings project like you would for a normal library file (libXXX.a)
The library equivalent in a .framework is the file without the extension that is at the root of the .framework directory, for example I recently wrote bindings for RDPDFKit.framework, the top level file was a file named RDPDFKit (no extension), rename this to "libRDPDFKit.a" and copy to your bindings project and add it to the project. It will create a code behind file with the supported platforms (e.g., x86, arm6, etc). All the documentation for this is on Xamarin's web site.
Define the bindings as you would for a normal library.
If the framework has a .bundle, copy this to you Program project (not the bindings project), it will need to be added as resources for the program. Add this directory to the project and all the items underneath, this is because resources in monotouch are not supported in DLLs.
The resulting monotouch bindings DLL will contain the entire .a file for later linking so you won't need the .a file after building the .dll.
You can use the .framework files just like the .a files. E.g. all the bindings MonoTouch provides (in monotouch.dll) are made from .framework files.
Related
I'm trying to load a custom .dylib library via the dlopen() function (in a Swift iOS app). It requires a path to the library.
Where to put the library in the project structure?
What will be the library's path on the iOS device?
Also, a tangential question, it seems more usual to include the library's sources directly into the project and let Xcode build it. Is that a preferable approach for some reason?
1 )
If you include the .dylib library in with your list of files and resources in your project, you can use the "Copy Files" build phase to copy the dylib into your shipping app.
A tutorial can be seen here.
2 )
For dlopen, try using just the .dylib name before you try to use relative paths including the "#executable_path" or "#rpath" run time variables. An example can be seen here in this related question.
As for why some developers prefer to include the library source code in a project, I believe it's mostly just a preference by folks who aren't comfortable with the "Copy Files" build phase or in using dlopen.
I want to deploy a static library that I've been writing in Xcode 6. I've already managed to compile the library into a .a file. Now I want to use it in another project. Also, note that including the library project is not an option, as this library is supposed to be distributed in binary.
I also managed to import the .a file into a new project, but I'm not sure what the best way to find the header files is. Should I copy them to a system folder? Should I just link to the framework's (downloaded) folder? Should I import the headers directly in the project? As the framework is meant for distribution, I think that ideally I would copy them to a system folder.
Finally, I've read that I need to build two different versions if I want the framework to be compatible with both iOS and the simulator. Is this true? Can it not be distributed in the same binary?
I distribute such a library for my company. I essentially put the .a file (built up with lipo) into a folder along with the headers. The client then needs to add the .a file to their project in the Build phases, Link Binary With Libraries. Then, they should add the path to the header files using a project relative path to the "User Header Search Paths". From my readme:
Process to Add the SDK to Your Project
1) Copy the xxx folder to the app folder, which contains the
".xcodeproj" project file, then add the directory to your project,
but don't add it to any targets (unselect the checkbox).
2) Add the appropriate library (iOS 6.0 or 7.0) folder, by going to your target's Build Phase tab, Link Binary with Libraries, tap
on "+", then navigate to the appropriate folder and select
libXXX.a
3) Add the following to the Project's Build Settings:
Search Paths -> Library Search Paths:
$PROJECT_DIR/xxx/ios // I have multiple folders each with a lib
Search Paths -> User Header Search Paths: $PROJECT_DIR/xxx
Linking -> Other Link Flags: -ObjC NOTE: If you fail to do this, your app will crash on launch (if it uses categories)
I use lipo to add both the Simulator .a files too - even thought this is not officially sanctioned. As others have said, Apple frowns on this yet offers no easy way for users of your library to use different .a files - the "official" solution would be for you to write a custom build script.
I have added a framework to xcode project. Under Build phases->Link Binary With Libraries.
The framework consists of a library file (.a file) and a folder "Headers" which includes all the necessary header files for that framework.
Now I am trying to import a header file in the framework to one of my classes.
#import <MySDK/MyHeaderFile.h>
But an error occurs "Symbol not found" while building.
My understanding was that, if we are using framework instead of library file there is no need to add the header files path in "Header Search Path".
But still, I have specified the path to my framework in header search path.
Also I have specified the framework path in Framework search and Library Search path options.
This is first time I am working with frameworks. For libraries I just added the .a files and specified full path to header files in header search path.
What configuration am I missing for adding frameworks?
If it's a static library file and a bunch of headers, it's not a framework. A framework is a specific method of packaging files. On MacOS X static and dynamic frameworks have one structure, while static frameworks on iOS have a different structure.
For a static framework using Xcode 5, your file structure would look like this:
MySDK.framework/
en.lproj/
Headers/
MyHeaderFile.h
Info.plist
MySDK
Where MySDK is the binary archive file (it should not be MySDK.a). If you have a file ending in .a , you have a static library rather than a framework. Building a static framework using Xcode 5 isn't easy but it is also not impossible. Building a static library is much, much easier and trouble free however. It sounds like you already have a static library, so you just have to tell Xcode where to find the library archive and header files using the appropriate search path settings for your project or target.
If/when you DO have a framework, adding it to "Link libraries and frameworks" OR setting "Other linker flags" to "-framework path/to/MySDK.framework" will work fine.
Newer versions of Xcode may support different functionality for building or using frameworks, however linking against them should be largely the same.
MySDK/MyHeaderFile.h : This explains that your library is inside MySDK folder. Check if it exists in same path. Otherwise you'll get "Symbol Not Found" error.
I am testing an image capture library that sent over their code library as a regular header file and a file ending in a "*.a" extension. I am not familiar with using a file in this format and can't seem to find the right "magic" to search for.
What does this file extension stand for?
What if any extra steps are needed to get it integrated with my XCode project?
Maybe a bit more of theory can get you in the right track so you'll know how to search next time:
.a files are archives of object (.o) files. These object files are generally produced by an assembler, compiler, or other language translator; They contain machine code that is usually not directly executable, but are used by linker tools to generate an executable or yet another library by combining parts of these object files.
Another important thing you should know is that since these files contain machine code, they must have been compiled for the correct architecture you're targeting for (ex.: armv7, i386, etc). That can be the reason why sometimes you will be able build your project for one device but not to another if you don't have the right set of files for the targeted platform (e.g. iPhone simulator vs. actual iPhone).
It is also possible to have "universal binaries", which are files that in turn package together archives of object files (.a) for different architectures (e.g. using tools such as lipo), so that the same library file can be given to the linker for multiple architectures. Or, you may have a different linker configuration for each target (e.g. using conditional build settings in XCode). All of these files can be analyzed with certain tools (e.g. "file", "otool", "lipo -info", etc), and each has several parameters to play with. Debuggers will also check the symbols within these files for their own purposes.
When you drag the '.a' file to your project's directory within Xcode, you can notice that it will automatically add this file to the list of "Link Binary With Libraries" items under your target's "Build Phases".
Since the header files allows us to separate certain elements of a program's source code into reusable files, that commonly contain forward declarations of classes, subroutines, variables, and other identifiers that are needed for reference during the compilation step, it is common to have libraries provided as archives of compiled objects (.o) in ".a" files along with their respective headers. For instance, as soon as you include the headers files in your XCode project, the editor will provide auto-complete for these new functions.
Sometimes, you might also consider having the actual source code of the library instead of binaries inside your project as this * might * make debugging easier in case an unexpected behavior is happening inside that "library" package. Many times this is not an option though (when you have no access to the sources) when the binary distribution is made in purpose to hide implementation details (commercial libraries).
.a stands for archive. It is also known as a static library. I believe you should be able just to drag it and the header files into Xcode. Xcode should pick up the right thing to do from its extension.
Example, see appr. from 30 sec here
http://memention.com/ac3dreader/usage/quickstart.html
Another example from Google Analytics, under Setup
Drag GANTracker.h and libGoogleAnalytics.a from the SDK's Library directory into your new project.
https://developers.google.com/analytics/devguides/collection/ios/devguide
I used to copy/paste my IOS plugin files inside Plugins/IOS folder on my Unity project, but it doesn't work for bundles (as it has directory structure).
I can't beleave there is no way to generate xcode project from unity with .bundle inside?
Any help appreciated
Unity3D will not contains folders in the Plugins/iOS to Xcode project. In fact Unity3D will only auto merge source file and .a library for you, as described by Unity3D's doc:
Automated plugin integration Unity iOS supports automated plugin
integration in a limited way. All files with extensions
.a,.m,.mm,.c,.cpp located in the Assets/Plugins/iOS folder will be
merged into the generated Xcode project automatically. However,
merging is done by symlinking files from Assets/Plugins/iOS to the
final destination, which might affect some workflows. The .h files are
not included in the Xcode project tree, but they appear on the
destination file system, thus allowing compilation of .m/.mm/.c/.cpp
files.
Note: subfolders are currently not supported.
But you can use the PostprocessBuildPlayer attribute to implement this yourself. I made a tool for this purpose called XUPorter, which can make exporting and libraries setting easier from Unity3D to Xcode. You may want to see it on GitHub. There is a demo in the package and you may set your bundle under the 'folders' tag.