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

«‹›5 »

dizzywhip: Dec 23, 2005

That makes sense. Thanks for the info

# ¿ Mar 15, 2012 00:33

Adbot: ADBOT LOVES YOU

# ¿ May 16, 2024 10:18

dizzywhip: Dec 23, 2005

I prefer the first for conciseness. It doesn't really matter though.

# ¿ Mar 15, 2012 19:55

dizzywhip: Dec 23, 2005

Toady posted:

Indeed, if you aren't already, adapting your code to use underscore-prefixed ivars now is a good idea for many reasons.

Why is that? I have an irrational, burning hatred for prefixing variable names with underscores.

# ¿ Mar 15, 2012 23:00

dizzywhip: Dec 23, 2005

Is mixing up the ivar and the property really a problem? I've never had that issue once myself.

# ¿ Mar 15, 2012 23:54

dizzywhip: Dec 23, 2005

I guess the reason I don't run into issues is that I almost always design my classes with the mindset that the properties are only for external use. But obviously that doesn't work for every situation so I can see the two getting mixed up in some cases.

pokeyman posted:

I do it for parameters or function-local variables. For example, if I need to implement my own setter,
code:
- (void)setWindow:(NSWindow *)window
{
    _window = window;
    blah blah
}
I've seen people refer to the ivar as this.window, or use a name like 'newWindow' for the parameter, but those always bugged me.

The other reason was to avoid the compiler warning about shadowing ivars, though I imagine you can turn that off now.

Yeah, if there wasn't a compiler warning about shadowing ivars with local variables I would mess that up all the time. In your setWindow: example I would personally go with calling the parameter 'newWindow' or 'theWindow'. I agree that it's kind of annoying, but underscores annoy me more, and making the parameter name ugly rather than the ivar name means the ugliness is confined to that one area rather than throughout the entire class. It's definitely a personal preference thing though.

# ¿ Mar 16, 2012 00:37

dizzywhip: Dec 23, 2005

That is gonna be so awesome.

# ¿ Mar 20, 2012 23:13

dizzywhip: Dec 23, 2005

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

dizzywhip: Dec 23, 2005

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:

.DS_Store
build/
*.pbxuser
*.perspective
*.perspectivev3
*.xcuserstate
*.xcbkptlist
*.xcsettings
*.xcworkspace
xcuserdata

That leaves just the project.pbxproj file, which is what you really want to keep.

# ¿ Apr 1, 2012 20:55

dizzywhip: Dec 23, 2005

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

dizzywhip: Dec 23, 2005

It looks like that Learning Core Audio book has finally been released. I've read a good amount of the in-progress version and it seems very good. I wish it had been out when I had first started learning Core Audio, but I think there's still a lot I can learn from it.

# ¿ Apr 14, 2012 21:33

dizzywhip: Dec 23, 2005

You might need to manually size the column in interface builder so that it takes up the width of the entire table.

# ¿ Apr 19, 2012 00:01

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

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

dizzywhip: Dec 23, 2005

Is there a way to customize the appearance of an NSPopover? The popover's view doesn't reach all the way to the edges:

I'm trying to achieve an effect similar to the popovers in the GitHub app, with content extending all the way to the edges:

I suspect the answer is going to involve implementing an entire custom popover class from scratch, but maybe there's a way to just override the drawing of the standard popover.

# ¿ May 27, 2012 19:06

dizzywhip: Dec 23, 2005

Well I can't use just a view because I need it to function like a popover and be overlaid on top of other views. I would need to somehow override the drawing of the popover itself or draw outside of the bounds of the popover's view (NSBezierPath's setClip didn't work).

# ¿ May 28, 2012 18:50

dizzywhip: Dec 23, 2005

I'm not thrilled about the idea of implementing a popover from scratch, and GitHub's appear's to be tightly coupled with the rest of the Chameleon UI stuff, so that one's not super useful unfortunately. I might use MAAttachedWindow, but first I'm going to try and modify the design of my popover to work with the bordered area. Thanks for the links.

# ¿ May 29, 2012 07:04

dizzywhip: Dec 23, 2005

I gave up and decided to just deal with the border

I just drew a 1px rounded border around the content area and treated the inside as if it were the edge of the popover. It doesn't look that good but I'd rather not deal with the hassle of using a completely custom popover right now.

If I had more time to spend on this, I'd take something like MAAttachedWindow and customize it to look how I need it. It'd be really annoying to emulate a bunch of standard behavior just for this one small customization though.

# ¿ May 30, 2012 23:05

dizzywhip: Dec 23, 2005

xgalaxy posted:

I'm still fairly new at the whole thing but couldn't you manipulate the quartz layer size/position or will the popover container clip that?

I haven't really ever worked at that low of a level, so perhaps, but the popover seems pretty strict about clipping. I tried using setClip and a layer-backed view (I believe core animation layers are usually allowed to draw outside of their containing view) and neither worked.

# ¿ May 31, 2012 01:16

dizzywhip: Dec 23, 2005

Sinestro posted:

Can I record audio to a file in ObjC? I don't know C++, so CoreAudio is a mystery to me.

You don't need to know C++ to use Core Audio, it's a C-based API. You should use something higher level if possible though, which I'm certain you can for such a simple operation. I'm not familiar with AVFoundation but that sounds like it'll work.

# ¿ Jun 4, 2012 21:56

dizzywhip: Dec 23, 2005

Rockybar posted:

I'm beginning to learn Objective-C (I already know some C) and I have a question about the syntax of the @implementation section.

Let's say you have this code: (taken from Programming in Objective-C by S. Kochan)
code:
@implementation Fraction
{
int numerator;
}
-(void) setNumerator: (int) n
{
numerator = n;
}
While I understand the function that is being defined here (to get a function such as [frac setNumerator: 2]), I fail to see why it is necessary to have "(int) n", and then to have to declare "numerator = n". Why not simply have "setNumerator: (int) numerator;"? Is it to do with being able to use the instance variable "numerator" throughout the implementation without its value being modified?

Thank you for your understanding when reading what I assume is a very stupid question.

Parameters and local variables shadow instance variables. If the parameter was named numerator, the instance variable would become inaccessible, so you wouldn't be able to set its value. The compiler would give you a warning.

A common convention in Objective-C is to prefix instance variables with an underscore, so it would look something like this instead.

code:

@implementation Fraction {
    int _numerator;
}

- (void) setNumerator: (int)numerator {
    _numerator = numerator;
}

@end

In practice, you wouldn't manually write out simple getters and setters like this. You would use a @property declaration, which I assume will be covered as you get further into your book.

# ¿ Jun 9, 2012 17:39

dizzywhip: Dec 23, 2005

That's true. I'm pretty sure you'll still receive a compiler warning though, unless you turn it off.

# ¿ Jun 9, 2012 18:30

dizzywhip: Dec 23, 2005

Is there a place to get information about deprecated Cocoa API in Mountain Lion? I've been using the function GetMacOSStatusErrorString to log Core Audio error messages, but it appears to be deprecated in Mountain Lion, so I'm looking for an alternative. The header file simply says it's deprecated without telling you what to use instead. I found a document in the dev center saying it's deprecated, but again it doesn't provide an alternative. Any ideas?

# ¿ Jul 26, 2012 07:07

dizzywhip: Dec 23, 2005

Yeah, each core audio function returns a numeric error code, so whenever there's an error I want to log a useful message so I know what's going on. Unfortunately it seems like NSError only gives me generic "The operation couldn't be completed" messages, while GetMacOSStatusErrorString would usually give me a more descriptive message. I'll use it for now to get rid of the warnings though, thanks!

# ¿ Jul 26, 2012 19:05

dizzywhip: Dec 23, 2005

Hmm, I actually had missed that part of the message. It doesn't seem like NSError lets you access that part directly, but since these aren't user-facing error messages they don't need to be formatted nicely. As long as I can see the message I'm happy.

# ¿ Jul 26, 2012 21:29

dizzywhip: Dec 23, 2005

Nope, when I log userInfo it's just an empty dictionary. Which I think makes sense because I'm passing nil for userInfo in the initializer.

# ¿ Jul 26, 2012 22:17

dizzywhip: Dec 23, 2005

There may be a compiler flag or something that I'm sure someone else will know, but if you manually implement both the getter and setter for a property, the ivar will not be automatically generated. You can also manually declare the ivar if you want.

It's a great feature though, and I'm having a hard time imagining a scenario where you have a property you don't want an ivar for but you also don't want to implement the getter and setter yourself.

# ¿ Aug 8, 2012 07:30

dizzywhip: Dec 23, 2005

Yodzilla posted:

We built a kiosk app for a conference and our answer to locking people into the experience was to build sort of a box that the iPad sat in which covered the home button. The client thought it was genius.

Hopefully he doesn't find out that you can still get back to the home screen with a five-finger pinch gesture. Or switch to different apps with four finger swipes.

# ¿ Aug 14, 2012 02:44

dizzywhip: Dec 23, 2005

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

dizzywhip: Dec 23, 2005

I don't see why it can't look up .name = any less than it can look up setName:.

# ¿ Aug 26, 2012 01:04

dizzywhip: Dec 23, 2005

rjmccall posted:

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.

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

dizzywhip: Dec 23, 2005

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

dizzywhip: Dec 23, 2005

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

dizzywhip: Dec 23, 2005

Carthag posted:

Anyone doing a similar thing with a good tip? I guess I could put it in a category but ugh...

I don't think there's a significantly simpler way to do this. This is the best I can come up with, which is only slightly better. I don't really think it's that bad though.

Objective-C code:

NSArray* someArray = ...;

NSUInteger index = [someArray indexOfObjectPassingTest: ^(BOOL)(id object, NSUInteger index, BOOL* stop) {
    return [object hasSuffix: @"Special"];
}];

id object                     = someArray[index];
NSMutableArray* filteredArray = [someArray mutableCopy];
[filteredArray removeObjectAtIndex: index];

# ¿ Sep 14, 2012 18:56

dizzywhip: Dec 23, 2005

Has anyone else been experiencing performance problems in Xcode since updating to 4.5? After about 2 or 3 hours I have to restart it because it becomes unusable.

# ¿ Sep 23, 2012 01:44

dizzywhip: Dec 23, 2005

Froist posted:

Since when have we been able to access argument-less getter-style functions with the dot syntax? I've just noticed this seems to work with Xcode 4.5 and it works on my iOS 6.0 and 4.3 Simulators, but I'm pretty sure I couldn't do this a few weeks ago in Xcode 4.4.

Is it right to assume this is a completely compile-time feature (as opposed to ARC which IIRC has some caveats on earlier iOS versions) and I can use it everywhere to clean up my code?

As far as I remember I've always been able to do this, and I started during Xcode 3. You may have previously been trying to use dot notation on an id-typed object, which doesn't work. In general I like to use dot notation for anything phrased as a noun and bracket notation for verbs.

# ¿ Oct 9, 2012 08:27

dizzywhip: Dec 23, 2005

lord funk posted:

I like to program UI elements in code rather than IB/Storyboard, but I have to figure out how to do auto layout in code. I'm going to do some resizing of UI elements soon, and I know it's going to be a pain.

I've been doing a lot of autolayout code recently and it is the pits. If you're just setting up one-time constraints the same way you would in interface builder it's not so bad, but it's really difficult to set up a view with dynamic subviews using autolayout. Trying to coordinate how you implement updateConstraints and layout and drawRect or updateLayer and when you need to call setNeedsUpdateConstraints vs setNeedsLayout vs setNeedsDisplay and how you add and remove subviews in a way that the constraint system is happy is a nightmare.

There's also very little good documentation on how to do it all properly. The only information I've found on it is in the most recent WWDC videos, which are helpful, but they cover a lot of information in a short amount of time so they don't go into a great amount of detail a lot of the time.

So yeah, unfortunately writing autolayout code is going to be a pain.

# ¿ Oct 31, 2012 02:46

dizzywhip: Dec 23, 2005

Does anyone know if there's a way to change the color of part of an NSWindow's title without drawing a completely custom title bar? Basically like how a document-based application will have it's title's "- Edited" suffix drawn in a lighter gray.

# ¿ Nov 5, 2012 06:53

dizzywhip: Dec 23, 2005

This is a bit of a longshot, but does anyone have experience with using Core Audio with app sandboxing? I've just enabled sandboxing, and now my Core Audio code doesn't work. In particular, when I call AUGraphAddNode, it returns the error invalidComponentID, saying just "The operation couldn't be completed". A number of other Core Audio calls seem to work correctly before that, though.

It doesn't seem to be a direct sandbox violation, as there aren't any messages from sandboxd in Console, but it definitely works when I turn off sandboxing. Anyone know why this would possibly happen? The only thing I can imagine is that maybe it's trying to read files that I don't have access to, although I would think that would give me a sandboxing error.

Update:

I've narrowed down the issue a little bit. AUGraphAddNode only fails if I try to add a node with the component type kAudioUnitType_MusicDevice and subtype kAudioUnitSubType_DLSSynth, so it seems to be an issue with that particular component in sandboxing mode.

Update 2:

I've figured out a hacky workaround. If I add a temporary exception entitlement to enable read-write access to the user's entire home directory, the error no longer happens. This is obviously not ideal, so I'm continuing to search for better options. I tried to narrow down the access required by adding entitlements for more specific subdirectories, but that didn't work.

dizzywhip fucked around with this message at 01:54 on Nov 11, 2012

# ¿ Nov 10, 2012 02:50

dizzywhip: Dec 23, 2005

Ender.uNF posted:

Is the component in the user's AU folder in ~/Library/Application Support/AudioComponent or whatever (I forget the exact folder name)? Or does that component rely on access to media files somewhere else?

I wonder what Apple's recommendation is for this... Should the CoreAudio part of your app be in a service process that has more permissive entitlements?

I'm not really sure where it is to be honest. The only locations I know of where audio components are stored only have components that I've added myself, so I'm not sure where the native ones are. It does seem likely that that component is loading files that could be outside of the sandbox since it's a sampler, which could explain why this is the only component that causes this problem.

What's strange is that it seems to be doing something with the home folder itself. I get the error if I ask for permission for any of its subdirectories, including hidden ones.

It seems like a bug to me -- there's nothing about playing MIDI sequences that should require access to any files except the audio samples, and that should be a readable resource without any extra entitlements. I'm filing a bug report, hopefully it'll get fixed.

# ¿ Nov 12, 2012 00:23

Adbot: ADBOT LOVES YOU

# ¿ May 16, 2024 10:18

dizzywhip: Dec 23, 2005

DreadCthulhu posted:

Hey guys, what's the most kosher way of storing hundreds of rather tiny (5-30kB) pictures and audio files that might need to be displayed to the user at some point. Think of a language learning tool where you play a sound / display an image in addition to showing the text.

My gut feel is, for simplicity sake, to just store everything in the bundle and fetch it directly from disk on demand, although that likely adds a 2-5ms delay for both the audio file and the picture itself, which may or may not result is a nasty user experience. Has anybody tried this approach before and found the results to be good?

The other option is to dump the images/audio files into CoreData during the first app boot (downside is now you have the same data persisted twice on the device) but now you can use the trick where you warm the CoreData cache in a background thread and thus make the data available at memory-speeds. The downside is having to keep CD in sync with the bundle as the app evolves and the additional complexity of cache preparation.

Thoughts?

Can't you just preload x number of images/sounds before you need to use them?

# ¿ Nov 16, 2012 20:02

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

«‹›5 »