I am currently working on a workspace with 2 projects. One project does not depend on the other. They are separate entities.
However a previous developer has implemented new features on the one project and I now need to implement the same features on the other project.
However the classes that he has implemented in the one project import other classes. These classes are not currently in the project I am working on.
What is the best way to share these classes across the 2 projects. I don't really want to copy the files over because that would making supporting the 2 projects harder. I.e - We would have to update both projects at the same time and is much more prone to a mistake.
Also when you do copy files from one project to the other (clicking copy) I am having a lot of issues with my project conflicting with the other project. Here is a question I asked about this issue: Xcode: Copy files from one Project to another in same workspace
Is there an elegant way to share these files across the two projects?
Thanks in advance.
If you work with Git, take a look on submodule
Related
We have a very big iOS application with multiple features, each feature has their own flow, some feature depends on another feature and a common datasource class to divide between each feature. Since because of this much code project taking lots of time to compile.
Can i divide the project into multiple projects and add into a workspace and compile only those projects in which making change.
I am not able to find how i can create dependency between projects and how can i access files form one project to another.
I don't want to create static library and into another project.
Any suggestion would be helpful.
I'm actually working on a project in a similar manner.
I saw this blogpost from hubspot which has some insights on what you are trying to do. It talks about separating the application 'flows' into cocoapods which can be worked on separately.
http://product.hubspot.com/blog/architecting-a-large-ios-app-with-cocoapods
I would like to create three separate ASP.NET MVC solutions, all pointing to the same Model project. How do I keep changes made from one solution update the others?
Ex, is there is way in Visual Studio to "Add new project from Source Control" like you can with a whole solution?
So you are hoping to have 3 solutions that share a common project.
You can achieve this in 2 ways.
NuGet
Have the project in it's own solution and create a NuGet package of the output, your other solutions can then consume the NuGet Package.
Shared Project
A shared project is easy to do, just ensure that your shared project is available in the same workspace as your solutions.Do a get latest, You can then just right click on the solution and choose add existing project.
Any changes you make will need to be checked back into source control, these changes will then appear in each 'copy' of the project in each of the different solutions.
The shared project works fine, but you may have to make some considerations when you come to building the solutions, the main one being that if you only make a change to the shared project would you want all of the solutions that consume it to be built on check-in?
Scenario. A team has 5 developers and all developers are working independantly on 4 different projects. iOS / OS X. A library has been created which encompasses multiple subclasses, categories and so on for reuse. Each member in this team needs to be able to use this library for each project. The library itself has it's own git repo. When someone makes a change to the library it is handled the same way a standard project is handled and a merge is completed.
Problem I see with this approach...
1. This doesn't seem like common practice for a proper Xcode / Git workflow and I feel a framework or similar would be a better tactic.
2. Although this is great for sharing I can also see this as an issue since one issue with the library will break all existing projects.
3. Adding classes to this library requires each project to be updated to include the new headers.
4. Directory structure can differ on each machine therefore a simple clone of a repo will not work as expected without folder modification.
What is the best way to handle your own library of classes in a Xcode / team environment of multiple users?
If you must have a single library for all this - you can go two ways:
Nobody changes the library, the library is as it is and everyone just pulls it down and then makes changes in their code to make-up for the shortcomings they find in the library.
Everyone changes the library, but the project has A master branch, a stage branch, and a branch for every single project associated with it. Devs change and update their respective project branch, and another person (perhaps one of the project devs maintains the flow from the multipe dev to the single stage to the single master branch). With this approach, it requires much more management but you can slowly improve the main library without potentially breaking other projects as everyone has their own specific know-to-work version of the library in a branch specific to their project, only re-syncing with the master when safe.
The XCode documentation on the concepts of Targets and Projects are helpful, but still I am not certain on the best practices to use in my situation.
I have an existing codebase (used for Windows as well as iOS) in a single SVN repository, which has just been refactored from one single test application into a central library and an application. The idea is more applications will use this central library over time.
An XCode project maps one set of source files to one or more targets, so I could have a single project for my whole codebase and one target for the library and one for each app. However each app will obviously have its own code, so it seems a bit clunky to throw all the source into a single project this way.
Alternatively I could have a workspace with multiple projects, each having a single target. This is much more how I have things set up for the Windows build, where a Visual Studio solution corresponds to the Xcode workspace, and a VC++ project would map neatly against how XCode projects are organised.
But are there 'normal' / expected ways to do things in this kind of situation, some unofficial standards I should try to follow so other developers don't get confused?
Targets nowadays are used to build dependencies and separate builds within a project. You'll see it being used mainly for unit testing. Occasionally, you might have different binaries available to different processors or operating systems, but this is a rarity in today's app store world.
Generally, you'd have one project for each executable. This allows it to be worked on independently and compiled separately without interfering with each other.
You can include projects within projects, which allows you to work on them independently and set up dependencies for them. You can set up a project to build a sub-project and deposit it's executable in a location for your project to link to.
I would say for your situation, make a library project with executable and testing targets. Then include that project in other projects and you can link to or move the files to your other project's location. Here's the gist of how to do it.
I know you don't mention them, but workspaces were basically added to allow you to have multiple projects open in a single window. You can have all your test applications and reference code available without them compiling in the background as well. I find it super handy.
The key difference is that each target is in exactly one project, but one project can be a part of many workspaces. This lets you have projects Lib, AppA, and AppB, and then WorkspaceA = [AppA, Lib] and WorkspaceB = [AppB, Lib], so that developers working on AppA don't have to load stuff related to AppB. As a general recommendation it's a good idea to create projects for things that you might want to share independently.
When I share code between one or more projects (be it Xcode or another IDE), I typically compile the shared parts into a binary and then link it to the code specific projects.
In your setup, something like an Xcode project just to compile a dylib from shared C++ files, and then a main Xcode project that links with this dylib.
I am developing an iOS app. Right now it is one app and two targets (app and tests).
Getting closer to publishing I want to split this app into three apps with lots of shared code and shared tests. (Think of free version and full version for App Store and prototyping app that will not be published).
Would you set up multiple projects in Xcode (1 library project and 3 app projects) or keep all in one project and only set up multiple targets?
I think you have at least 3 options here:
Separate projects. It is more difficult to share code across projects, but with Xcode workspaces this is quite feasible. If you have a lot of customization for each project, this might make sense.
Same project, more targets. This is the usual way this is done. It is very easy because you have a very neat overview of what files go into which target. If you have around, say, a dozen or so targets, it is really quite easy to handle.
Separate git branches. I have worked with this in the past. The differences between the apps (Info.plist, configuration files, data files) are just swapped in the corresponding git branch. This is practical if you have a lot of data and don't need to have all of it available at all times. However, the complexity of git is considerable if you are not familiar with it. You can create git submodules to change the shared code parts in one go.
I would suggest you a hybrid approach depends on your needs
If you need several applications - create Target, that is exactly what they are for. You can handle sharing files using Target Membership[About]
If you have source code which can be separated into module - create additional Project (for shared source) inside Workspace. This technic is used by CocoaPods
[Xcode Workspace vs Project]
[Xcode components]