Hi experts i have created a set of UItableviewcustom cell classes. Now can i group those classes to an static library so that i can include that library in whichever project i want and i can use it.
You can, but it really isn't worth the trouble... with the rate that they keep on releasing new SDKs, and considering that you'd have to make it a Universal binary supporting both the simulator and the iPhone device, it really isn't worth the effort... I'd just save the ".h" and ".m" files and drop them in a new project.
However, if you are absolutely determined to go that route... I do have some articles on creating iPhone frameworks: here. Note that they are somewhat outdated (circa iPhoneOS3.1), so I don't know how much has changed, and I've since converted to the Android camp... but you still might find the info there useful.
Related
I've been writing iOS apps for some time now and for this particular project, I decided that I needed a static library for code sharing purposes.
I've followed some tutorials in creating static libraries and everything works perfectly.
Now I wonder, is there any way of versioning the static library?
I couldn't find any files regarding version number in the static library project, nor any good search results (both Google and here) regarding this particular issue.
I think I could create some kind of "fake" Info.plist and store the version info there.
Is that the way of doing it? Any other approaches to the problem?
Edit:
I think I may have not been clear on my purpose:
I have a workspace that has both my library project and related projects using the library, which is imported using the .xcodeproj file, then configured the dependencies so it builds whenever needed.
I just need some way of versioning the library, so that I can include that in some sort of about box, just in case.
I think you should stay away from bundling binary builds of your own code. Unless you're building a really, really, really massive library, you're better off just importing the code in any of your projects, and rebuilding it each time. You can put it in a separate target though, so Xcode doesn't rebuild it all the time.
You might want to write a tool that takes version info in a .plist and writes it out as literal strings defined in a .h file, which you can then include in your own code.
To make it foolproof (avoid mismatch between the header and the library), define a class method like [YourLibraryClass versionString] that returns a NSString with the version number or signature.
TL;DR Version:
This question has arisen due to the fact that I have multiple frameworks (which I have built) and a client project that uses said frameworks. Now, when I open up the client project and try to debug into the framework, it doesn't work.
However, if I have the project associated with the framework open, then debugging appears to work (though there are some weird issues with breakpoints I don't see being triggered).
I have looked at Apple's docs, and perhaps the answer is buried there somewhere, but I couldn't find it on a skim of the Xcode Debugging Guide.
Long Version:
The reason this question is important to me is that a coworker and I had a disagreement about how headers are imported in the frameworks we build.
I have a tendency to use framework headers (with client apps) in the fashion:
#import "FrameworkA/HeaderA.h"
#import "FrameworkB/HeaderB.h"
He, on the other hand, favors importing the framework headers (with client apps) like this:
#import "HeaderA.h"
#import "HeaderB.h"
and specifying the header search paths in the build target of the client application.
Complicating matters further is the fact that some of these frameworks have interdependencies. For example, FrameworkB has headers from FrameworkA referenced in his format:
#import "HeaderA.h"
His argument for doing this is that debugging only works if we import headers this way. It seems dubious to me that there would be a relation between header importing style and debugging, but I am not really certain how XCode chooses the file to link to during debugging, hence the question.
Thanks in advance for any assistance with this query.
you add project references to the target, and make sure Xcode knows where to find the debug symbols.
#import <FrameworkA/HeaderA.h>
that's the way to go (for internal and external declarations). the reason? the other approach is more likely to cause issues as libraries evolve. the additional qualification disambiguates any case (unless of course there are two FrameworkA/s in your search path), it's best to qualify the file explicitly now, rather than when your clients tell you they cannot use your library with other libraries, or that they can only use them in some conditions. then you have to go fix the issues and reship (this stuff has a way of happening at inconvenient times =p). it's one simple measure to ensure you've developed a robust interface.
perhaps the most important part that people overlook is the location of the products: use a customized central build location for your targets -- many people use the default location, which is by the xcodeproject. otherwise, Xcode may not be able to locate debug information.
finally, debugging complex projects in Xcode can be quite... let's call it 'problematic'. So don't expect the debugging experience to be perfect, even if you've configured everything correctly. all the more reason to integrate assertions and unit tests into your development cycle early on with Xcode. truth is, the debugger may be useless no matter how hard you try - this is not a new issue. hopefully LLDB will improve our debugging experiences.
good luck
i want to share some code with other iOS projects. So I create static library.
When I use this library in other projects and use header file from that lib I get an error like No such file and Directory. Can any one tell me fixes of it.
Here I get reference for making static lib
http://www.amateurinmotion.com/articles/2009/02/08/creating-a-static-library-for-iphone.html
I downloaded that sample. It is also not working in my case. So please help me to fix that error.
Thanks in advance
My guess would be because the blog, whilst detailed, is probably a bit old now. Like anything there's a thousand ways to skin a cat.
You can now create frameworks for the iPhone sdk and include both simulator and device versions of the classes. Frameworks have the advantage that they can simply be dragged and dropped on Xcode to include them in a project. In addition I like to store my frameworks in version numbered directories so if I make changes, dependent projects can still use the old ones until I'm ready to update them.
I don't do it, but for the above reasons I'm not sure I'd drag and drop a libs project on a client project. To me the idea of a static framework is that it's independent on it's clients. Dropping it into client projects makes a connection between the two projects that is too tight.
Anyway do some searches on lipo and static frameworks. I also have so scripts in my project at https://github.com/drekka/dUsefulStuff that you mint find useful.
love this site and all helpful people! I'm newbie to Xcode and iPhone programming but I've pretty much got the hang of using the SDK to make programs in Obj-C (simple programs right now but make me happy). My experience is web programming (such as PHP and Perl) and I'm not really used to a lot of the new Xcode/desktopy-app stuff like static libraries and linking and such. I be honest, I am not total awesome programmer yet!
I have a problem right now, my (card game) program I am writing needs to use this C library. I don't really understand how I get the proper C files and integrate them into my project so I can start using the commands in that tutorial to evaluate hand values.
I hope I have been clear, please let me know if there is anything I am leaving out. Unfortunately, my newbieness may prevent from me making everything so clear and sometimes I can't english perfectly what I am thinking!
Happy thanks in advance, looking forward to any help!
Couple things:
The library you linked to is quite large. Pokersource appears to be a large C project containing all sorts of things like language bindings and some GUI tools as well. A project that large certainly has an IRC channel. I would recommend going there.
The library you linked to appears to be (I may be wrong about this), licensed under the GPLv3. This means that any program that you distribute to others that uses a GPLv3 library or piece of code must also be licensed under the GPLv3. The upshot is that if you use that library, you'll have to release the source for your game.
The site you linked to does seem to have a long list of other poker hand evaluators, so its possible one of them is suitable for your needs.
Good luck!
it's totally possible to use third party static libraries with your iPhone and using Xcode. This webpage illustrates the process of doing it.
I'm trying to write an SSH client for the iPhone, and I'd like to use the libssh2 open source library to do so. It's written in C.
How should I include this C library for my iPhone app? Should I compile it into some binary that I include into the my app, or do I add all the source to my project and try to compile it along with the rest of my app?
I'm interpretting this question as:
"Should I compile the C library code once, and include the binary library in my project? Or should I include all the source and compile it every time I build my app?"
It depends. One of the projects I work one depends on several external libraries. Basically, we have a simple rule:
Do you think you will need to change code in the C library often?
If you will be changing the code, or updating versions often, include the source and build it with the rest of your project.
If you're not going to change the code often or at all, it might make sense to just include the pre-built binary in your project.
Depending on the size of the library, you may want to set it up as a distinct target in your project, or for even more flexibility, as a sub-project of your main project.
If I was in your place, I would build libssh2 ahead of time and just include the binary library in my iPhone project. I would still keep the libssh2 source around, of course, in case it does need to be re-built down the road.
I have an iPhone app that is 90% c. I have had no problem adding 3rd party sources to my project and compiling. I am using Lua, zLib, and libpng with no modifications. I've also included standard libraries like unistd and libgen and they just workâ˘
The Three20 iPhone library has a great howto on adding their library to your xcode project. Give that a shot.
I think you will find in the long run you will be better off building it into a standalone library and linking it with your application. This makes it easier to integrate into future apps. Another benefit is that it encourages code separation. If you feel pretty confident with the library, you can link your debug exe to the release build of the library and get some extra performance.
I can't really think of any downsides to creating a library, after the initial cost of setting it up, and having an extra project to modify if you have some changes that need to be made to all your projects. Even if you don't know how to make a library for the iPhone, this is a good excuse to learn.
Just adding the source to you project should work fine as well.