Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »

Toady: Jan 12, 2009

Boxed expressions have been added to the literals documentation: http://clang.llvm.org/docs/ObjectiveCLiterals.html#objc_boxed_expressions

# ? Apr 19, 2012 18:59

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 20:40

some kinda jackal: Feb 25, 2003; �
�

After tolling around in Xcode for the better part of a week trying to bootstrap myself into Cocoa and Objective-C, the one thing I *really* wish Apple had was some sort of app that I could open on my iPad, then if I option-click something in Xcode I had the option to bring up the reference documentation in that app instead of making me flip between the organizer window and Xcode itself.

I mean because I usually keep Xcode fullscreen :tipshat:

# ? Apr 19, 2012 19:40

haveblue: Aug 15, 2005; Toilet Rascal

I'm with you, I hate that Apple decided to actively kill off running Xcode in multiple window mode. My whole workflow depended on being able to glance at background windows. Short of buying a second monitor, I haven't been able to find a way around this.

# ? Apr 19, 2012 19:50

Doc Block: Apr 15, 2003; Fun Shoe

Open the docs in Safari, either on your Mac or your iPad.

# ? Apr 19, 2012 20:02

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Ender.uNF posted:

rjmccall can confirm but I believe it just automatically makes the ivar with an underscore. You just don't have to think about it anymore.

Right. If your class @interface declares a property foo that you don't explicitly define in the @implementation (whether by @synthesize, @dynamic, or just defining its methods yourself), the compiler will implicitly synthesize the property against an ivar named _foo. The default for explicit @synthesize won't change, of course.

As a necessary prerequisite, the compiler now also does the C++ trick of scanning the @implementation for all its method declarations before parsing any of the method bodies, so you also no longer need to forward-declare methods that you just use in your @implementation, in case that ever affected anyone.

# ? Apr 19, 2012 21:29

haveblue: Aug 15, 2005; Toilet Rascal

Doc Block posted:

Open the docs in Safari, either on your Mac or your iPad.

Doing it on the Mac doesn't solve the problem of the full-screen Xcode window obscuring it. 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.

# ? Apr 19, 2012 21:33

lord funk: Feb 16, 2004

Don't worry - Apple doesn't want you to use multiple monitors. That's why they made fullscreen mode not support it! :negative:

# ? Apr 19, 2012 22:13

Toady: Jan 12, 2009

rjmccall posted:

As a necessary prerequisite, the compiler now also does the C++ trick of scanning the @implementation for all its method declarations before parsing any of the method bodies, so you also no longer need to forward-declare methods that you just use in your @implementation, in case that ever affected anyone.

I was pretty happy about removing dozens of notification callback and IBAction declarations from various class extensions.

# ? Apr 19, 2012 22:45

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

rjmccall posted:

As a necessary prerequisite, the compiler now also does the C++ trick of scanning the @implementation for all its method declarations before parsing any of the method bodies, so you also no longer need to forward-declare methods that you just use in your @implementation, in case that ever affected anyone.

That is a motherfucking delight.

# ? Apr 19, 2012 23:19

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Whatever version of clang in Xcode 4.3.1 already doesn't require the forward-declaration within @implementation. Start using it today!

# ? Apr 19, 2012 23:27

Zhentar: Sep 28, 2003; Brilliant Master Genius

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

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

So if you were about to start on a Cocos2D based game in the next month, would you use version 2, or still stick with 1.0.1?

# ? Apr 20, 2012 05:06

dizzywhip: Dec 23, 2005

I have a small UI design dilemma and I want to get some opinions before making a decision. Here are two options for section headers in my Mac app's sidebar:

vs.

The icons would obviously be different for each button in the final app. I like the first one, but the second is obviously more standard, as it matches the look of Finder, iTunes, etc. Most of the rest of the app's UI is pretty standard OS X fare, so I'm concerned that the first option will look out of place.

Here's the sidebar in the current version of the app for context:

What do you guys think?

# ? Apr 20, 2012 06:24

some kinda jackal: Feb 25, 2003; �
�

If you made the background a little lighter I think the second would work much better. If you're going to keep it that dark then the first would be easier to read.

My choice would be #2 but only with the background colour that you're using now, in that last screenshot.

And now something completely different:

I know we all love reducing the amount of code we write, but did anyone besides me have this weird feeling of "okay that was a little TOO easy" when they first bound something like an NSArrayController to a tableview and pretty much just wired everything up in the xib?

Don't get me wrong, I love that there's less code to work with, but something about it just seems TOO easy. Like I'm somehow doing it wrong, even though everything is working. It's a completely psychological barrier.

I wonder if all people who come to ObjC/Cocoa from other languages go through this phase of worrying that they're not doing it right because they didn't have to write as much code as they expected.

some kinda jackal fucked around with this message at 06:33 on Apr 20, 2012

# ? Apr 20, 2012 06:28

duck monster: Dec 15, 2004

Gordon Cole posted:

I have a small UI design dilemma and I want to get some opinions before making a decision. Here are two options for section headers in my Mac app's sidebar:

vs.

The icons would obviously be different for each button in the final app. I like the first one, but the second is obviously more standard, as it matches the look of Finder, iTunes, etc. Most of the rest of the app's UI is pretty standard OS X fare, so I'm concerned that the first option will look out of place.

Here's the sidebar in the current version of the app for context:

What do you guys think?

What it looks like is that your making a loving awesome app and I will volenteer to betatest the gently caress out of it when your finished!

# ? Apr 20, 2012 06:46

Doc Block: Apr 15, 2003; Fun Shoe

Lumpy posted:

So if you were about to start on a Cocos2D based game in the next month, would you use version 2, or still stick with 1.0.1?

Not 1.0.1. Use either 1.1 or 2.0.

The big thing in 2.0 is the use of OpenGL ES 2.0, but there are some other niceties, like a superior animation plist format (and a built-in animation plist loader) that supports things like sending notifications on certain frames.

1.1 is mostly code-compatible with 1.0.1, and still uses OpenGL ES 1.1, but is faster than 1.0.1 and supports the animation format from 2.0.

Both 1.1 and 2.0 fix the touch wonkiness you'd get in 1.0.1 when using the DisplayLink director (the DisplayLink director is the only option in Cocos2D 2.0).

For a new game, I'd probably go with 2.0 (which is at release candidate status right now).

# ? Apr 20, 2012 07:22

Toady: Jan 12, 2009

Gordon Cole posted:

I have a small UI design dilemma and I want to get some opinions before making a decision. Here are two options for section headers in my Mac app's sidebar:

...

What do you guys think?

Caffeinated draws a subtle divider for its group rows if you want another option to explore:

# ? Apr 20, 2012 07:36

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Martytoof posted:

I know we all love reducing the amount of code we write, but did anyone besides me have this weird feeling of "okay that was a little TOO easy" when they first bound something like an NSArrayController to a tableview and pretty much just wired everything up in the xib?

I feel that way when it randomly throws exceptions that in no way lead me anywhere near the source of the bug (which was, admittedly, in my code).

I'd rather write the code than use NSArrayController. Especially now that I'm used to it from iOS.

But maybe it's gotten better in the intervening years.

# ? Apr 20, 2012 16:34

haveblue: Aug 15, 2005; Toilet Rascal

The first time I tried to use bindings exploded in all kinds of bizarre ways and most of the errors claimed to stem from deep inside the AppKit implementations of seemingly unrelated classes. I'm sure it's gotten better since then but it was scary at first.

# ? Apr 20, 2012 16:46

Toady: Jan 12, 2009

The only reason I'm not using NSController/UI bindings in my current project is that they don't support table animations, but otherwise, I'm very comfortable with them and try to use them as often as I can.

# ? Apr 20, 2012 17:02

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Yeah my disparaging comments about NSController should in no way dissuade anyone from using it. When it works it's awesome. So use it unless it stops working.

# ? Apr 20, 2012 17:10

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

Reading Cocoa Design Patterns helped a lot on my understanding of what goes on below the surface when you're using bindings & controllers. I highly recommend it.

Amazon posted:

�Next time some kid shows up at my door asking for a code review, this is the book that I am going to throw at him.�

�Aaron Hillegass, founder of Big Nerd Ranch, Inc., and author of Cocoa Programming for Mac OS X

Unlocking the Secrets of Cocoa and Its Object-Oriented Frameworks

Mac and iPhone developers are often overwhelmed by the breadth and sophistication of the Cocoa frameworks. Although Cocoa is indeed huge, once you understand the object-oriented patterns it uses, you�ll find it remarkably elegant, consistent, and simple.

Cocoa Design Patterns begins with the mother of all patterns: the Model-View-Controller (MVC) pattern, which is central to all Mac and iPhone development. Encouraged, and in some cases enforced by Apple�s tools, it�s important to have a firm grasp of MVC right from the start.

The book�s midsection is a catalog of the essential design patterns you�ll encounter in Cocoa, including

* Fundamental patterns, such as enumerators, accessors, and two-stage creation
* Patterns that empower, such as singleton, delegates, and the responder chain
* Patterns that hide complexity, including bundles, class clusters, proxies and forwarding, and controllers

And that�s not all of them! Cocoa Design Patterns painstakingly isolates 28 design patterns, accompanied with real-world examples and sample code you can apply to your applications today. The book wraps up with coverage of Core Data models, AppKit views, and a chapter on Bindings and Controllers.

Cocoa Design Patterns clearly defines the problems each pattern solves with a foundation in Objective-C and the Cocoa frameworks and can be used by any Mac or iPhone developer.

Debugging bindings is a pain in the rear end though.

# ? Apr 20, 2012 17:16

dizzywhip: Dec 23, 2005

Martytoof posted:

If you made the background a little lighter I think the second would work much better. If you're going to keep it that dark then the first would be easier to read.

My choice would be #2 but only with the background colour that you're using now, in that last screenshot.

Toady posted:

Caffeinated draws a subtle divider for its group rows if you want another option to explore:

Thanks for the feedback! I do like that subtle divider a lot, I think I'll give that a shot and see how it looks.

duck monster posted:

What it looks like is that your making a loving awesome app and I will volenteer to betatest the gently caress out of it when your finished!

Haha, thanks! I'll be needing to do a lot of testing in a couple weeks, so around then I'll probably see if any of you guys are interested in trying it out and giving feedback.

# ? Apr 20, 2012 21:59

some kinda jackal: Feb 25, 2003; �
�

Thanks for the link to Cocoa Design Patterns, I'll pick that one up when I'm through with the Big Nerd Ranch book

# ? Apr 20, 2012 22:30

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Why are the iTunesConnect reports so delayed on seemingly random days? I still haven't got my report for the 21st, and it's almost 8PM on the east coast. Is it this way for all developers on the same day, or does Apple just poo poo itself sometimes? What could they possibly be doing that takes so long?

# ? Apr 23, 2012 00:38

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Processing millions of transactions I guess.

# ? Apr 23, 2012 03:47

duck monster: Dec 15, 2004

Gordon Cole posted:

Thanks for the feedback! I do like that subtle divider a lot, I think I'll give that a shot and see how it looks.

Haha, thanks! I'll be needing to do a lot of testing in a couple weeks, so around then I'll probably see if any of you guys are interested in trying it out and giving feedback.

Hell yeah, I'm a mad musician and enough of a coder to give you meaningful reports when it shits itself. Leave your debug symbols in!

# ? Apr 23, 2012 13:27

some kinda jackal: Feb 25, 2003; �
�

Hi guys, so another (probably) asinine question from an Objective-C newb:

If I'm going to do something like:

@interface MyClass : NSObject {
NSString *someString;
}
@property (copy) NSString *someString;

and then I @synthesize someString in my implementation, do I really need to explicitly declare the instance variable in my interface? My understanding is that @synthesize will declare it for me.

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 understand that not everything needs to be a property, of course, and those I would explicitly declare in the interface.

edit: That is to say, I don't want to start my obj-c "career" off to a bad start by taking unnecessary shortcuts, but the double-declaration seems very redundant so unless it's absolutely necessary I'd really rather just learn to do it more efficiently from the get-go.

I'm also picking up a copy of their basic Obj-C book so I can thumb through it.

some kinda jackal fucked around with this message at 20:21 on Apr 23, 2012

# ? Apr 23, 2012 18:18

lord funk: Feb 16, 2004

I've stopped explicitly declaring ivars and just used the underscore notation in the @synthesis. So:

code:

@interface MyClass : NSObject {

}
@property (copy) NSString *someString;

then

code:

@implementation MyClass

@synthesize someString = _someString;

I think we talked about this a few pages ago, but I use the @interface ivars (no property) for internal access only variables, and properties for accessible variables from other objects. You could go all out property, though, and do a second @interface declaration in your .m file for that.

# ? Apr 23, 2012 18:29

some kinda jackal: Feb 25, 2003; �
�

Yeah I think we talked about the underscore thing but I wasn't sure if I asked about the backing variable. I'll go read back and hopefully I didn't just ask the same question twice

# ? Apr 23, 2012 18:36

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

You can put private ivars in the @implementation - I find that the headers look a lot cleaner that way.

code:

MyThing.h

@interface MyThing : NSObject

- (void)doStuff:(NSString *)gizmo;

@property NSString *whatever;

@end

/*************************************************/

myThing.m

@implementation MyThing {
  NSString *_blah;
}

- (void)doStuff:(NSString *)gizmo
{
  _blah = [gizmo stringByAppendingString:_whatever];
}

@synthesize whatever = _whatever; //this can be removed if your XCode is new enough (4.4 I think?)

@end

The ivar _blah is only present in the .m file and can be considered "private"... It can still easily be accessed from outside with the -> operator, but it is hidden from view and won't confuse/intrigue people looking at your .h file.

Carthag Tuek fucked around with this message at 18:57 on Apr 23, 2012

# ? Apr 23, 2012 18:54

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Martytoof posted:

Yeah I think we talked about the underscore thing but I wasn't sure if I asked about the backing variable. I'll go read back and hopefully I didn't just ask the same question twice

There's no need to explicitly put the backing instance variable anywhere, @synthesize has you covered.

# ? Apr 23, 2012 19:22

Froist: Jun 6, 2004

Carthag posted:

You can put private ivars in the @implementation - I find that the headers look a lot cleaner that way.

The ivar _blah is only present in the .m file and can be considered "private"... It can still easily be accessed from outside with the -> operator, but it is hidden from view and won't confuse/intrigue people looking at your .h file.

Jumping on the topic here, is there any way of making a truly private variable?

Also, thanks for this tip:

code:

@implementation MyThing {
  NSString *_blah;
}

I always declared them in a separate interface block at the top of my .m file:

code:

@interface MyThing(private)
@property (assign) int foo;
- (void) doSomething;
@end

@implementation MyThing

@synthesize foo = _foo;

...

@end

but as far as I understand 'private' doesn't have any special meaning here, it's just being used as a category as much as 'froist' or 'carthag' could? (Obviously defining them as properties in this block makes them even less private, I'd never thought of defining iVars there - I'm pretty new to ObjC)

# ? Apr 23, 2012 20:35

Doc Block: Apr 15, 2003; Fun Shoe

There's always @private, which seems to work pretty much like private in C++ class declarations.

# ? Apr 23, 2012 20:43

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

Yeah, category names have no meaning, they're purely descriptive.

There are @private/@protected/@public keywords for ivars, but I've never bothered using them so I can't speak to their efficacy. Here's what Apple says The Scope of Instance Variables.

Methods can't be declared private at all. I use class extensions (basically unnamed categories inside the .m file, like your "(private)" category) for "private" methods (and this won't be necessary either soon).

E: I guess I was wrong earlier, you can't use the -> operator from outside an instance or an instance of a subclass, since by default they're @protected. I'm sure I've done it at some point though. Maybe the debugger doesn't care?

Carthag Tuek fucked around with this message at 20:56 on Apr 23, 2012

# ? Apr 23, 2012 20:49

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

@private and so on are compile-time checks. At run-time everything is public, and the language runtime will happily help you reach into any instance you like and pull out an ivar.

See, for example, object_getInstanceVariable and object_setInstanceVariable.

# ? Apr 23, 2012 21:18

Zhentar: Sep 28, 2003; Brilliant Master Genius

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

some kinda jackal: Feb 25, 2003; �
�

Interesting, I didn't realize synthesized ivars won't show up in the watch window. Is that just in auto mode or is there no way to (visually) inspect synthesized variables at all?

edit: Outside of the debugger cli I mean.

# ? Apr 23, 2012 21:34

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

No, you can still access the synthesized ivars. In the next release with auto-synthesize you'll automatically get ivars with underscores for all your properties so you can just stop worrying about it.

I'll also second the motion to skip using ivars, or when using them put them in the implementation file. Since the current compiler doesn't require forward declaration of Objective-C methods there is no need to use the empty category for private methods either. Just stick private properties in the empty category and public properties and methods in the header and be done.

Debugger support for properties is better in LLDB since it understands the dot syntax IIRC. It still can't evaluate dynamic properties like on CoreData objects but it's a bit step up from GDB. (Why do I need to manually cast the return type of a int or CGRect property? Arrrrggggggggg)

# ? Apr 23, 2012 22:26

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 20:40

Zhentar: Sep 28, 2003; Brilliant Master Genius

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

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »