|
Yeah, even with Git, merging branches can be a real pain in the rear end. On a different subject, I found something neat: AppleDoc. It's like Doxygen, except the documentation it outputs looks like Apple's own documentation, it supports Markdown, and it can output documentation in the format Xcode uses (and it can even automatically install the docs into Xcode for you).
|
#
?
Mar 31, 2012 17:17
|
|
|
|
| # ? May 15, 2024 16:34 |
|
|
lord funk posted:Sweet jesus. Just had my first real run in with Git problems. The Xcode project wouldn't parse, had to resolve conflicts manually on two different branches... nearly gave me a heart attack when it started to get ugly. I thought this would be a good way to leave the current App Store version of the app available for bug fixes, while still adding new features for the next version. But man... what a shitstorm I just went through. This might give some ideas on how to better manage your branches: http://nvie.com/posts/a-successful-git-branching-model/
|
|
#
?
Mar 31, 2012 17:46
|
|
|
I suspect that his problem has less to do with his branching model than the fact that that the project file format is not conducive to merging. It's not as bad as xibs though, which can be flat out impossible to merge.
|
|
#
?
Mar 31, 2012 23:23
|
|
|
Zhentar posted:I suspect that his problem has less to do with his branching model than the fact that that the project file format is not conducive to merging. It's not as bad as xibs though, which can be flat out impossible to merge. Ah yea. I don't check project files into source control. Instead I define the files in JamPlus and check those in instead. And then have JamPlus generate the project files for me. Much easier to do it this way, especially if you are working cross platform and have to keep 'project files' in-sync between different ide versions, different ides altogether, etc. Scons and Cmake can do this as well.
|
|
#
?
Apr 1, 2012 00:53
|
|
|
xgalaxy posted:This might give some ideas on how to better manage your branches: Thanks for this! Zhentar posted:I suspect that his problem has less to do with his branching model than the fact that that the project file format is not conducive to merging. It's not as bad as xibs though, which can be flat out impossible to merge. Well that explains it. I'll probably just tell Git to ignore it from now on.
|
|
#
?
Apr 1, 2012 02:19
|
|
|
It can help to tell git to treat pbxproj (and xib if you like) as binary files, so it won't try to merge them or diff them. Check out Pro Git chapter 7.
|
|
#
?
Apr 1, 2012 03:22
|
|
|
lord funk posted:Well that explains it. I'll probably just tell Git to ignore it from now on. Your xcodeproj and obviously your xib files contain important information about your project, though. It doesn't make sense to ignore them in the repository, otherwise when you do a fresh clone of your project you won't be able to actually run it.
|
|
#
?
Apr 1, 2012 04:12
|
|
|
The only important project-file in xcode is NAME.xcodeproj/project.pbxproj; the rest is user specific. And if you aren't in the habit of making changes to the build settings, you can just ignore it and let it add any new files when they show up.
|
|
#
?
Apr 1, 2012 07:12
|
|
|
Thanks for the info!
|
|
#
?
Apr 1, 2012 15:54
|
|
|
If you've customized your schemes, you'll want to check those in too. edit: check in your .XIBs too Doc Block fucked around with this message at 20:49 on Apr 1, 2012 |
|
#
?
Apr 1, 2012 20:47
|
|
|
Carthag posted:The only important project-file in xcode is NAME.xcodeproj/project.pbxproj; the rest is user specific. And if you aren't in the habit of making changes to the build settings, you can just ignore it and let it add any new files when they show up. Yeah, you definitely don't want to check in the user-specific files. Here's my .gitignore for reference: code:
|
|
#
?
Apr 1, 2012 20:55
|
|
|
Apple needs to integrate mercurial in. Its basically git for dumb people like me.
|
|
#
?
Apr 1, 2012 22:40
|
|
|
duck monster posted:Apple needs to integrate mercurial in. Its basically git for dumb people like me. I actually tried to find information about Xcode's plugin API to see if I could ape the git plugin and get it working with Mercurial.... the API can't be that complicated. Unfortunately there is literally zero information about it. There's almost no info about Xcode plugins in general, let alone something like a source control provider.
|
|
#
?
Apr 1, 2012 23:14
|
|
|
duck monster posted:Apple needs to integrate mercurial in. Its basically git for dumb people like me. I've been thinking about a side project I've wanted to do for a while, which would be a light wrapper around git that exposes a core set of commonly-used features in a much friendlier manner. Most of the time I need to do anything in git that isn't basic stuff like committing, pushing and pulling, I have to google how to do it. It'd be super easy to make a proxy command that gives you access to those kinds of actions in a way that's actually natural and rememberable. For example, sometimes I get a branch in a weird state and I want to just revert it to the state it's in on the remote repo. It'd be a lot easier to remember how to do that if I could run a command like reset --remote instead of reset --hard origin/master. I think there's a bunch of those kinds of cases that could be greatly simplified. I bet I could knock it out in a couple days...maybe I'll give it a shot next weekend.
|
|
#
?
Apr 1, 2012 23:24
|
|
|
Almost a year ago I setup two provisioning profiles for a simple game I was making. I made a second one because I scrapped the UIKit-based code for an OpenGL setup. Anyway, I finally pulled my iPod Touch out and wanted to work through this Cocos2D book. I want to use it to test programs out, because touch input sucks on the simulator and stuff like the accelerometer doesn't work. Do I have to either A) use the same code+profile for each chapter of the book B) make a new provisioning profile for each chapter? Can't I just use my device to test any random program I write? Do I want to make a wildcard id?
|
|
#
?
Apr 1, 2012 23:45
|
|
|
duck monster posted:Apple needs to integrate mercurial in. Its basically git for dumb people like me. We use Mercurial at work for iOS dev (and everything else now) and it's absolutely lovely.
|
|
#
?
Apr 2, 2012 01:32
|
|
|
Bob Morales posted:Almost a year ago I setup two provisioning profiles for a simple game I was making. I made a second one because I scrapped the UIKit-based code for an OpenGL setup. Just make one provisioning profile for everything. Just follow Apple's own HOWTO on the provisioning portal.
|
|
#
?
Apr 2, 2012 03:35
|
|
|
I've considered converting my Git project to Mercurial because I used Mercurial prior to Xcode 4 and enjoyed it. I admit I'd miss the Xcode integration. However, I've already been firing up SourceTree to avoid issues I've encountered with Xcode's Git functionality for certain operations.
|
|
#
?
Apr 2, 2012 06:30
|
|
|
Zhentar posted:I suspect that his problem has less to do with his branching model than the fact that that the project file format is not conducive to merging. It's actually designed specifically to be conducive to merging in certain ways. For example changing settings on two different files or changing build settings in two separate targets in the same project shouldn't cause any conflicts. However, there's really nothing a file format can do when trying to merge two changes that both append to the same collection, such as when two developers add a file to the same group. Whether you use more a flat-with-IDs format (like Xcode projects) or hierarchical nesting (like storyboards) this will result in a conflict.
|
|
#
?
Apr 2, 2012 07:10
|
|
|
pokeyman posted:It can help to tell git to treat pbxproj (and xib if you like) as binary files, so it won't try to merge them or diff them. Check out Pro Git chapter 7. For xib files this is reasonable, but not really for projects. Project files are about as mergeable as source code.
|
|
#
?
Apr 2, 2012 07:12
|
|
|
eschaton posted:For xib files this is reasonable, but not really for projects. Project files are about as mergeable as source code. In my experience, hand-resolving conflicts on a project file can leave you with a project that just crashes Xcode. If I ever add files to a project that somebody else has already added files to (causing a conflict), I tend to just update/revert and then apply my changes again (which is a pain in the rear end, but usually not a big deal).
|
|
#
?
Apr 2, 2012 07:18
|
|
|
Doc Block posted:Just make one provisioning profile for everything. Just follow Apple's own HOWTO on the provisioning portal. That ended up working, but I spent about two hours mucking around with old certificates and provisioning profiles and keychains. Now I just need to figure out how to run stuff on an iPod 2G - I've changed the settings to armv6 like the google searches say, but it just says 'finished running testapp on Bob's iPod' and never actually runs. Runs fine on my iPad and iPhone 4 Maybe I'll just sell it and buy a new iPod.
|
|
#
?
Apr 2, 2012 13:50
|
|
|
I have a little indie magazine that I created, and I'd like to make it available on iOS. I have no experience with app development, and just a bit of knowledge HTML. Someone in the iPad thread recommended iBooks Author, it seems like a good way to go for me. Before I get too deep into it I thought I'd ask, are there any other alternatives that I may not know about?
|
|
#
?
Apr 2, 2012 18:48
|
|
|
eschaton posted:However, there's really nothing a file format can do when trying to merge two changes that both append to the same collection, such as when two developers add a file to the same group. Whether you use more a flat-with-IDs format (like Xcode projects) or hierarchical nesting (like storyboards) this will result in a conflict. Visual Studio project files are much easier to merge, and more often than not avoid conflicts between two adds (the files are sorted alphabetically, so new files get inserted, not appended). Although I don't have as much experience merging them, so maybe they have pain spots that I haven't encountered. It's been a while since I've had a particularly painful pbxproj merge, so I'm a little fuzzy on the details, but I think there are a few problems with the format. First is that files aren't just listed in one spot; adding a single header file can result in at least three changes to the project file; this alone makes resolving conflicts much worse. I recall groups being the biggest problem; a single group has multiple constant formatting lines interspersed with content that can change; it's very easy to get the diff algorithm to decide to insert unbalanced brackets/parentheses and require manual editing to resolve (and things get particularly bad if groups get renamed or files get rearranged). I also had some problems with things going to hell because the GUID of some files changed, although I haven't seen that in a while so it may have been an xcode 3.2 issue, or someone being a fool. It also doesn't help that XCode's diff viewer shits itself when it tries to load our project file (which weighs in at about ~500kb), or that XCode just crashes with a generic error message if there's anything wrong with the merged project file.
|
|
#
?
Apr 2, 2012 19:10
|
|
|
I'm trying to use Key Value coding to set a string value to a BOOL property. According to the KVC documentation, this should call [string boolValue] and all should be happy. But it is not. Instead, it's calling [string charValue] (which, naturally, is not implemented). The problem itself is fixed easily enough (implement a -charValue category method that just returns [self boolValue]... of course, that will be trouble in the unlikely event I have a char property I want to set). But I haven't been able to find any explanation as to why KVC isn't behaving in the manner specified in the documentation. Does anyone know?
|
|
#
?
Apr 2, 2012 21:27
|
|
|
BOOL is, for stupid historical reasons, a typedef for signed char and gets @encoded as such. Try using bool (for which you'll need to #include <stdbool.h> if this isn't ObjC++).
|
|
#
?
Apr 2, 2012 22:05
|
|
|
I'm not sure I've ever read an explanation for what those "stupid historical reasons" are. Is there one lying around somewhere?
|
|
#
?
Apr 2, 2012 22:56
|
|
|
Well, first off, BOOL predates C99 and was historically char; unsurprisingly, there's code which manages to rely on holding other values in the type. We consider that code buggy, but it takes effort to fix these things, and you can't actually change the type anyway without breaking ABI. It doesn't help that PowerPC made _Bool 32-bits for some terrible reason. I think we've just missed the opportunity to change it on all the new architecture transitions we've done (for i386, x86-64, and ARM). It's signed char because the old Mac compilers used to treat char as signed, but GCC says it's unsigned, and it was easier to switch the typedef than to switch the Mac default to -fsigned-char and then fix all the unsigned-char assumptions in the BSD code. And changing compilers broke ABI for C++ anyway, so nobody cared about the mangling difference.
|
|
#
?
Apr 2, 2012 23:27
|
|
|
rjmccall posted:Well, first off, BOOL predates C99 and was historically char; unsurprisingly, there's code which manages to rely on holding other values in the type. We consider that code buggy, but it takes effort to fix these things, and you can't actually change the type anyway without breaking ABI. It doesn't help that PowerPC made _Bool 32-bits for some terrible reason. I think we've just missed the opportunity to change it on all the new architecture transitions we've done (for i386, x86-64, and ARM). So which version of C is Objective-C a superset of, cause doesn't C99 make bool an honest to god type? And will Objective-C ever change? (probably not) Like what happens if you compile as "-std=c99" EDIT: I guess c99 has been default for awhile n/m xgalaxy fucked around with this message at 03:00 on Apr 3, 2012 |
|
#
?
Apr 3, 2012 02:54
|
|
|
Objective-C is a superset of whatever version of C you ask for. clang uses C99 as the default. gcc and llvm-gcc still used C89. _Bool is just the official name of the C99 bool type (they didn't want to conflict with people's various typedefs and macros, so they used an identifier in the reserved namespace). I already spelled out why Objective-C has not yet moved to making BOOL a typedef for _Bool. We actually cannot change this for existing platforms because it would break binary compatibility in a number of subtle ways.
|
|
#
?
Apr 3, 2012 06:03
|
|
|
xgalaxy posted:You can use MAC address if you don't care about security, or don't care that jail broken devices can change it. Though I wouldn't be too terribly surprised if access to MAC gets restricted too, since it's an obvious fallback solution for ad tracking purposes. Here's some code I've found: - (NSString *)localUuid { NSString *ident = [[NSUserDefaults standardUserDefaults] objectForKey:@"unique identifier stored for app"]; if (!ident) { CFUUIDRef uuidRef = CFUUIDCreate(NULL); CFStringRef uuidStringRef = CFUUIDCreateString(NULL, uuidRef); CFRelease(uuidRef); ident = [NSString stringWithString:(__bridge NSString *)uuidStringRef]; CFRelease(uuidStringRef); [[NSUserDefaults standardUserDefaults] setObject:ident forKey:@"unique identifier stored for app"]; [[NSUserDefaults standardUserDefaults] synchronize]; } return ident; } I've been using this to track unique devices & usage behavior in an app. I've checked and the function does not return the actual UUID. Would that be OK to use or will Apple reject it?
|
|
#
?
Apr 3, 2012 23:12
|
|
|
That's fine. It's exactly what Apple tells you to do.
|
|
#
?
Apr 4, 2012 00:00
|
|
|
Yay! Thanks.
|
|
#
?
Apr 4, 2012 02:03
|
|
|
klem_johansen posted:Yay! Thanks. The only change I would suggest would be to store the CFUUID you generated in a keychain instead of UserDefaults. However this isn't necessary if you don't care that your app will generate a completely new CFUUID if the user uninstalls and then later reinstalls the program. But you also need to remember that storing in the keychain isn't a 100% guarantee that the data will be saved either. They could wipe their phone for instance.
|
|
#
?
Apr 4, 2012 02:21
|
|
|
Sorry wrong thread, ignore this post.
modig fucked around with this message at 02:46 on Apr 4, 2012 |
|
#
?
Apr 4, 2012 02:31
|
|
|
loving XCode is driving me nuts right now. Periodically, all my projects, Not some, All, start declaring "STORYBOARDS CANT BE USED BEFORE IOS 4.3" even though every god drat motherfucking switch in the systme is set to 5.1 aaannd then after a bit they all compile again FOR SOME REASON. gently caress this poo poo apple. I dont have time for this.
|
|
#
?
Apr 4, 2012 13:53
|
|
|
Is it true that NSOutlineView did not retain a data source's item identifiers until 10.7? I can't find anything in the docs that confirms this but my experiments just now seem to show it to be the case.
|
|
#
?
Apr 4, 2012 14:37
|
|
|
duck monster posted:loving XCode is driving me nuts right now. Open up the pbxproj or whatever in an editor. I guarantee there is a stray 4.3 version switch somewhere in there. Either a deploy target or what have you. I've had this happen before.
|
|
#
?
Apr 4, 2012 17:28
|
|
|
Someone posted this on the mailing list: Objective-C namespace proposal
|
|
#
?
Apr 4, 2012 23:59
|
|
|
|
| # ? May 15, 2024 16:34 |
|
|
Anyone have any resources on creating hybrid apps? Not, creating a webapp and running it through phonegap, etc. But something like Flipboard, or Clutch.io. Skin-ability (not just color swaps) by non iOS devs is something I'd like to explore.
|
|
#
?
Apr 5, 2012 00:53
|
|