I have created a static library for my application. Now, my application uses sources like plists & images which I am referring in my application.
How can I bundle those images and deliver them with the static library and also what changes do I need to do in my source loading code to load it from that bundle.
Right now I using [UIImage imageNamed:"my.png"] to load the image.
A library cannot have "resources". A library will just provide some algorithm or logic to get the things done. So you cannot include any resources with in your library. Along with your library, you have to distribute the resources also. Or else the app that is using the library must have the resources with the same name that you hard coded.
That is exactly the reason to create a Framework - in a Framework you have:
A static library (with binaries for
simulator and phone melded together)
Include files a user of the framework
needs
Resources the framework needs, which
can be anything including .plist
files, images or xib.
Edit:
Removed link that was dead. You no longer need to know how to construct frameworks for iOS, because starting with iOS8 you can have Xcode create an iOS framework project.
In fact this is a great approach also, because frameworks can easily be imported into Playgrounds to call.
Related
What is the best way to reuse code within projects?
Let's say I implemented a UI Element and I want it to be used in both my iphone and ipad application without having to copy the code over and have 2 copies of it.
Just create a project, which includes all your shared code in XCode and reference this project in your iPhone and iPad application project. Plain and simple.
For me I would make a static library project which contains the shared code (UI Element in your example) in Xcode.
Then when I need to use the library in the iPhone or iPad app project, then I can just reference the static library project by drag and drop the project to the Project Navigator and configure the correct dependency, library used and header search path. In this way you always have a single source of library source code for easier maintenance and modification.
Certainly you can actually compile the static library into binary and link it to your project, but it just not too flexible when you find bugs in your static library and need to switch to another project to correct the bug, and then do the compile and copy of the binary library file.
I have just wrote an article (link below) on how to link up the static library project to an iOS project on Xcode 4.3.2. This maybe useful for you to solve the header not found problem you encountered. Hope this help.
http://vicidi.wordpress.com/2012/04/11/linking-an-ios-static-library-project-in-another-project-in-xcode-4-3-2/
What is the difference between a static and dynamic library in XCode? And why doesn't Apple allow us to use dynamic libraries in our iOS applications?
While you can build dynamic libraries for Mac OS X, you cannot use them for iPhone development.
A static library is merely an archive of object files that gets pulled into a program linking against it. The linker will unarchive all the archive files, and pull them in during linking along with the rest of your object files.
A dynamic library however, creates a shared object file, akin to a program but without an entry point, which programs can link against and call out of themselves into these shared libraries for their symbols, without pulling them into itself.
A dynamic library wouldn't make any sense for an iphone app as there is no way to install the library on the phone. I remember reading some documentation where apple stated they decided not to use dynamic libraries as they didn't want users to have to deal with hassles of finding/updating libraries. Much easier to just install 1 bundle per app.
Apple does allow you to make dynamic libraries. On Mac OS X, these end in .bundle or .dylib (not .so or .a like on Linux).
What, specifically are you trying to do? Did you create a target for your dylib?
iOS static vs dynamic library
Static library(.a) - library which copies all it's content into a target at compile time. That is why compile time is slower and result file is bigger, but there is no delay in run time
Dynamic library(.dylib) - library which has a single copy in a system where linking happens during run time. That is why compile time is faster, footprint of output file is smaller but there are some delays in runtime. Dynamic library is prerogative of OS(a lot of system libraries are dynamic) and as a developer you are not able to create it. Since such type of library is shared between different applications it should be secure and support IPC
Dynamic framework - framework with Dynamic library inside. Apple presented Dynamic framework and App extension[About] from iOS v8. You are able to use it inside single application to share common code and resources inside app sandbox
[Vocabulary]
I am creating an SDK for a client that includes predefined view controllers. What is the recommended way to package everything (static lib, .xib(s), and .png(s)) for easy use?
SDKs that I've used (e.g. Pinch Media) do a good job of just providing a .h and .a file that expose only user accessible functionality and hiding everything else. As I read Apple's documentation, a framework would be ideal but is not permitted on iPhoneOS.
Some key requirements:
Don't expose source or object
internals.
Be easy to use & set up.
Work on both the device and simulator.
Thanks!
Frameworks would be ideal, but as you said, aren't allowed on the iPhone. I think in the end you'll need to provide at least 3 files: a header file, a static library, and a resource bundle.
The header file would simply have all the API's you do want to expose. If you have multiple classes you may want to provide multiple headers.
For the static library I recommend compiling it like normal for each architecture (Device and Simulator), and then use lipo to combine them like so (replacing paths as necessary):
lipo -create -output output/file/path device/file/path simulator/file/path
With the bundle you can make a new target in Xcode to create a bundle, but really it's just a folder. You would also need to make you're SDK know how to load the bundle, and get to the resources. You can't load executable code from the bundle however; that is the reason frameworks don't work on the iPhone.
working on an iphone app and separate framework.
the separate framework is for an API that i'm building for use in multiple future apps.
this api now needs to reference resources (images). what i would like to do is keep the resources WITH the API framework as local set of resources.
i followed the instructions from http://www.clintharris.net/2009/iphone-app-shared-libraries/ to setup my app's project to use the headers from the separate API framework.
what i can't seem to figure out is how to automatically load the framework's resources into the app's xcode environment so they can be linked in at app compile time.
sure, i can drag the resources across from the framework into the main app's set of resources. but that seems kinda ugly and another step that possibly can be automated (??) anyone know of a better way? it would be great if any changes from the framework would be automatically available in the main app (due to the project 'link-age').
thanks for any help/tips/suggestions...
You can't make your own frameworks and have the apps made with that framework get accepted into the iTunes store... Apple doesn't allow other frameworks in the App Store.
Is it possible to create an own obj-C Cocoa Touch framework which can be used by other developers? And furthermore can you protect this framework?
I've created templates for Xcode 4 that allow you to build universal iOS frameworks (which work in both device and simulator).
Once the templates are installed, you simply select "Static iOS Framework" when creating a new project and it does the rest. It also works with unit tests.
https://github.com/kstenerud/iOS-Universal-Framework
You can create a static library. There is an option in the XCode project chooser to do this. You'll have to distribute the compiled static library file and the header files to users of your library. Your actual implementation files (.m) do not need to be distributed.
GHUnit does a good job of this - packaging up the libraries for both simulator and device - so I recommend looking at this project. (I also recommend using this library for unit testing :-)
The frameworks in Objective C are typically just C / ObjC code and a bunch of classes, nothing amazingly special. As such, you can create your own if you'd like, and then just include that in your project when you build it. The iPhone doesn't care about the difference, it just knows to put all that code into your app, along with everything else.
Have a look at the Framework Programming Guide on Apple's website. It will get you started. Essentially what you'll do is create a Framework project in XCode and then go from there.
As for "protecting" your framework, I assume you mean making your code unreadable. I'm not sure if and how you can do this, but perhaps Apple's guide will say something about it.
Yes you can create frameworks for use with Cocoa Touch.
However there are these caveats:
has to be a statically linked libary, no dynamic loading (dyld) for us
should be a combined (lipo) library for i386 (simulator), arm6 and arm7
you need to hack a bundle project into a framework
you should embed (small and few) images into the library so that the developer does not have to mess around with resources but just drags/drops it into his project
... or if you have large and many images build a bundle with these
I have guides for these things on my site.
1+2 = http://www.drobnik.com/touch/2010/04/universal-static-libraries/
The other links you have to google because this site does not let me post more than one URL.
You could make a static library available as binary (i.e. rudimentary "protection") to third parties, but not a dynamic one, as Apple's App Store policy prevents dynamic linking.
Take a look at a worked example for static libraries given at
this site
If you're going to do it, in my opinion JSON.framework is a great example to follow. To hide/obfuscate the source code is a different story, and a different question entirely,
When creating a new project, navigate to iOS > Framework & Library > Cocoa Touch Framework, it's as simple as that. When you are successfully compile, .framework will be created under Products folder in XCode. Right click to show in Finder, and you can find the output.
It's unlikely this will work the way you want it to because the other developers won't be able to use your framework. This StackOverflow Question explains why.