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

«‹›2 »

Zhentar: Sep 28, 2003; Brilliant Master Genius

NotShadowStar posted:

Warning signs:

Also their code example showing how much easier it's supposed to be compares to ridiculously roundabout, obfuscated code.

Edit: What the gently caress? It's real example code from a legitimate tutorial... why does it have poo poo like this in it?

code:

CGContextTranslateCTM( context, 0, height - height );

Zhentar fucked around with this message at 21:20 on Apr 5, 2011

# ¿ Apr 5, 2011 21:10

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 14:47

Zhentar: Sep 28, 2003; Brilliant Master Genius

modig posted:

code:

@synthesize window=_window;

In English, that says "Create the setter & getter for the property 'window', using the variable '_window'". Using the underscore in the private variable name is just a coding style thing.

# ¿ Apr 25, 2011 16:47

Zhentar: Sep 28, 2003; Brilliant Master Genius

Ender.uNF posted:

If you are both checking in changes to the Xcode project bundle, it should prompt you to merge them and thus combine both sets of changes. Most of that stuff is just plist XML so in theory it should merge fine.

Except that if you're both adding stuff at the end of the list, it'll conflict (easy enough to resolve though). And if you're messing with groups you can break things even without conflicts. Combine the terrible usability and miserable performance of XCode4's visual diff with several developers on a large project and you're not going to have a good time.

# ¿ May 5, 2011 23:11

Zhentar: Sep 28, 2003; Brilliant Master Genius

Small White Dragon posted:

XC4 is definitely a big change, but it is a lot better in many ways -- once you figure it out.

The more I use Xcode 4, the more I find about it to dislike. The improved autocompletion is too much to give up to go back to 3.2, but that's about it for me.

Is there any secret hidden option to adjust the scrollwheel speed? It doesn't seem to respect the system preference.

# ¿ May 11, 2011 16:20

Zhentar: Sep 28, 2003; Brilliant Master Genius

rjmccall posted:

you can do the nice covariant-return and contravariant-parameter cases

On a similar note, is there some way to do this without a warning (or suppress the warning)? Or would it be better not to do it at all...

code:

@interface SomeClass {
}
@property (nonatomic,readonly,retain) NSArray* array;
@end

@interface SomeClass ()
@property (nonatomic,readwrite,retain) NSMutableArray* array;
@end

# ¿ May 17, 2011 20:34

Zhentar: Sep 28, 2003; Brilliant Master Genius

Anyone have suggestions for how to track down properties that are retained, but not released in dealloc?

# ¿ Jun 2, 2011 22:07

Zhentar: Sep 28, 2003; Brilliant Master Genius

I do most of my development at work in VB6, which pretty much has ARC without zeroing weak references.

I'd say about 90%-95% of developers don't understand the retain cycle limitation. Some of those reasonably could understand it but haven't learned because we so rarely encounter leaks. The misunderstanding mainly shows up with people trying to break retain cycles within the object's destroy/dealloc method (although it could also be behind the strange VB obsession with setting local variables to Nothing before they fall out of scope).

# ¿ Jun 17, 2011 04:34

Zhentar: Sep 28, 2003; Brilliant Master Genius

Yodzilla posted:

1) any line that contains self.tableView will break because now the tableView is inside of another view. I'm not sure how to access the tableView as self.view.tableView doesn't seem to work. I really don't get this part.

self.tableView just means your class has a @property UITableView* tableView. It doesn't matter if that table view is inside of another view, or is the main view, or isn't loaded anywhere at all. If you want those references to work in a non-UITableViewController, then you have to provide that property yourself.

# ¿ Jun 25, 2011 21:12

Zhentar: Sep 28, 2003; Brilliant Master Genius

Ender.uNF posted:

and how heavily Apple pushes you to use UITableViewController?

They do? I must have missed that. The UITableViewController is only like two dozen lines of code worth worth of minor convenience functions to make implementing a simple tableview easy. You really should just stop trying to force it into doing what you want and use a UIViewController regardless of what Apple is pushing.

# ¿ Jul 3, 2011 23:32

Zhentar: Sep 28, 2003; Brilliant Master Genius

Ender.uNF posted:

Have you tried to duplicate it's keyboard scroll functionality when moving between UITextView cells? Perhaps I'm totally missing something here.

I'm not familiar with the specifics of the built in functionality, but I didn't find it particularly difficult to handle for the situations I've encountered.

# ¿ Jul 5, 2011 01:33

Zhentar: Sep 28, 2003; Brilliant Master Genius

Ender.uNF posted:

The idea of one controller per screen is really pre-ipad advice.

Even with a reasonably complex iPhone app, sticking to one controller per screen can be restrictive.

I think the primary motivation behind Apple's one controller per screen advice is that if you want to implement nested view controllers, you're responsible for passing all of the calls like -viewWillAppear: that are typically handled by the framework.

# ¿ Jul 5, 2011 19:32

Zhentar: Sep 28, 2003; Brilliant Master Genius

Spelter posted:

you shouldn't be doing anything like setting Name, ShortDescription and Icon properties to nil

Also you're setting the variables, not the properties, to nil which means you're not actually even releasing them.

# ¿ Aug 4, 2011 20:57

Zhentar: Sep 28, 2003; Brilliant Master Genius

stray posted:

I've seen a number of people (not here) who insist that the only proper way to release something is by setting it to nil before releasing it, like so:
code:
- (void)dealloc {
	[foo release], foo = nil;
	[super dealloc];
}

The risk addressed by doing that is that if the superclass releases an ivar using the property (e.g. self.bar = nil) and your subclass overrides the setter, and sends a message to foo.

I think it's better to just make a rule of never using properties within dealloc. Outside of dealloc, always set the property to nil.

Doc Block posted:

My opinion is that it's a waste of time. While trying to pass messages to nil might be "safe" in that it won't crash your program, it almost certainly will result in incorrect behavior.

I would say that sending messages to nil gets me the desired behavior somewhere around 95% of the time, and most of the remainder gets explicit nil checks.

# ¿ Aug 8, 2011 05:58

Zhentar: Sep 28, 2003; Brilliant Master Genius

Probably because you haven't told your UITableView to use your controller as a data source.

# ¿ Aug 18, 2011 17:34

Zhentar: Sep 28, 2003; Brilliant Master Genius

Sinestro posted:

Whut? I am letting my controller autocreate the view, the documentation states that dataSource is set to self.

I checked the documentation before posting that.

Have you tried sticking a breakpoint in tableview: numberOfRowsInSection to see what you're returning?

# ¿ Aug 18, 2011 19:05

Zhentar: Sep 28, 2003; Brilliant Master Genius

KDiff3 works well, although visually speaking it's not a well done port.

# ¿ Aug 19, 2011 20:06

Zhentar: Sep 28, 2003; Brilliant Master Genius

You're passing the address of a struct to a function that does not expect to receive a pointer to that struct.

# ¿ Sep 27, 2011 19:52

Zhentar: Sep 28, 2003; Brilliant Master Genius

Last thread I saw From C++ to Objective-C posted a few times. Coming from a similar background, with "decent" familiarity with C++, I found it very useful for understanding Objective, and highlighting important differences between my expectations and what I could/couldn't do.

# ¿ Oct 26, 2011 05:52

Zhentar: Sep 28, 2003; Brilliant Master Genius

lord funk posted:

So it looks like an issue when I get a memory warning - level 2. My views are unloading, objects deallocating, and then they're getting called.

What you have just described has absolutely no relation to what pokeyman described, nor does it appear to have any relation to what's in the crash log.

# ¿ Nov 6, 2011 18:31

Zhentar: Sep 28, 2003; Brilliant Master Genius

I haven't looked too closely at NSMutableArray, but a typical implementation would start with a buffer of 4 entries and re-allocate a new array with double the size each time you exceed the capacity. If your array ends up with 1025 elements, it'll end up using as much space as a 2048 element array, write 2045 elements, and perform allocations for 4092 elements worth of space. That can add up to a pretty huge amount of overhead if you're doing the operation enough times.

That said, it's pretty easy to go back and change later, so you're probably better off not worrying about it right now and then doing something when your profiler tells you there's actually a problem to solve.

# ¿ Nov 17, 2011 21:24

Zhentar: Sep 28, 2003; Brilliant Master Genius

ManicJason posted:

Taking away the alpha made very little difference.

A coworker suggested an issue with the images being too large for the OpenGL buffer, but there's very little way to investigate that using CALayers, as far as I can tell.

Here's what instruments has to say:

http://lmgtfy.com/?q=png_read_filter_row

# ¿ Dec 2, 2011 23:42

Zhentar: Sep 28, 2003; Brilliant Master Genius

Kekekela posted:

I think you don't need * there since its an integer. (which would seem to my novice eye to make sense with the error you're getting)

Bingo (and then you do need to use the & with both parameters). The parameter there is asking for the address of an NSStringEncoding variable that it can modify. You're giving it an uninitialized pointer, so rather than pointing at an NSStringEncoding it can modify, you're just giving it a random memory address. You get the EXC_BAD_ACCESS because that random memory address doesn't happen to point to allocated memory.

# ¿ Dec 22, 2011 17:19

Zhentar: Sep 28, 2003; Brilliant Master Genius

Are there any published ARC performance comparisons? I'm doing some investigation to convince my team to switch our project over to ARC, and it would be helpful if I had some measurements to address any concerns in that area.

Edit: has anyone else found the version of the static analyzer shipped with XCode 4.2 to give really poor results? Telling people "the compiler is smart enough to know when retain and release are needed!" would probably be a lot easier if the analyzer weren't giving us a hundred or so obviously incorrect memory management warnings

Zhentar fucked around with this message at 21:24 on Dec 23, 2011

# ¿ Dec 23, 2011 20:15

Zhentar: Sep 28, 2003; Brilliant Master Genius

I realized that all of the apparent "false" positives were calling [self.ivar release] rather than [ivar release]. They happen to be equivalent in these cases, but they aren't necessarily, so the analyzer is technically right, it's just confusing as to what the problem actually is.

stealth edit: and actually, the analyzer is at least a little clever about the naming conventions. I thoughtlessly added a couple properties that start with copy, and I just get a compiler warning about not respecting naming conventions, without any analyzer errors.

Zhentar fucked around with this message at 03:56 on Dec 24, 2011

# ¿ Dec 24, 2011 03:04

Zhentar: Sep 28, 2003; Brilliant Master Genius

Hot optimization tip: try profiling your code instead of blindly guessing what might be slow.

# ¿ Dec 27, 2011 22:54

Zhentar: Sep 28, 2003; Brilliant Master Genius

To get by without making a custom class, you can just hook the cell's components to outlets in your view controller. Not very re-usable, but it works fine for a one-off custom cell.

# ¿ Dec 30, 2011 18:07

Zhentar: Sep 28, 2003; Brilliant Master Genius

echobucket posted:

How would this work? How would the views in a prototype cell point to outlets in a class? Is it constantly wiring up and rewiring the outlets as it draws each cell? Or were you meaning outlets in his custom CellView class?

By "one-off" I was referring to a cell you will only have one instance of. And I'm not sure how that would work with prototype cells specifically, since I haven't tried them yet.

# ¿ Dec 30, 2011 20:18

Zhentar: Sep 28, 2003; Brilliant Master Genius

Without looking at the documentation or thinking about it too hard... you probably need to make a connection in IB between windowController and the Parent object.

# ¿ Jan 19, 2012 22:06

Zhentar: Sep 28, 2003; Brilliant Master Genius

The "%@" format specifier means 'call [obj description]'. You're using it on a BOOL.

# ¿ Jan 24, 2012 04:50

Zhentar: Sep 28, 2003; Brilliant Master Genius

Is there a way to find the type of an object's property using KVO? Basically, I've got a key and a string, and I need to know whether or not I need to parse that string into an NSNumber before calling -setValue: forKey:.

# ¿ Jan 25, 2012 19:37

Zhentar: Sep 28, 2003; Brilliant Master Genius

Carthag posted:

As in you want to know what types it accepts? Usually that would be in the documentation, but I suppose you could do something like [[object valueForKey:@"key"] class] if you know it's an object and not a primitive or a struct.

Yes, I want to know what type it accepts. And whether or not it's an object or a primitive is what I want to know most, so that method doesn't help me (it also doesn't help if the key you are setting is nil...).

Although, looking at the documentation again, this isn't as big an issue for me as I thought - I thought that setting value types required you to pass an NSValue object, but that's not quite the case; rather, it calls the appropriate -<type>Value method on the object you pass, and NSString implements the -<type>Value methods that I'd need so I won't have to do any conversion in those cases.

# ¿ Jan 25, 2012 21:25

Zhentar: Sep 28, 2003; Brilliant Master Genius

pokeyman posted:

This is almost certainly not what you want to do, but the runtime can tell you whether a property takes a primitive or an object. Take a look at the Objective-C Runtime Programming Guide, in the Declared Properties section. You can get a type string (aka what you get out of @encode) for a property, which you would then have to parse for the information you're looking for.

That is what I was looking for originally, thank you.

# ¿ Jan 26, 2012 02:00

Zhentar: Sep 28, 2003; Brilliant Master Genius

That issue has nothing to do with whether or not you are using ARC.

Edit: Also, adding an observer does not increase the retain count. But if you're observing something, you should probably have a strong reference to it anyway.

Zhentar fucked around with this message at 20:08 on Feb 15, 2012

# ¿ Feb 15, 2012 20:02

Zhentar: Sep 28, 2003; Brilliant Master Genius

duck monster posted:

This is really loving me off, because I cant defeat this stupid overengineered piece of poo poo class.

If you don't love NSDate yet, just wait till you want to get tomorrow's date and find yourself starting off with

code:

NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];

# ¿ Feb 23, 2012 01:09

Zhentar: Sep 28, 2003; Brilliant Master Genius

Ender.uNF posted:

Time is incredibly complicated and software engineers often get it wrong. I've seen people using tricks to get the current GMT offset in JavaScript then apply that to a user selecting a date for an appointment six months from now, when the user will be in DST, resulting in the wrong value being stored... Unless you are trying to store the expiration date of some food in which case you want absolute time as the sun rises, regardless of DST.

And yet the ridiculous complexity of NSDate and friends don't even solve that. NSDate goes a lot farther than most to try to encompass all the complexity of things, but the end result is that it's harder to handle simple, common cases and all the opportunities to screw things up are still there.

# ¿ Feb 23, 2012 16:09

Zhentar: Sep 28, 2003; Brilliant Master Genius

I'll throw text rendering in there too. gently caress text rendering.

# ¿ Feb 23, 2012 17:21

Zhentar: Sep 28, 2003; Brilliant Master Genius

An NSIndexPath just tells you "the user selected row 13 in section 2".

code:

 [self.sections valueForKey:
  [
   [
    [self.sections allKeys] 
   sortedArrayUsingSelector:@selector(localizedCaseInsensitiveCompare:)] 
  objectAtIndex:indexPath.section]
 ]

Is just saying "get me the list of what's in section 2" (in a complicated way because NSDictionary isn't ordered, and it's a stupid way of organizing your data for a tableview)

and then

code:

[
objectAtIndex:indexPath.row];

Is just "get me what's in row 13 of that section".

# ¿ Feb 27, 2012 21:18

Zhentar: Sep 28, 2003; Brilliant Master Genius

kedo posted:

PS. Also let me know if there's somewhere else that'd be good to post this. I'm not super familiar with this subforum

There is a job thread that you might want to post it in: http://forums.somethingawful.com/showthread.php?threadid=3246449

# ¿ Mar 13, 2012 20:51

Zhentar: Sep 28, 2003; Brilliant Master Genius

It might help if you included how you present the UIImagePicker.

# ¿ Mar 13, 2012 22:41

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 14:47

Zhentar: Sep 28, 2003; Brilliant Master Genius

GC performs cycle collection and ARC doesn't, so there's plenty of opportunity to introduce huge memory leaks with an ARC conversion.

# ¿ Mar 14, 2012 22:34

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

«‹›2 »