|
I agree with pokeyman; my policy is to never set to an ivar. Gets I don't feel so strongly about, but I've never been in the situation where something would have been easier to change if a property had been an ivar, but the reverse isn't true, so my preference is to use accessors there as well.
|
#
¿
Mar 16, 2012 02:06
|
|
|
|
| # ¿ May 16, 2024 07:15 |
|
|
Container literals? poo poo yes.
|
|
#
¿
Mar 21, 2012 01:28
|
|
|
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
|
|
|
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
|
|
|
But most of the design decisions and architectural requirements have already been worked out. Even though you have to rewrite pretty much everything, it's still significantly faster.
|
|
#
¿
Apr 14, 2012 04:38
|
|
|
haveblue posted:And it seems silly to spend several hundred dollars on hardware (iPad or external monitor) to solve a problem that didn't exist until Apple chose to introduce it. Not having an external monitor was a pre-existing problem. Seriously, how could you live like that?
|
|
#
¿
Apr 20, 2012 01:50
|
|
|
Martytoof posted:Now I'm going through the Big Nerd Ranch book and it's still got me explicitly declaring my ivars. Is this just Good Practice™ so the code is easily understandable, or is there some deeper reason why I'd declare an ivar if I'm going to make it a property anyway? I'd say it's Bad Practice, not good. But there are two reasons they may be included in the book; the first is that they aren't optional with the old 32-bit OS X runtime, and the second is that they will be shown in the debugger watch windows, while implicit ivars are not so you'll have to do some typing in the debugger console to inspect properties. Speaking of the debugger console, in one of the recent XCode versions, for me it got really aggressive with autocomplete. Is there some way to stop this? I can't pause my typing for fear that it will start "helpfully" finishing some wildly incorrect guess at what I wanted.
|
|
#
¿
Apr 23, 2012 21:25
|
|
|
Oh, hey, I didn't realize we could finally use LLDB for iOS now. I'll have to give it a try.
|
|
#
¿
Apr 24, 2012 00:35
|
|
|
I've had that problem in the past, but only with huge files (like 500k+ project files). Between the poor performance, and various issues I've encountered, I've ended up only using XCode's source control to commit changes to my personal branch, and occasionally updating for small changes.
|
|
#
¿
Apr 25, 2012 19:07
|
|
|
@property(nonatomic, is just the keyword to start a property declaration. If I put my retain semantics before nonatomic, then I'd have things that are important mixed in the middle of my keyword.
|
|
#
¿
May 15, 2012 01:26
|
|
|
I'm pretty sure the answer to this is no, but is there anyway under ARC to explicitly autorelease something? Basically, I need a __bridge_retain_autorelease. (Without going into too much detail, I have a legitimate use case for something explicitly unsupported by ARC; an ARC autorelease would just let me keep the impact of the lifetime management to one line). Fake edit: could I just call objc_autorelease myself? Real edit: great, the rewriter strips out all retains from properties, but no one told the warnings the default is strong now. So I've got many hundreds of warnings now. Awesome. Zhentar fucked around with this message at 18:23 on Jun 8, 2012 |
|
#
¿
Jun 8, 2012 17:59
|
|
|
rjmccall posted:You can make a local __autoreleasing variable and assign to it. Ah! It looks like that will work, then. I think I misunderstood how __autoreleasing works when I read the documentation previously. rjmccall posted:Really? File a bug, please. I also strongly encourage you to try the Xcode 4.4 preview if you can. Stack Overflow linked me to a fixed bug report about it, so it is hopefully fixed for 4.4; I'll go ahead and give it a try. I also ran into one other issue, where a number of assign properties in class extensions got the "weakweak" attribute, but the first google hit for that one was an llvm commit fixing the issue.
|
|
#
¿
Jun 8, 2012 23:34
|
|
|
Gordon Cole posted:If the parameter was named numerator, the instance variable would become inaccessible, so you wouldn't be able to set its value. This isn't strictly true - you can still do self->numerator to access the instance variable.
|
|
#
¿
Jun 9, 2012 18:17
|
|
|
ARC is not just compile time. Notably, the zeroing weak references require runtime support.
|
|
#
¿
Jun 19, 2012 23:02
|
|
|
IANAL, but if the code that performs the encryption is not compiled into your binary, then I don't see how you could be exporting encryption.
|
|
#
¿
Nov 30, 2012 23:58
|
|
|
PT6A posted:From what I've heard, it's because the law doesn't differentiate between "contains encryption" and "uses encryption." There is evidently a streamlined process to get approval for a product which does not actually itself contain the code, but based on what I've read I still think it's necessary. The guv'ment would agree with you, apparently. http://www.bis.doc.gov/encryption/flowchart1.pdf
|
|
#
¿
Dec 1, 2012 18:14
|
|
|
DreadCthulhu posted:Still not sure if it's worth the trade-off though, assuming XCode doesn't actually resize them in any meaningful way. Just to be clear, the trade-off here is install footprint vs. runtime performance. As for memory usage, the XCode way likely has lower peak memory consumption and equivalent steady state consumption. Edit: DreadCthulhu posted:Feels like I'm coding for a 1980 GameBoy here. If your minimum supported iOS version is 5.0+, you're running on a device with at least 256MB of RAM, of which you can potentially use as much as 100MB. If you've only got 1.5MB of resources, it's a pretty safe bet that you're worrying over nothing. You can run your app in Instruments and easily see just how much memory you actually are using, if you need reassurance. Zhentar fucked around with this message at 21:44 on Jan 7, 2013 |
|
#
¿
Jan 7, 2013 21:32
|
|
|
ImageOptim is trying to figure out the ideal compression of the image you provide it. Save for web is altering the image you provide to be more compressible. The linked comparison uses ImageAlpha to similar effect.
|
|
#
¿
Jan 9, 2013 17:03
|
|
|
A while back, when I was trying to figure out some random, drawing related crashes, I tried using swizzling to make it throw an exception when doing off-main thread UI work. I got it to work but it wasn't usable - UIKit was, as far as I could tell, intentionally splitting off some UITableView drawing onto a background thread. I'm still not sure that wasn't causing some of the issues I was seeing, either.
|
|
#
¿
Jan 18, 2013 16:22
|
|
|
|
| # ¿ May 16, 2024 07:15 |
|
|
We ship an app has no public sign up at all (paid or otherwise), without any problems.
|
|
#
¿
Sep 26, 2013 14:40
|
|