I've spent some time building an iOS project, however I'd like to reuse one of the UITableViewControllers in another project.
This UITableViewControllers is quite complex (being a custom UITableViewController that inherits from another ViewController and contains multiple classes via #imports, so its not simply a case of copying over the .h, .m and .xib file)
Whats the best way to do this in xcode4? The options I've considered are building a library (.a), a framework (.framework) or importing the new xcodeproject into the original one.
Thanks
I think building your custom view controller into a static library would be the easiest method to include it in your new project. But will require a bit of work in the old project to make sure you get everything included and built correctly. With Xcode 4, libraries are no longer built into 1 static fat library, you end up with 1 library just for the specific build. e.g. iphonesimulator-debug. You will need to either include all the different versions of these libraries or add a build script that will build all of them in create just 1 static library (which will make your life much easier I can promise you that).
This post on SO, Build Fat Static Library, saved me hours of work with static libraries. Hopefully it will help you too.
Related
During my work with development of iOS applications, i noticed that almost every application has some parts that are repeated. For example every application has user management logic, Login, Sign Up, Forgot password.
And every time, i find my self trying to manually import already developed logic (View controllers, nibs, storyboards).
My question is how can i implement these common features in separate component, so i can simply reuse them every time i start new project. Also notice that there should be possibility for small customisations, for example all apps have login screen, but UI design varies for every app.
Long story short, what i need is:
How to encapsulate commonly repeated features in separate component.
How to inject the component in the newly started project.
How to make customizations at the component, without changing the component core.
I guess that here should be made some combination of Framework (Or static library) and cocoa pods, but i wanted to hear if somebody have already developed some concept about this.
Yes, exactly as you supposed, the way I opted for to reuse components is through a static library or sometimes a framework of reusable components, implementing common logic or well structured classes to inherit from in the new projects, which I make available to the new projects as a CocoaPods development pod sitting on my development machine or in a shared git repository. This way should answer your questions 1 and 2. For your question 3, you can either opt to perform customisations to the core dismissing pod updates, or to adapt the core methods to a possible override in the destination project. Hope it helps.
How to encapsulate commonly repeated features in separate component.
Whatever you choose you are going to have to factor out the code your separate component requires from your code base. This is the first step in the entire process - so think long and hard about if it makes sense to turn it into a separate component.
So now you have some code you would like to reuse...
There are a number of ways of doing this, such as Xcode's workspaces, stand alone source files, static libraries and frameworks. Cocoa pods is a package manager and will help you maintain your framework - not write it :(
Xcode's workspaces
A workspace is an Xcode document that groups projects and other
documents so you can work on them together. A workspace can contain
any number of Xcode projects, plus any other files you want to
include. In addition to organizing all the files in each Xcode
project, a workspace provides implicit and explicit relationships
among the included projects and their targets.
Static Libraries
Introduction to Using Static Libraries in iOS
Static libraries provide a convenient mechanism for sharing code among
multiple applications. On iOS, static libraries are the only supported
library type. This document explains how to extract code from your
application into a new static library and how to use that static
library in multiple applications.
Frameworks
In OS X, shared resources are packaged using standard frameworks and
umbrella frameworks. Both types of framework feature the same basic
structure and can contain resources such as a shared library, nib
files, image files, strings files, information property lists,
documentation, header files, and so on. Umbrella frameworks add minor
refinements to the standard framework structure, such as the ability
to encompass other frameworks.
Frameworks are packaged in a bundle structure. The framework bundle
directory ends with the .framework extension, and unlike most other
bundle types, a framework bundle is presented to the user as a
directory and not as a file. This openness makes it easy for
developers to browse any header files and documentation included with
the framework.
Source Files
These are the classes you have factored out of your code base. You could just include them in each project you use them - for instance a separate repo, that contains all of your shared/common code that you add to your Xcode project's workspace. Very simple, not the best to maintain.
How to inject the component in the newly started project.
Depending on how you choose to implement your common code will effect this step. For source files you just need add them to the project and set the target. For frameworks or static libraries you will have to embed them in your project
For workspaces you will add the projects containing the shared code to the main projects workspace.
How to make customizations at the component, without changing the component core.
Again you may find yourself refactoring code so that you expose the UI controls or logic functions that you want to be able to customize. As a general rule the more you expose the more complex the code gets.
Short version of the question:
So basically what I'm looking to do is to take an existing library written in C (https://github.com/lsalzman/enet) and turn it into a static library for iOS.
I am just looking for an easy to understand step by step of how to accomplish this in Xcode.
Long version:
I've gone over some tutorials for making a simple static library that's written in Objective-C (http://www.raywenderlich.com/41377/creating-a-static-library-in-ios-tutorial), and I generally understand what is happening there, but I'm failing to understand how to do this with existing code written in C.
I think I'm getting close, but I'm not so sure.
I start out by making a "Cocoa Touch Static Library" project in xcode.
I add all of the enet .h and .c files
make sure the enet stuff is in my "User Header Search Paths" in build settings.
hit build - it compiles!
The generated .a file is 517kb, so I'm pretty sure it's building the enet stuff in at this point.
My problem right now though is that the header file for the library is basically empty:
#import <Foundation/Foundation.h>
#interface enet_ios : NSObject
#end
I'm thinking I either need to write a wrapper in Objective-C that talks to the enet library, or I need to reconfigure my xcode project somehow so that enet.h is the 'entry point' into this library and not xcode's pre-generated .h/.m files. I'm not really sure how to do that, though. Ideally I'd just like to skip any sort of wrapper and use what the enet library is already providing me.
Thanks for taking a look!
Question, are you trying to call the functions using objective c syntax / object orient notation? Then you do need a wrapper object, no way around that.
But if you are fine calling C functions directly, which is completely acceptable in IOS/Objective C, then it is a matter of making sure your header files from the enet library (the ones in the include directory I see in the github link you shared) are also distributed with the static library. This is a limitation of the static library. You can copy them with the *.a, but they must be copied with the static library. This does differ from a Framework, which has included .H and assets, which developers are not easily able to create with Apple's tools for IOS.
I find that library management with Objective C to be painful on its own and static libraries a challenge for this and many other reasons. One more suggestion, definitely more elegant and portable but slightly overkill for personal use, would be building the project as a cocoapod. You can do this by forking the project and converting it to cocopods. There are lots of examples of how the project structure should look on cocopods and other OSS like AFNetworking. This seems to be the defacto standard way people are creating IOS libraries. See http://cocoapods.org/ for more details. This will include the source code as the pod and compiled against the target application.
This is the only way i deal with my own libraries and third party libraries. It has gotten to the point that if the library doesn't use cocoapods, i don't use the library or fork it and do make it a pod myself....
First of all I'd like to say that I'm pretty new to this topic so I'm a bit confused on some general aspects of how it works.
Basically I'm working on an iOS project which has two targets, one is the app itself which I'm developing and it is a front-end iOS client, one is a static library which the former developer used to define classes belonging to a back-end framework.
Both the files of the app itself (the client I'm working on) and the static library (the back-end framework) are in the same xcode project bundle.
Even If I've never done the "setup procedure" of the static library anything seems to be working just fine on compilation.
Now the question is: I'm setting up unit tests because I'd like to start developing new features adopting a Test Driven Development approach, so one of the things I was struggling on was if I had to generate or not two separate test targets, one for the iOS app and one for the static library (since they're two separate targets), ore use one single test target for both the static library and the iOS App.
So, reading on the internet to find a solution I discovered that, as even Apple suggests here , a common approach is to add the static library as a "sub-project" of the app project.
I'm just asking myself why and what is the difference with my current situation (one project, to targets, one of it is the static library). Are there any drawbacks? Should I reorganize the whole project?
My experience agrees with Apple and the common approach. I'd suggest making the framework a subproject. (I've had some issues finding headers, but that's my lack of mastery over Xcode, not a flaw in the process.)
Set up unit tests on each project, independently. This way, your tests are true to your objective with a framework: You've successfully decoupled the framework from the parent project entirely.
If you write the all of the unit tests in the parent project, what happens when the framework is needed in another project? You've got two choices. You can not test the framework, or string along the original parent. Do the right thing and split up your tests.
I've got an open source framework that I built, called SpiffyKit, that has a parent project called SpiffyTester. (I admittedly didn't unit test much, because it's all UI and no logic.) It may serve as a good example of a starting point.
Depending on your needs you can use Pods, static or adding it to the project. If you add a library as a "subproject" is useful when you are working on the 2 projects at once. For example if you add something new to the library you just compile the library and voila you have access to the new library in your project. However if you just link the static library you will have to open the project for the library then build then replace it in the library and add the new headers witch is a lot of setup work.
Let's suppose that I want to create an Xcode static library.
I use the Xcode provided template for this kind of project "Cocoa Touch Static Library", i want this library in a separate project because:
I want be able to keep this project under git version control
I want to be able to import this static library under other project as a git submodule
Now let's suppose that this library depend on third-part library such as ASIHTTPRequest.
Maybe in my main project (the one that import my static library) i will also depend on the same library. What's the best way to handle this multi-dependecy?
PLUS: Now suppose that i want to create a second static library (this one is more specific for some kind of task and i don't want to mix this code with the code of the previous mentioned static library) but this second static library depend on the after mentioned static library. Again what the best way to handle this
Your question is not super clear, Luca, but let me see if I can help you out a bit.
In one of my own projects, I have a number of embedded (or "sub") projects which get built as libraries included in the main project. So if one file in the sub project changes, both the sub project and the main project pick up the changes.
With Xcode 3, it was a snap to simply drag and import one project into another project and if you have Xcode 3 installed, I highly recommend using Xcode 3 to embed one project into another.
Xcode 4 does handle projects already embedded within another project (like what you might have created using Xcode 3), but the ability to actually do the work on it's own is not fully implemented or baked yet (in other words: it does not work well or at all). Here's another question somebody else asked with more information that might help you.
Also, I noticed this other related question.
Does this information help you out?
I'd like to separate reusable code in Xcode 4 as a separate project/library/something else. The reusable code in this case is a game engine, and the main project is a game itself. Idea is to make the game engine code easy to use in the future projects.
Xcode 4 lets me create a blank project or a static library for iOS. Which one would be preferred (or would something else work better?) under KISS principle? I just want to separate two logical set of files into two projects (it's ok if one is a child of another), and to be able to compile them at the same time. I don't have a need for obfuscation and I've heard that with a static library one has to worry for which architecture it was built for, which sounds like an overkill.
I feel that a blank project might be better way to go than the static library, but I don't have any practical experience with this. Any preferences and why?
I ended up going with the static library since that seems to be preferred way of doing this in Xcode 4. When it works, it works great, but took me a while to set it up properly - these two links were invaluable:
http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/
and
Compile, Build or Archive problems with Xcode 4 (and dependencies)
Just create two projects. Add the dependent project into the main project. The Click on the Main XCode Project, Go to the Build Phases Tab, Under the "Target Dependencies" section click + sign and add the second project.