This might sound like duplicate question. In all the place I searched, they said merge conflict will occur when more than one person uses storyboard. But no one explained why, how, and when it will exactly occur.
My question is: What is a merge conflict?
Second question is: Why and when it will occur, and why it doesn't occur when we use programmatically?
Each person is going to work on different ViewControllers, so how this conflict occur.
Imagine that there is a little piece of text in the file. Let say, that there is a text "labeltext" and one developer changes it to "label" while you are changing it to "text". The source control system cannot know, which change is the "valid" one. It reports a merge conflict, so you and the other developer can decide, which version to take.
This can happen in code, too. But as a developer you are good in reading source code and likely bad in reading XIBs containing the storyboard. When you know, on which part of the software your colleague works, in many cases it is easy to decide, which version to use. If it is done in a XIB it is often impossible to you to know, even what the change is. You find yourself in the situation the version control system is: "Gmpf, what is the right version?"
Beside this, typically a storyboard is app global. You cannot say to your colleague: "Do not touch this file, I'll work on it today."
Related
I'm attempting to learn Xcode currently, and instead of reading a lengthy tutorial, I much prefer to learn by doing. Therefore, I'm looking at some of the sample code from the Apple Developer website and learning the ins and outs of the code. I'm currently learning about Core Data (https://developer.apple.com/library/ios/samplecode/iPhoneCoreDataRecipes/Introduction/Intro.html) but I ran into a problem. There's a button that links me to "Categories" in which I can select a category to put a recipe in. The categories are connected to an SQLite database best I can tell. However, I'm trying to delete this button, and I can't find out where the button is in any of the code. If anyone knows an easy way to locate and delete a button through the simulator, I would really appreciate it, or if anyone would have the time to look over the code and see where the button is (It's right below Prep Time and directly above Ingredients) and see how to delete it, I would be very appreciative. Any help is greatly appreciated. Thanks.
From Apple's introduction to Core Data:
Important: Core Data is not an entry-level technology. Before starting
to use Core Data, you must understand the basics of iOS application
development, including:
How to use Xcode and Interface Builder
Fundamental design patterns such as model-view-controller and delegation
How to use view controllers, navigation controllers, and table views
The sample code you linked to has some very helpful info for learning Core Data, but you should really learn the ropes of Xcode, etc. first. Additionally, the project doesn't use Storyboards and appears to be targeting iOS 3.2. You may want to check out some sample code that targets a more current version of iOS and integrates Storyboards if you're just getting started. If you're dead set on starting with Core Data, start by picking apart the Master Detail Application template--it's much easier to consume (pun intended).
If you must know, the "Category" button is actually a UITableViewCell. It resides in RecipeDetailViewController.m and triggers a push transition to the TypeSelectionViewController when tableView:didSelectRowAtIndexPath: is called.
If you want to get rid of the cell and the title for the section, comment out lines 249 and 228 - 230.
Line 249:
// case TYPE_SECTION:
Lines 228 - 230:
// case TYPE_SECTION:
// title = #"Category";
// break;
Stop now, don't pass go. Thank me later.
If you search the project for the word "Category", you can see that it's a section in a tableview inside RecipeDetailViewController:
This app-wide search function (which admittedly only scans code, not NIBs or Storyboards) is very useful.
This tells us that this is not part of the UI defined by the NIBs, but rather a UI generated from code (it's a section in the table view). As you can see from that code, that means that the section whose section number is equal to TYPE_SECTION results in the "Category" behavior. So search the code for all occurrences of TYPE_SECTION, and comment that out of the code. Because these section numbers are integral to the code (and have to start at zero), you have to adjust the constants that say:
#define TYPE_SECTION 0
#define INGREDIENTS_SECTION 1
#define INSTRUCTIONS_SECTION 2
and replace that with something like:
// #define TYPE_SECTION 0
#define INGREDIENTS_SECTION 0
#define INSTRUCTIONS_SECTION 1
This code, rather gracelessly, has hard-coding for the number of sections, too, so you'd probably have to fix that, too, namely, replacing:
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 4;
}
with
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 3;
}
This is, at my quick investigation, what you need to do. There might be other things you'd have to do, too. If this was a UI element defined by a NIB or storyboard, the process of hunting it down is a little different (and sufficiently more cumbersome that I hesitate to go into it here ... the answer to that question is (a) not applicable to your immediate question of how to remove the "Category" section and (b) a detailed answer on searching NIBs would probably be more confusing than helpful; if you really want me to describe it I can, but it's probably not a good use of your time as you're just getting started).
Having said all of this, if you're looking to learn, diagnosing really old code might not be the first avenue I'd suggest.
I would, instead, suggest following some tutorials that walk you through the creation of your own test apps (e.g. Apple's "My First App" described in Jump Right In section of the Start Developing iOS Apps Today guide; or the Second or Third app that they describe in Where to Go From Here? section at the end of that guide.
Actually writing your own code (simplified by following along a tutorial like these) is going to be a heck of a lot more productive than trying to reverse engineer some old code (IMHO).
The interface is probably in a xib file. But if you are learning in this way, you will have to accept you will run into stuff where a more formal approach would probably have helped you.
Sorry for the generalized question...I have been hunting for a long time and haven't found anything I can use or easily adapt yet. I'd really appreciate any pointers!
I'm building a reference app that will contain several textbooks in plain-text format. I want the user to be able to perform a search, and get a table back with a list of results. I have a working prototype, but the search logic that I wrote isn't all that smart and it's been hell trying to make it better.
This is obviously a fairly common problem so I'm looking for a tool that I could adapt to the task. So far I've found Lucene (http://vafer.org/blog/20090107014544/) and Locayta (http://www.locayta.com/iOS-search-engine/locayta-search-mobile/)
Lucene appears to have been last updated for iOS 2...I don't even know if I'll be able to rework it myself. Maybe.
Locayta would probably work great, but a commercial license is $1,000 and I may not soon recoup that with this app, as it's a niche market.
Thanks!
We stumbled upon the same predicament where I work, and have yet to decide on a solution.
Locayta seems promising, but barring that, I've looked into SQLite's FTS3/FTS4 as well.
The only issue seemed the lack of a way to match partial words. It's easy to search for fields that contain whole words (eg. "paper" matches "printer paper", "paper punch", and "sketch paper"), or words that start with something (eg. "bi*" matches "binder", and "bicycle"), but there's no built in way to match a suffix.
If you don't require that functionality, FTS3/FTS4 might work.
I see you mentioned in the follow-up that your SQLite didn't recognize FTS3(), and I had the same issue at first.
Apparently it's not bundled into the iOS version by default, instead you have to download the SQLite3 amalgamation, and include it in the project manually. As found at is FTS available in the iOS build of SQLite?
Also note, the SQLITE_ENABLE_FTS3 variable is not enabled by default, you just have to add it to the configuration as detailed at http://www.sqlite.org/fts3.html#section_2
Hope this helps.
If you can translate plain C code to iOS Objective-C, then Apache Lucy (a loose "C" port of Lucene) might be worth a look.
when trying to email contents from text fields im having exceptions thrown. I think im wiring them up wrong.
Im creating outlets for my text fields in .h, setting up my email button as an action.
In .m im implementing usual code for sending email. Ui message frame kit has been imported.
Now I need some help as thats not working for me.
To summarise: How do i email whats in my text boxes?
Im using xcode 4.3 with storyboards
Thanks
There are no tricks to emailing the contents of text boxes. You need help with some exception, you need to provide us the precise error and show us the relevant code. If you want to try to solve it on your own, you should debug the code, single stepping through the method that attempts to email the contents of your text boxes (see Xcode 4 User Guide: Debugging and Analyzing Your Code; see the section about adding breakpoints and then the section about controlling execution).
Exceptions are generally the result of memory management problems (e.g. your code is trying to use some object that has already been released) so you might want to enable zombies if you haven't already. I also think that people do not sufficiently appreciate the value of Xcode's Analyze command on the Product menu (described in the aforementioned Analyzing Your Code section). This Analyze command will identify not only dangling pointers, but also some memory leaks. It's not perfect, but it's a good start.
People really shouldn't be posting questions here if they haven't first resolved the problems raised by Analyze (unless, of course, you need help fixing issues that Analyze raises). Personally, when I went through this Analyze exercise on my first big project, it was painful to clean up all the issues that it identified, but, more importantly, I suddenly "got it". I've been an IT professional for decades, have programmed in dozens (literally) of programming languages, but only after going through this painful exercise did I finally get the subtleties of Objective C memory management. Suddenly, rereading Apple's Advanced Memory Management Programming Guide, it all made perfect sense.
So, if you're still stymied, and the Analyze command did not identify any issues, and you ran the code through the debugger you were not able to identify why the exception was generated, then just provide us a detailed error message and show us the relevant code and I'm sure we'd be happy to help.
As with my previous "vs" question at BlackBerry: Overriding paint() vs subpaint() I am wondering if this has to do mostly with convention, style, or if there are some real hard n fast rules.
The way I've seen it so far is that MainScreen.setBanner(Field) and MainScreen.setTitle(Field) have almost exactly the same functionality. I have used the case of being able to call setTitle(String) in a simple UI. However I am working across iOS, droid, BB, and try to make the UIs similar - my title/banner is a 'pretty' custom manager.
The only difference I can see is the little style element that is inserted automatically under a title.
Is this the only reason I would have to choose between using each of these methods?
Perhaps there are stylistic or convention reasons to use one over the other? Perhaps RIM has some intentions with these methods that I cannot yet see as a new BB developer? Am I making a mistake by treating these methods as direct substitutes?
If you use both, the banner is laid out above the title. My understanding is that if you are using only one, then they are pretty much interchangeable -- the reason to have both is that you can get some stacking behavior if you want to add more information to the top of the screen.
There is an article: "MainScreen explained" that goes into detail on this and other features of MainScreen.
I don't know if my approach to this is fundamentally wrong, but I'm struggling to get my head around a (seemingly trivial?!) localisation issue.
I want to display the title of a 'System' UITabBarItem (More, Favorites, Featured, etc...) in a navigation bar. But where do I get the string from? The strings file of the MainWindow.nib doesn't contain the string (I didn't expect it to) and reading the title of the TabBarItem returns nil, which is what stumped me.
I've been told, there's no way to achieve it and I'll just have to add my own localised string for the terms in question. But I simply don't (want to) believe that!! That's maybe easy enough in some languages, but looking up, say, "More" in already presents me with more than one possible word in some languages. I'm not happy about simply sending these words for translation either, because it still depends on the translator knowing exactly which term Apple uses. So am I missing something simple here? What do other people do?
Obviously, setting the system language on my test device and simply looking to see what titles the Tab Items have is another 'obvious' possibility. But I really have a problem with half baked workarounds like that. That'll work for most languages, but I'm really gonna have fun when it comes to Russian or Japanese.
I'm convinced there must be a more reliable way to do this. Surely there must be a .strings file somewhere in the SDK that has these strings defined?
Thanks in advance...
Rich
The simple and unfortunate answer is that aside from a very few standard elements (e.g. a Back button), you need to localize all strings yourself. Yes, UIKit has its own Localization.strings file but obviously that's outside of your app sandbox so you don't have access to it.
I filed a bug with Apple years ago about providing OS-level localization for common button titles, tab item labels, etc. That bug is still open but obviously they haven't done it yet (sorry, I don't have the radar # handy).