|
mc.schroeder posted:Note that this will no longer be true in the future. From http://clang.llvm.org/docs/ObjectiveCLiterals.html: There aren't definite plans to change that AFAIK; it's just a general warning against relying on things that aren't guaranteed. tarepanda posted:I'm coming from a C/C++/Python background and Objective C's syntax (punctuation? Not sure what I want to say here -- all of the symbols and the way it uses it) are really screwing me up. XCode's autosuggest/correct is also constantly interfering and writing crap I don't need/want and is screwing my code up when I try to type things and XCode makes it something else that I don't want. If you're not used to it, autocomplete can be a little disorienting, and Xcode's suggestions aren't always that great (although they should be better if you're using Xcode 4.4). That said, it shouldn't actually be inserting anything into your buffer unless you confirm its suggestion; if you're finding that autocomplete is actively interfering with your typing, please do file a bug against Xcode. ultramiraculous posted:Wait, is that an actual thing or are you just anticipating what will probably end up coming? I don't remember @==, etc coming up in the "Modern Objective-C" sessions. It's unlikely that we'll ever add new binary operator tokens to Objective-C.
|
#
?
Aug 24, 2012 19:10
|
|
|
|
| # ? Jun 5, 2024 21:33 |
|
|
cereal eater posted:If I'd like to get into developing apps, is the base Mac Mini a good choice if that is all I am using it for? Just curious since there is no room for upgrading the model itself. RAM, SSD, and CPU are the big performance keys, in that order. Apple's RAM prices aren't insanity anymore but I still usually grab some memory from Crucial or Newegg. Also, a lot of their machines can actually take more than the Apple official maximum. My 2009 MBP (non-unibody) is my Mac dev machine. It officially only supports 4GB but I have 6GB in it no problem. My old man is a developer as well and I helped him upgrade his Unibody MBP to 16GB even though it officially only supports 8GB. I believe Everymac can tell you what the real maximum is. Upgrading to SSD is also the single biggest performance boost I've ever had, with the possible exclusion of moving from my Tandy 8088 640k to a 486 SX (with x87 math coprocessor) 2MB. It is way better than any modern upgrade I've ever done, no question. Xcode launches and opens workspaces lightning quick. Just for kicks I've kicked off my Windows VM boot, opened Storm Sim in Xcode, clicked on Photoshop, then clicked on Mail. The Mail window was up, open, and usable immediately, as if nothing else were going on with the machine. Yesterday I was copying my VM image to my backup drive (40GB) and went ahead and installed MS Office 2011 at the same time. The copy didn't slow down and Office installed in about 5-10 minutes. You can pickup the Crucial M4 512GB from Amazon for $399. Do it. Now. Seriously. I will never use another dev machine without 100% SSD in my life. If you offered me a job with a $20,000/yr pay raise but no SSD I would turn it down. It just isn't worth wasting any more of my life or sanity on waiting for a spinning platter. CPU speed... meh. There are occasionally times where my Core 2 Duo dual-core feels a bit slow (calculating hashes across the entire repository or when rebuilding all) but that's such a small slice of my overall computing time that it hasn't been worth upgrading yet. I will get a new Mac whenever the new mini gets released, but I'll order it with minimum RAM and the cheapest disk, drop a Crucial M4 in there, and buy the max RAM from Newegg. Connect a HDD for automatic TimeMachine backups (in addition to the TimeCapsule) so if the SSD shits itself I'm good. That should keep me set for another 3-4 years. quote:Whoever was lusting after C#'s class and property attributes (Ender.uNF?), check out extobjc. Interesting... I'll have to mess with it in a test project and see how it operates.
|
|
#
?
Aug 24, 2012 19:28
|
|
|
Plorkyeran posted:But typing a paragraph for every method call would be awful, so really you just need to get used to it. Xcode's autocomplete annoys me frequently, but the language would be pretty much unusable without it. I've had autocomplete-as-you-type turned off for as long as I can remember. Typing out makeMeCoffeAndAddTwoSugarsToCup:(NSCup *)cup doesn't bother me. Maybe I'm just a fast typist. The long method names help my code be self-documenting, and I have a much easier time going back to something I wrote a month ago than I ever did with C/C++ code. I do hit Escape and let Xcode autocomplete a method if there are a lot of parameters, or if I'm unsure of the exact method name, though.
|
|
#
?
Aug 24, 2012 20:44
|
|
|
Hmmm... anyone else see app rankings changing? My app hasn't been outside the top 50 in its category in the US at any point for the past six months, maybe longer. It usually bounces between 20-40. Yesterday it dropped to 84 and sales took a massive dive too. I thought maybe they were tweaking searches but "thunderstorm", "rainstorm", and "rain" all bring up Storm Sim on the first page of results so I'm officially 
|
|
#
?
Aug 24, 2012 22:11
|
|
|
Doc Block posted:Typing out makeMeCoffeAndAddTwoSugarsToCup:(NSCup *)cup doesn't bother me. Maybe I'm just a fast typist. 
|
|
#
?
Aug 24, 2012 22:23
|
|
|
The real value of autocomplete for me is that, with the semi-English functions, I can hardly ever remember the precise "phrasing" of a function. But I do know, for example, if I start typing "-(void) tableVi," I'll have the reminder to jog my memory in no time flat. Adding huge batches of @synthesize declarations can benefit from autocomplete as well, even if it's not a huge deal.
|
|
#
?
Aug 25, 2012 04:22
|
|
|
I've got a really dumb question to ask and I just want to confirm the equally dumb answer. I'm going through BNR's iOS Programming 3rd Edition right now and am making the map application in Chapter 5. We end up using [userLocation coordinate] to get the 2D location of the user instead of [userLocation location], but I'm not really clear on why. I tried to NSLog [userLocation coordinate] to see what it contained by couldn't. [userLocation location] returns a properly formatted string. Is [userLocation location] simply an accessor that gets us that properly formatted string rather than usable data? How would we ever use that?
|
|
#
?
Aug 25, 2012 04:25
|
|
|
[userLocation location] is probably returning a CLLocation object. [userLocation coordinate] is probably returning a CLLocationCoordinate2D. It's important to note that code:code:So while it's not returning a properly formatted string per se, trying to NSLog() the CLLocation that [userLocation location] returns is going to print out the string. See the CLLocation docs, specifically the part about the -description method, where it explains the exact string format that is returned. Doc Block fucked around with this message at 05:27 on Aug 25, 2012 |
|
#
?
Aug 25, 2012 04:51
|
|
|
Ahh, that clears up a lot for me. I'm also a bit confused about bracket notation here -- for example, with dot notation, you could do something like userLocation.location.coordinate, correct? What would the corresponding bracket notation be if we couldn't just access [userLocation coordinate] directly?
|
|
#
?
Aug 25, 2012 04:58
|
|
|
Doing userLocation.location.coordinate is the same as doing [[userLocation location] coordinate]. Here's how it works: - First it has to get the location to get the location's coordinate, right? (userLocation has a "location" property, which in turn has a "coordinate" property) - Since we need to get userLocation's location, we call the location property's getter method (which, in Objective-C, has the same name as the property, so we call it like [userLocation location]), which returns a CLLocation object. - Then we need to get the CLLocation object's coordinate, so we call the coordinate getter method. So, basically, CLLocationCoordinate2D coord = userLocation.location.coordinate; is the same as CLLocationCoordinate2D coord = [[userLocation location] coordinate] which breaks down to CLLocation *tempLocation = [userLocation location]; CLLocationCoordinate2D coord = [tempLocation coordinate]; Remember that dot-notiation is just syntactic sugar for calling the property's getter/setter methods, and that the compiler will turn them into the exact same code as if you just called the property's getter or setter directly. edit: hopefully more clear now Doc Block fucked around with this message at 05:29 on Aug 25, 2012 |
|
#
?
Aug 25, 2012 05:22
|
|
|
Thanks a lot, man. You're really helping to clear a lot of this up for me. I'm really feeling like I should have gone through BNR's Objective C Programming before trying to get through iOS Programming.
|
|
#
?
Aug 25, 2012 05:24
|
|
|
Speaking of getters and setters, is there any real reason that you can't use dot notation on objects with an id type? I usually find myself wanting to use it on objects in an array or dictionary, especially with the new subscripting notation. I'd really like to do array[i].name = @"whatever" instead of [array[i] setName: @"whatever"]. Also, I'm not sure when it changed but I noticed a while back that you're now allowed to use dot notation on classes, so you can do things like MyClass.someStaticProperty, which is pretty nice. XCode doesn't give you autocomplete suggestions on classes though.
|
|
#
?
Aug 25, 2012 06:03
|
|
|
Without type information it can't look up which selector to use to access the property. At least, I'm guessing that's the reasoning. Although I'd be fine with just assuming the defaults. Also, I just noticed -Wimplicit-atomic-properties. Can we just change the default already? :-(
|
|
#
?
Aug 26, 2012 00:43
|
|
|
I don't see why it can't look up .name = any less than it can look up setName:.
|
|
#
?
Aug 26, 2012 01:04
|
|
|
pokeyman posted:Without type information it can't look up which selector to use to access the property. At least, I'm guessing that's the reasoning. That's at least part of it. Properties do not have to use the default getter/setter selectors. But I think it's mostly to encourage proper use of types. pokeyman posted:Also, I just noticed -Wimplicit-atomic-properties. Can we just change the default already? :-( We can never change the default, at least without making it an error for a while as an intermediate step.
|
|
#
?
Aug 26, 2012 03:19
|
|
|
rjmccall posted:We can never change the default, at least without making it an error for a while as an intermediate step. Like a badly designed building or poorly laid out roads, some choices in software get to live on forever and ever. 
|
|
#
?
Aug 26, 2012 03:44
|
|
|
rjmccall posted:That's at least part of it. Properties do not have to use the default getter/setter selectors. How is using a property on an untyped object less proper than sending a message to it? I also don't see how the compiler can't figure out property selectors. To my knowledge, when you send a message to an untyped object, all the compiler does is check if something, somewhere declares a method with that signature. Why couldn't you do exactly the same thing with properties? It doesn't matter if you use nonstandard getter/setter names. If you're using a getter for name, all the compiler needs to do is look for a method called name, regardless of where it came from. Similarly if you're using a setter, it just needs to look for a method called setName:.
|
|
#
?
Aug 26, 2012 05:39
|
|
|
Gordon Cole posted:How is using a property on an untyped object less proper than sending a message to it? I also don't see how the compiler can't figure out property selectors. To my knowledge, when you send a message to an untyped object, all the compiler does is check if something, somewhere declares a method with that signature. Why couldn't you do exactly the same thing with properties? Properties are a lot more likely to collide, so the general rule of "pick the first method you ever saw declared with that name" is actually a pretty poor idea. Also, I'm not sure being able to send arbitrary messages to id is actually a good idea so much as it's a convenient workaround for some glaring inadequacies in the type system. Of course, you're right that those inadequacies still bite you when you're using properties, so... Gordon Cole posted:It doesn't matter if you use nonstandard getter/setter names. If you're using a getter for name, all the compiler needs to do is look for a method called name, regardless of where it came from. Similarly if you're using a setter, it just needs to look for a method called setName:. I'm not sure you understood what I meant by nonstandard getter/setter names. You can make a property called "foo" and tell the compiler to use the selector "bar" for the getter (@property (getter=bar) int foo;); this is intended primarily to allow non-canonical methods like 'getFoo' to be grandfathered in to the syntax, but in principle it's general. This actually introduces a possibly unlikely but still fascinating potential ambiguity with array[i].foo: does it mean "use the selectors for the first property named foo", or does it mean "assume that the property isn't using custom selectors and just look for methods named foo"?
|
|
#
?
Aug 26, 2012 06:26
|
|
|
rjmccall posted:Properties are a lot more likely to collide, so the general rule of "pick the first method you ever saw declared with that name" is actually a pretty poor idea. Also, I'm not sure being able to send arbitrary messages to id is actually a good idea so much as it's a convenient workaround for some glaring inadequacies in the type system. Of course, you're right that those inadequacies still bite you when you're using properties, so... Even if property names are more likely to collide, you aren't avoiding collisions by using [object setName: name] instead of object.name = name. In regards to sending arbitrary messages to id being a bad idea, out of curiosity, how do you think it could be done better? I don't see how you could restrict which messages are allowed to be sent to id without forcing the programmer to give the object some kind of type, which would make the id type not terribly useful. rjmccall posted:I'm not sure you understood what I meant by nonstandard getter/setter names. You can make a property called "foo" and tell the compiler to use the selector "bar" for the getter (@property (getter=bar) int foo;); this is intended primarily to allow non-canonical methods like 'getFoo' to be grandfathered in to the syntax, but in principle it's general. This actually introduces a possibly unlikely but still fascinating potential ambiguity with array[i].foo: does it mean "use the selectors for the first property named foo", or does it mean "assume that the property isn't using custom selectors and just look for methods named foo"? I did understand your meaning originally, although I just realized I was mistaken about how custom property names work after playing around with them a little bit. I had thought that, in terms of the compiler knowing which methods exist, that the declaration of @property (getter=bar) int foo was no different than saying - (int) bar. But the property declaration actually allows you to use both object.foo and object.bar, which makes sense in retrospect. The ambiguity is definitely a problem, but I think it would be okay to just give an error whenever ambiguity is encountered. If you use object.foo and the compiler finds both a property named foo with a getter named bar and a method declaration named foo, you should be forced to use [object bar] or [object foo] depending on which one you meant.
|
|
#
?
Aug 26, 2012 07:29
|
|
|
Gordon Cole posted:In regards to sending arbitrary messages to id being a bad idea, out of curiosity, how do you think it could be done better? I don't see how you could restrict which messages are allowed to be sent to id without forcing the programmer to give the object some kind of type, which would make the id type not terribly useful.
|
|
#
?
Aug 26, 2012 14:43
|
|
|
Gordon Cole posted:Even if property names are more likely to collide, you aren't avoiding collisions by using [object setName: name] instead of object.name = name. I don't think the id type is terribly useful. My goal in language design is not primarily to justify earlier poor designs.  I agree with Plorkyeran: some better handling of class types (including the "related result type" work in 4.2, where alloc and init propagate static type information) and some ability to give a type parameter to a container would eliminate the vast majority of use cases of id, to the point that I think it would be reasonable to just require a cast for everything else. We're not going to actually do that, of course. But I can understand the desire from the @property designers to not adapt every new language behavior to work with 'id'.Gordon Cole posted:The ambiguity is definitely a problem, but I think it would be okay to just give an error whenever ambiguity is encountered. I agree that it's a solvable problem, and that's probably how we'd have to do it.
|
|
#
?
Aug 26, 2012 20:41
|
|
|
Yes, we've actually discussed the need for something like generics which would eliminate a lot of the need for everything to return id, unfortunately protocols stole the most ideal syntax because you'd want to declare NSArray<FunkyTown>, where FunkyTown is a class... Though now that I think about the namespaceing issue maybe it doesn't matter... If the type is a protocol then use protocol semantics, if it is a class use generic semantics... I'm sure there are huge flaws with that idea though. If you can get the trifecta of generics, automatic type inference, and introspection you have the most powerful tools you need to do crazy functional-style coding in a very natural way. I really want to be able to do var x = @"blah" or auto x = @"blah". The compiler knows what I meant, just figure it out. I think this becomes far more important when you want to start passing blocks around and treating functions as data. The existing syntax is painful, plus the lack of introspection around blocks sucks (NSBlock is a private API). On an unrelated note, Storm Sim jumped from #84 to #17 last night (closer to its historical spot). Why? 
|
|
#
?
Aug 26, 2012 20:44
|
|
|
Ender.uNF posted:...unfortunately protocols stole the most ideal syntax because you'd want to declare NSArray<FunkyTown>, where FunkyTown is a class... 
|
|
#
?
Aug 26, 2012 21:24
|
|
|
Ender.uNF posted:Yes, we've actually discussed the need for something like generics which would eliminate a lot of the need for everything to return id, unfortunately protocols stole the most ideal syntax because you'd want to declare NSArray<FunkyTown>, where FunkyTown is a class... Though now that I think about the namespaceing issue maybe it doesn't matter... If the type is a protocol then use protocol semantics, if it is a class use generic semantics... I'm sure there are huge flaws with that idea though.
|
|
#
?
Aug 26, 2012 23:41
|
|
|
Clang only parses something as a protocol-qualified type if the base is known to be an ObjC type, which in effect means that you can never make a template that adds protocol qualifiers to a dependent type.
|
|
#
?
Aug 27, 2012 02:41
|
|
|
Does it bug anyone else that setting a UITableView to setScrollEnabled:NO makes the cell selection cancellation really sensitive? I've ended up leaving table views always scroll enabled because it becomes literally unusable.
|
|
#
?
Aug 27, 2012 15:44
|
|
|
Is Interface Builder terribly documented, or do I just suck at finding it? Sometimes I can't match a checkbox to the class documentation.
|
|
#
?
Aug 28, 2012 05:00
|
|
|
There used to be tooltips on the interface builder controls that were really helpful, but they went away in XCode 4 I think  A lot of the options can be really confusing if you don't know what they mean beforehand. I haven't found a good resource for interface builder documentation, though I haven't looked that hard so it might exist somewhere.
|
|
#
?
Aug 28, 2012 06:18
|
|
|
If you're testing an app on an actual device, is there a way to see NSLog output? Edit: The bronze challenge in Chapter 8 of the iOS Programming book from BNR requires the use of the proximity sensor... is this just 100% undoable without a real iPhone? If so, it seems like a dumb challenge. tarepanda fucked around with this message at 08:29 on Aug 28, 2012 |
|
#
?
Aug 28, 2012 07:13
|
|
|
tarepanda posted:If you're testing an app on an actual device, is there a way to see NSLog output? If you have a device plugged in, i.e. an iPhone/iPad, you can log data as it occurs to the console using NSLog while the app is running on the device. For what it's worth, you also probably shouldn't even bother doing iOS development on anything remotely near a serious level without a device as, somewhat obviously, they're nothing like the simulator. I'd venture to say that BNR's writers are expecting you to have an iPhone capable of running whatever iOS version the book is using (they have a new edition out every 6-8 months, it seems like, so stuff can become out of date somewhat often), but it's kind of understandable as to why.
|
|
#
?
Aug 28, 2012 13:38
|
|
|
Gordon Cole posted:There used to be tooltips on the interface builder controls that were really helpful, but they went away in XCode 4 I think Thanks for telling me I wasn't imagining the past. I'm often hovering over a checkbox waiting for a tooltip which never comes.
|
|
#
?
Aug 28, 2012 15:43
|
|
|
gucci void main posted:For what it's worth, you also probably shouldn't even bother doing iOS development on anything remotely near a serious level without a device as, somewhat obviously, they're nothing like the simulator. I'd venture to say that BNR's writers are expecting you to have an iPhone capable of running whatever iOS version the book is using (they have a new edition out every 6-8 months, it seems like, so stuff can become out of date somewhat often), but it's kind of understandable as to why. Yeah... no iPhone here, just a couple of iPads. I never thought that would be an issue since we're not really targeting iPhones.
|
|
#
?
Aug 29, 2012 00:46
|
|
|
If your apps are going to be iPad-only then obviously it's OK if you don't test on iPhones. But if you are going to write apps that run on the iPhone then you'll need an actual iPhone to test on. Remember that the simulator is not an emulator; it simulates the iOS environment, not the underlying hardware. edit: to answer your first question, if your device is plugged in then launching your app from Xcode will show you all your NSLog output in Xcode's console window. Doc Block fucked around with this message at 01:32 on Aug 29, 2012 |
|
#
?
Aug 29, 2012 01:26
|
|
|
How would you guys recommend I go about copying a section of an image and create another image from that section?
|
|
#
?
Aug 29, 2012 06:43
|
|
|
Is there a way to process the camera stream without taking a picture? For example, to open the camera and look for a QR code, then display the data once the code is found, all without the user taking a picture of the code?
|
|
#
?
Aug 29, 2012 07:03
|
|
|
There is, but I have no idea how they are doing it. I assume using it in video mode, grabbing a frame, running the algorithm in the background (while throwing away the intervening frames), then if the data you are looking for isn't found grab the next frame, repeat until the algorithm finds what it wants. (You can set it up to vend the frames to you instead of saving a movie.) Copying an image - you can create a new CGImageRef of the desired size/bit depth/etc then just ask it to draw a CGRect of the source image into the target image (you can ask a UIImage for it's CGImageRef) - the rect just needs to have the correct X/Y and width/height for the piece you want to clip out. Take a look at some Core Graphics tutorials; it's C-based but the API is fairly easy to use. edit: Pro tip #95823 - watch out for scale on Core Graphics. It isn't aware of it at all so if you draw from a retina UIImage into the "same"-sized CGImageRef you will shrink it by half.... if you then save/upload that image by turning into a UIImage or by loading the bytes, you can end up stretching the shrunken image back to @2x. The results look about as awful as you might imagine. Pro tip #658923 - You can render any view by getting its CALayer object, then just ask it to renderInContext and it will draw itself into the Core Graphics context. You can also get snapshots of OpenGL views this way (IIRC) by using the EAGLLayer. This can be really helpful for a debug build to make it auto-take screenshots, etc. Simulated fucked around with this message at 07:19 on Aug 29, 2012 |
|
#
?
Aug 29, 2012 07:15
|
|
|
Ender.uNF posted:There is, but I have no idea how they are doing it. I assume using it in video mode, grabbing a frame, running the algorithm in the background (while throwing away the intervening frames), then if the data you are looking for isn't found grab the next frame, repeat until the algorithm finds what it wants. (You can set it up to vend the frames to you instead of saving a movie.) Huh, I didn't realize you could just set it to send you the frames instead of saving the movie... that sounds exactly like what I'm looking for. Edit: https://github.com/benlodotcom/MyAVControllerDemo looks like a pretty good example... tarepanda fucked around with this message at 07:44 on Aug 29, 2012 |
|
#
?
Aug 29, 2012 07:27
|
|
|
Read up on AVFoundation, it's what you'd use to access the camera directly (among other things).
|
|
#
?
Aug 29, 2012 14:12
|
|
|
zergstain posted:How would you guys recommend I go about copying a section of an image and create another image from that section? CGImageCreateWithImageInRect, -[UIImage CGImage], and +[UIImage imageWithCGImage:]
|
|
#
?
Aug 29, 2012 18:24
|
|
|
|
| # ? Jun 5, 2024 21:33 |
|
|
tarepanda posted:Is there a way to process the camera stream without taking a picture? If reading QR codes are your actual use case, we are using ZBar with great success to do QR code scanning in one of our apps at events; the scanner view is just a little subview in the main view controller. http://zbar.sourceforge.net/iphone/sdkdoc/index.html
|
|
#
?
Aug 29, 2012 19:36
|
|
