What is the best way to handle the storyboard with multiple developer while using SVN. I'm facing issue while commit with other developers storyboard.
For a team to work on the same app it's recommended that every developer creates a separate storyboard file for the feature / module he working on that way no conflicts would happen , only drawBack i think is that instead of easily using self.storyboard , you have to create the storyboard object corresponding to the name of the storyboard you created but it can be handled with a simple extension
I would personally prefer taking multiple storyboards in such a situation. Use storyboard references as much as you can. This will not only help your developers to independently work with their storyboards, but it would also separate multiple functionality or to be specific, modules, from each other.
Related
I tried to turn a xib project which is downloaded from iOS Developer Library of Apple, into a pure code one for further use, but it didn't work.
I wonder what should I pay attention to when I do this kind of conversion, and I wonder it will help me improve my skill of iOS developing.
Converting the Xib file into pure code part is not a very big task, you just need to be carefully replace the items created via Interface builder by your code part. You can follow this sequence while converting such projects :-
1) Display the elements made via IB with your code.
2) Make sure the delegates and datasources to be connected via code if they were connected via IB.
3) Check for the IBActions, if any to be replaced.
4) Lastly, if you are not using ARC or the Project that is being converted not using ARC then the dealloc part or viewDidUnload method, where we generally make the objects nil and release.
Hope it helps you :)
There are some tool available. For example, http://kosmaczewski.net/projects/nib2objc/
I have different project set up for iPhone and iPAD and most of the file names in these two projects are same. Now i would like to merge these two into one and create a Universal build. Is there any tutorial or a better way to handle this without reworking on the complete code.
Please help. Thanks.
I already did that before. At that time, we did not have the choice to rename all the files and classes of one project. Objective-c does not have namespace, unfortunately.
Don't know how big is your project, but with rename/replace or re-factoring tool, you would be able to that without any (to much) pain.
If you use StoryBoard, then you can choose your project and when you choose Universal, you can set two different StoryBoards for iPhone and for iPad.
So you will have an application which initialize it according to iOS device.
And if you have same class names, I suggest you to change one of those with one character difference (eg. ViewController and PViewController (P for phone..)) and refactor all related class according to it.
Good luck!
I want to integrate two Xcode projects together and they both are full Xcode projects with UI and all. For example lets say i have an App 'A' which has a UIButton and on click it should open App 'B' which has its own UI.
I know we can open an App from another App through Custom URL schema but is there a way i can do this without custom URL schema and via connecting Xcode projects.
I know this a little vague question but i don't a better way to put this.
Thanks,
You're question doesn't make any sense. You're talking about two very different things. Yes, you may import one Xcode project into another Xcode project and setup a dependency between them. However, this in no way affects how the apps work with each other. If you're wanting to embed one app inside another, you have to do it at the view controller/code level. You cannot simply add one project to another and expect the two to intercommunicate. You'll have to move the functionality of one app to another. Apps are sandboxed on the device and can therefore have no communication with each other except for by using custom URL schemes as you've mentioned.
I have a project whose release date is Q1 2013, should I use xib to get compatibility to iOS4.3 and early version, or should I just use storyboard to ignore iOS4.3 and early version users? I have checked some ios version share data, and just want to know you guys' opinions.
http://www.14oranges.com/2012/07/ios-version-statistics-%E2%80%93-july-14th-2012/
It depends on what you want to do with them I guess. I personally feel like xibs give you more power over a custom interface but that may just be because I'm used to them (I'm sure everything that can be done in xibs can be done in storyboards as well).
Storyboards will probably make the entire development process easier, seeing as though you can throw together a navigation or table view controller in a matter of a couple seconds. More details on perks of storyboards here.
Additionally, if you're worried about backwards compatibility before you start the project you should compile a summary of all the features of iOS that you wish to use. From this you can extrapolate which iOS devices/iOS versions will be able to run your app. Doing this should give you a clear idea of how far back you're able to support and should help make the 4.3+- decision easier.
This is a problem we never had to deal with until storyboards were introduced - Whenever there was a chance of conflict in UI, we just made sure that no 2 developers ever worked on the same XIB file simultaneously. The reason we refrained from resolving XIB conflicts is that there may be problematic side-effects (XIB is represented in XML format so there isn't a "good" way to merge 2 versions).
Now we are facing this issue because all of our UI elements are within the same .storyboard file - prevention of simultaneous work on any 2 UI elements in the project makes working in parallel very difficult.
Any suggestions as to how to tackle this issue? Thanks in advance for your efforts.
Break up your storyboard into multiple storyboards.
There is no reason for your app to contain only one storyboard. Break your storyboard up into module storyboards. You can use +storyboardWithName:bundle: to load storyboard modules.
See: UIStoryboard Best Practices for other good storyboard ideas.
Update
It's important to note this is not a complete solution to the problem. In the same way you cannot completely avoid the possibility of merge conflicts in source code decomposing a giant class into smaller modules, you can't avoid the possibility storyboard merge conflicts either. The idea is to reduce the likelihood until it becomes a manageable problem.
There will alway be tricky merge situations in a large codebase. A properly decomposed solution will reduce the number of conflicts and minimize the number of lock out needed.
Here's something I came up with when I was just messing around, trying to find a solution.
If you right click your storyboard file in Xcode and navigate to "Open As" you'll see that there are multiple options - the default is "Interface Builder - iOS Storyboard". However, you can also select "source code".
If you open storyboard up in source code mode, it's possible to make changes (although kind of a pain). But you can add code from other storyboards and make changes in your own - I haven't used SVN but with a git repository I can view other versions of the storyboard and copy code in.
I wouldn't say that this is a great solution - I've had some trouble with Xcode randomly crashing when I try to reopen the storyboard in IB. Sometimes pasting code in works, sometimes it doesn't. A few times I had to change the <scene> tag's value. In my experience it's pretty hit-or-miss but if you back up your files before you try anything it might work.
If it does work, let me know - I'm interested in seeing whether a solution can be found to this problem.
Is this about merging XML files?
Fortunately, SVN allows you to change the merge tool you use to perform merging for different types of file. (eg tutorial for using P4Merge)
So now you just need to find a great tool for merging XML files (good luck :) )
there's WinMerge (with the DisplayXMLFiles prefilter), or diffxml, or XMLMerger or a java xmlmerge tool
You can also have a look at a modern source code management tool. Git for example has intelligent merge features. See this link for why you should consider upgrading your workflow.