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 »

lord funk: Feb 16, 2004

This makes me nervous. The icon for my next update is showing the reflective highlight in iTunes connect, but it shouldn't be there. The binary details say prerendered icon = true, so it should be okay...

Please don't be reflective please don't be reflective please don't be reflective...

# ? Aug 29, 2012 19:56

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 00:12

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

My icon never looks right until the update goes live.

# ? Aug 29, 2012 20:49

lord funk: Feb 16, 2004

Ender.uNF posted:

My icon never looks right until the update goes live.

This is the first time it's happened for me, but good to know.

# ? Aug 29, 2012 20:52

tarepanda: Mar 26, 2011; Living the Dream

Lumpy posted:

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

I was looking at that and zxing, but my main problem is getting it to work "live" rather than after you take a picture.

# ? Aug 29, 2012 22:33

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

tarepanda posted:

I was looking at that and zxing, but my main problem is getting it to work "live" rather than after you take a picture.

They have a sample app you can DL which does exactly that. I'd be happy to post code as well for our "always on" view in a view implementation as well.

\/\/ Sure thing. I'll have to do it tomorrow when I'm at work so it will be a bit, but I'll get it up somewhere for you.

Lumpy fucked around with this message at 01:15 on Aug 30, 2012

# ? Aug 29, 2012 22:52

tarepanda: Mar 26, 2011; Living the Dream

Lumpy posted:

They have a sample app you can DL which does exactly that. I'd be happy to post code as well for our "always on" view in a view implementation as well.

Oh, shoot. If you could do that, it would be a big help.

I forget which sample app I ended up downloading to look at, but it was only for taking a picture and scanning. I'm heading into work now and will look again.

# ? Aug 29, 2012 23:15

zergstain: Dec 15, 2005

pokeyman posted:

CGImageCreateWithImageInRect, -[UIImage CGImage], and +[UIImage imageWithCGImage:]

I'm working with OS X here. I found -[NSImage initWithCGImage: size:] and -[NSImage CGImageForProposedRect: context: hints:] and am passing nil for context and hints. Is that the best way?

I'd also like to detect if the region i grabbed was entirely one color (black in this case), and throw it away if so.

Edit: Apparently it isn't the best way. It's scaling the full image to fit in the rect I specify rather than using the rect as a clipping region.

zergstain fucked around with this message at 14:37 on Aug 30, 2012

# ? Aug 30, 2012 03:28

Doc Block: Apr 15, 2003; Fun Shoe

lord funk posted:

This makes me nervous. The icon for my next update is showing the reflective highlight in iTunes connect, but it shouldn't be there. The binary details say prerendered icon = true, so it should be okay...

Please don't be reflective please don't be reflective please don't be reflective...

Apple doesn't even get the rounded corners right in iTunes Connect. v :shobon:

v

It used to be that the UIPrerenderedIcon key had to be at the root level (or whatever) of the app's info.plist if you didn't want the gloss effect, but now when you tick the "Prerendered" checkbox in Xcode's app target summary screen that key gets stuck down in the CFBundleIcons dictionary part of info.plist (the one that shows up as "Icon Files (iOS 5)" if you open the actual info.plist for your app in Xcode).

My guess is that the part of iTunes Connect that shows your app's icon is just scanning the root level of the info.plist for the prerendered icon key and not finding it. You can always add this yourself; it won't hurt anything.

edit: and if you don't add it, it won't matter either, as long as it's in the CFBundleIcons part of the info.plist (where Xcode puts it).
On iOS 5+, the device will know to look in the CFBundleIcons dictionary. If you're targeting iOS 4, though, iOS 4 devices won't know to look anywhere but the root level of info.plist, won't be able to find the UIPrerenderedIcon key, and your icon will be rendered with the gloss effect on that device.

edit 2: I hope that makes sense. It's late...

Doc Block fucked around with this message at 05:21 on Aug 30, 2012

# ? Aug 30, 2012 04:47

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

tarepanda posted:

Oh, shoot. If you could do that, it would be a big help.

I forget which sample app I ended up downloading to look at, but it was only for taking a picture and scanning. I'm heading into work now and will look again.

So, here's a very bare-bones but working "live" scanner. This was written with 4.3, thus the non-use of ARC.

code:

#import <UIKit/UIKit.h>
#import "ZBarSDK.h"

@interface BarcodeScannerViewController : UIViewController <ZBarReaderViewDelegate>

@property (nonatomic, retain) IBOutlet ZBarReaderView *barcodeScanner;

@end

code:


#import "BarcodeScannerViewController.h"
#import <AVFoundation/AVFoundation.h>

@implementation EPBarcodeScannerViewController

@synthesize barcodeScanner = _barcodeScanner;

- (void)viewDidLoad
{
    [super viewDidLoad];
    _barcodeScanner.readerDelegate = self;

     NSArray *devices = [AVCaptureDevice devices];
     AVCaptureDevice *theCamera = nil;
     for (AVCaptureDevice *device in devices) {
         if ([device hasMediaType:AVMediaTypeVideo]) {
     
             if ([device position] == AVCaptureDevicePositionBack) {
                 theCamera = device;
                 _barcodeScanner.device = theCamera;
             }
         }

     }
}

- (void)viewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];
    [_barcodeScanner start];
}

- (void)viewDidDisappear:(BOOL)animated
{
    [_barcodeScanner stop];
    [super viewDidDisappear:animated];
}

// this is important if you rotate!
- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation 
                  duration:(NSTimeInterval)duration
{
    [_barcodeScanner willRotateToInterfaceOrientation: toInterfaceOrientation
                                        duration: duration];
    [super willRotateToInterfaceOrientation:toInterfaceOrientation duration:duration];
}

#pragma mark - ZBarReaderDelegate
- (void) readerView: (ZBarReaderView*)view 
     didReadSymbols: (ZBarSymbolSet*) syms 
          fromImage: (UIImage*) img
{
    _errorLabel.text = @"";
    ZBarSymbol *symbol = nil;
    for(symbol in syms) {
        break;
    }
    NSLog(@"scanned code: %@", symbol.data);
    // do something clever with your scanned code
}

- (void)dealloc {
    [_barcodeScanner release];
    [super dealloc];
}

@end

Then in your View controller's NIB, drag out a view, position / size it, and in the Identity Inspector, change it's class to ZBarReaderView and hook it up to the outlet in the controller.

# ? Aug 30, 2012 20:52

tarepanda: Mar 26, 2011; Living the Dream

I actually understand most of that, surprisingly (or maybe I think I do and I don't), but what's up with - readerView: didReadSymbols: fromImage:? It's never called, right? But that's the important part.

# ? Aug 31, 2012 00:50

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

tarepanda posted:

I actually understand most of that, surprisingly (or maybe I think I do and I don't), but what's up with - readerView: didReadSymbols: fromImage:? It's never called, right? But that's the important part.

It's a delegate method. Usually you can tell by the name starting with the sender of the message, in this case the reader view, and the keyword "did" ("should" & "will" are other keywords used in delegate methods).

The method is defined in the ZBarReaderViewDelegate protocol in ZBarReaderView.h (included via ZBar.h) and will be called by the view when it has processed new symbols.

This is a common pattern in Objective-C/Cocoa code. Most data views will have a delegate and/or a data source. Your own object will act as the view's delegate and you implement the methods from the delegate protocol that you want (sometimes, they are required, sometimes optional). The view will call the ones you implement and ignore the ones you don't.

E: https://developer.apple.com/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html

Carthag Tuek fucked around with this message at 01:20 on Aug 31, 2012

# ? Aug 31, 2012 01:16

tarepanda: Mar 26, 2011; Living the Dream

Ahh. That's one thing I wish the BNR book had covered better -- naming conventions. Thanks.

Are there any other common ones (specific to Obj-C) I should be aware of?

Edit: Duh. I just noticed the whole "pragma mark" thing that announces that the function is a delegate.

tarepanda fucked around with this message at 06:11 on Aug 31, 2012

# ? Aug 31, 2012 01:26

Froist: Jun 6, 2004

tarepanda posted:

Edit: Duh. I just noticed the whole "pragma mark" thing that announces that the function is a delegate.

Yes and no. You may already know this, but just to avoid you getting confused, "pragma mark" doesn't mean anything to the compiler/precompiler. It just puts dividers in Xcode's function jump list so you can group your code more neatly.

It's good to put them in, but the code would function exactly the same without them.

# ? Aug 31, 2012 07:56

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

tarepanda posted:

Are there any other common ones (specific to Obj-C) I should be aware of?

Hmm I dunno that I can think of any others right now. Apple has a document on naming conventions for developers though, at first glance it meshes nicely with how their own methods are named:

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

# ? Aug 31, 2012 13:10

zergstain: Dec 15, 2005

zergstain posted:

I'm working with OS X here. I found -[NSImage initWithCGImage: size:] and -[NSImage CGImageForProposedRect: context: hints:] and am passing nil for context and hints. Is that the best way?

I'd also like to detect if the region i grabbed was entirely one color (black in this case), and throw it away if so.

Edit: Apparently it isn't the best way. It's scaling the full image to fit in the rect I specify rather than using the rect as a clipping region.

I got something that works, not sure it's the best way though. Anyway, I'm not exactly sure how I should go about this part:

quote:

I'd also like to detect if the region i grabbed was entirely one color (black in this case), and throw it away if so.

Would iterating over every pixel and comparing it to black be a good idea, or even possible? The images would be 32x32.

# ? Aug 31, 2012 16:13

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

At some point I feel like you should just try the first idea you think of and see how it goes.

# ? Aug 31, 2012 19:13

Doc Block: Apr 15, 2003; Fun Shoe

zergstain posted:

I got something that works, not sure it's the best way though. Anyway, I'm not exactly sure how I should go about this part:

Would iterating over every pixel and comparing it to black be a good idea, or even possible? The images would be 32x32.

For a 32x32 image it should be fine.

edit: Depending on how fast you need it to be, if you're just trying to see if the 32x32 image is entirely black then you can add up all the pixels in each row, and then see if it's non-zero. That way you're only doing 32 comparisons instead of 1024.

edit 2: Or even just add them all up for all rows and then do one comparison at the end. 32 pixels wide * 32 pixels tall = 1024 total pixels, with each having a maximum value of 765 (adding all 3 color components together), means the maximum possible total of adding all the pixels is only 783360, so overflow won't be a problem.

Doc Block fucked around with this message at 19:37 on Aug 31, 2012

# ? Aug 31, 2012 19:17

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

Also, timely blog post: http://www.mikeash.com/pyblog/friday-qa-2012-08-31-obtaining-and-interpreting-image-data.html

# ? Aug 31, 2012 19:35

fankey: Aug 31, 2001

I'm struggling with ARC issues. If I have a class which contains a pointer to another class with the default __strong attribute

code:

@interface Bar
{
}
@implementation Bar
-(void)dealloc
{
  NSLog(@"%@ dealloc", self);
}
@end

@interface Foo
{
  Bar* bar;
}
@implementation Foo

-(id) init
{
  if( self = [super init] )
  {
    bar = [[Bar alloc] init];
  }
}

-(void)dealloc
{
  NSLog(@"%@ dealloc", self);
}
@end

At the point in my code where I expect to release Foo I get the dealloc printout for Foo. The odd thing is I don't get the dealloc printout for Bar. I've combed through my code and commented out everything that could possibly be maintaining a reference to Bar.

Is there any case where deallocing Foo won't cause a dealloc on Bar ( excluding the obvious case where something else has a reference to Bar )? Are there any tools in XCode that can help trace who has a reference to Bar?

FAST EDIT:
If I add the following code to my Foo dealloc it will then dealloc Bar correctly

code:

-(void)dealloc
{
  NSLog(@"%@ dealloc", self);
  bar = nil;
}

I thought this sort of thing wasn't required with ARC - am I totally mistaken about that?

EDIT2 : Apparently having Zombies enabled was my issue ( per http://stackoverflow.com/questions/8695969/object-not-being-deleted-under-arc ).

fankey fucked around with this message at 22:34 on Aug 31, 2012

# ? Aug 31, 2012 20:58

tarepanda: Mar 26, 2011; Living the Dream

I've been using OpenCV to analyze live video feeds and I feel like I'm doing something wrong with my memory management, though I'm using ARC.

If nothing is happening, my memory allocations stay stable at around 17 MB, but if I start putting target objects in the picture and moving them around, allocations jump up to 50 MB and keep increasing -- that I can understand, since it's doing processing in the background. But when I take those objects out and the frame is empty again, the allocations stay at their former high.

I tried using the profiler to look for memory leaks and honestly don't know what the gently caress I'm doing. I can see the basic statistics (that's how I wrote the bit above), but it's not finding any memory leaks at all... so I feel like I'm just allocating things and never releasing them or something?

I'm so confused because I'm not too clear on ARC or Obj-C or iOS, much less with the whole thing after throwing C++ (OpenCV) into the mix...

# ? Sep 2, 2012 03:46

Doc Block: Apr 15, 2003; Fun Shoe

ARC doesn't work with C or C++, only Objective-C. So whatever C or C++ stuff you create, you'll also need to destroy. That's probably where your problem is: you're allocating buffers or creating objects or whatever and then never deallocating them.

# ? Sep 2, 2012 04:08

tarepanda: Mar 26, 2011; Living the Dream

Doc Block posted:

ARC doesn't work with C or C++, only Objective-C. So whatever C or C++ stuff you create, you'll also need to destroy. That's probably where your problem is: you're allocating buffers or creating objects or whatever and then never deallocating them.

Whew, good to know. I'd heard conflicting opinions... that should be an easy fix.

Edit: Wait, here's a really retarded question.

If I use standard C++ datatypes inside an Objective-C function, will their destructors still automatically be called as is usually par for the course, or do I have to deal with all of that manually?

Edit 2: Looked at the profiler again and CFData is consistently sucking up easily 99% of the memory my app is using. What the heck is that?

tarepanda fucked around with this message at 04:41 on Sep 2, 2012

# ? Sep 2, 2012 04:20

klem_johansen: Jul 11, 2002; [be my e-friend]

I'm getting weird crashes in an iPad app.

It's basically a kid's book with lots of animation and giant images. I'm using ARC and doing all the stuff I know to do in memory management such as setting IBOutlet UIImageViews to nil (foot.image=nil) in the didunload function, AVAUDIOPLAYER sounds as well.

All my property declarations are nonatomic,strong. Could that be a problem? Weak gives me an error.

Should I be declaring any and all graphics in the XIBs so ARC can trash them when thew viewcontroller is unloaded?

Another weird thing. I'm not seeing any real errors in the console when it crashes (which it does at seemingly random spots once I've paged through it for a while) and no memory warning messages.

# ? Sep 2, 2012 04:21

zergstain: Dec 15, 2005

Doc Block posted:

edit 2: Or even just add them all up for all rows and then do one comparison at the end. 32 pixels wide * 32 pixels tall = 1024 total pixels, with each having a maximum value of 765 (adding all 3 color components together), means the maximum possible total of adding all the pixels is only 783360, so overflow won't be a problem.

Went with this but slightly modified because mine have alpha. I could potentially be dealing with a thousand images, so fast is good.

That blog post was extremely helpful as well.

# ? Sep 2, 2012 04:47

Doc Block: Apr 15, 2003; Fun Shoe

tarepanda posted:

Whew, good to know. I'd heard conflicting opinions... that should be an easy fix.

Edit: Wait, here's a really retarded question.

If I use standard C++ datatypes inside an Objective-C function, will their destructors still automatically be called as is usually par for the course, or do I have to deal with all of that manually?

Edit 2: Looked at the profiler again and CFData is consistently sucking up easily 99% of the memory my app is using. What the heck is that?

CF = Core Foundation. It's the C equivalent of the Foundation classes (CFArray = NSArray, CFData = NSData, etc.). Something is probably creating a bunch of CFDatas for easy passing out of OpenCV, since Core Foundation and Foundation types are toll-free bridged (you can pass a CFData to a method that expects an NSData and it will Just Work, and vice versa).

As to the C++ destructors being called, I'd imagine the same general rules as C++ apply: if a C++ object is created on the stack then its destructor should be automatically called, but if it's on the heap then you'll have to delete it or whatever. I've only got a passing knowledge of C++ though.

Doc Block fucked around with this message at 05:39 on Sep 2, 2012

# ? Sep 2, 2012 05:29

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

tarepanda posted:

If I use standard C++ datatypes inside an Objective-C function, will their destructors still automatically be called as is usually par for the course, or do I have to deal with all of that manually?

Destructors get called as you'd expect.

quote:

Edit 2: Looked at the profiler again and CFData is consistently sucking up easily 99% of the memory my app is using. What the heck is that?

It's a CoreFoundation object representing a pile of bytes. Toll-free bridged with NSData.

If I had to guess, I'd think you're wrapping up some data from a library into an NSData for passing back into Objective-C land. Maybe turning a cvArray into a UIImage or whatever.

# ? Sep 2, 2012 05:29

tarepanda: Mar 26, 2011; Living the Dream

pokeyman posted:

It's a CoreFoundation object representing a pile of bytes. Toll-free bridged with NSData.

If I had to guess, I'd think you're wrapping up some data from a library into an NSData for passing back into Objective-C land. Maybe turning a cvArray into a UIImage or whatever.

That makes sense. I'm using a function written by Robin Summerhill to convert UIImage to OpenCV cv::Mats. I've narrowed my problem down to that -- when I use it, pushes up CFData and Malloc 396.00KB allocations up by around 10 MB/s...

Edit: Looking at his examples, it looks like he wasn't using ARC and was manually releasing after every conversion...

Edit 2: Got it! Hooray for @autoreleasepool. I don't know why I thought it wasn't usable with ARC...

tarepanda fucked around with this message at 06:43 on Sep 2, 2012

# ? Sep 2, 2012 05:42

klem_johansen: Jul 11, 2002; [be my e-friend]

Some practices have changed so I want to make sure I'm formatting my headers correctly.

The way I learned iOS, for IBOutlet stuff we added two references, one inside the interface and then another outside the brackets where you add a @property line with the nonatomic,retain info.

For example:

@interface fooViewController : UIViewController{
IBOutlet UIImageView *bar;
}
@property (nonatomic,retain) IBoutlet UIImageView *bar;

I've seen some tutorials that imply that it's not necessary to have the earlier declaration and it messes up attempts to use "weak" properties. This is for an app where the views are like pages in a book, so when they go away I need them to go away for good because the images are huge.

@interface fooViewController : UIViewController{
}
@property (nonatomic,weak) IBoutlet UIImageView *bar;

Does that look right or am I insane?

# ? Sep 2, 2012 06:38

Doc Block: Apr 15, 2003; Fun Shoe

Don't use a weak property for something like that unless you don't mind it disappearing out from under you.

But yes, you can just do

code:

@interface MyViewController : UIViewController

@property (nonatomic, strong) IBOutlet UIImageView *profilePic;

@end

And you don't need to @synthesize the property or specify an instance variable (one will be automatically created, with the default in this case being _profilePic).

You don't even need to put that in the header, though. Since this is a property that other classes probably shouldn't mess with, make it "private" by doing it as a class continuation in the implementation file:

code:

MyViewController.m

#import "MyViewController.h"

@interface MyViewController ()

@property (nonatomic, strong) IBOutlet UIImageView *profilePic;

@end

@implementation MyViewController
...

edit: If you're going to have a lot of huge images, you're going to have to think of a better way to manage them than just making each page be its own XIB and hoping you don't run out of memory.

Doc Block fucked around with this message at 07:51 on Sep 2, 2012

# ? Sep 2, 2012 07:39

Doc Block: Apr 15, 2003; Fun Shoe

edit: doublepost

Doc Block fucked around with this message at 07:50 on Sep 2, 2012

# ? Sep 2, 2012 07:44

tarepanda: Mar 26, 2011; Living the Dream

What's up with AVCaptureSession blocking audio playback? Was that ever fixed?

I've tried with AudioServicesPlaySystemSound and AVAudioPlayer, no sounds at all...

# ? Sep 2, 2012 08:00

klem_johansen: Jul 11, 2002; [be my e-friend]

Doc Block posted:

edit: If you're going to have a lot of huge images, you're going to have to think of a better way to manage them than just making each page be its own XIB and hoping you don't run out of memory.

Thanks. Here's what I have never understood about memory management. Once a viewcontroller (in this case a book page) is out fo the picture I need to eliminate all of its elements from memory. When and if the page comes back up, the app should recreate it anyway.

In the past I just set all my IBOutlet objects to nil in the didunload, and in the viewcontroller that handles the navigation I remove the previous view and set its view to nil. It's a technique that has worked find for me in the past.

When I look at the memory graph in Instruments the allocations just pile up until it gets into memory trouble.

Edit: I think ARC is doing its job. When I run through the book's first half over and over I don't get a crash but if I run through the last half several times I do. That tells me I have something I didn't put away properly- maybe.

Is there a big memory management difference between these approaches:

A) declare my IBOutlet imageviews,labels & buttons in the header, synthesize them and set them to nil in the didunload

b) Use tags to use temporary imageviews,labels & button references to do what I need and trust ARC to trash them.

*UIImageView *tmpImage=(UIImageView *)[self.view viewWithTag:605];

Is there an inherent difference between these? Maybe there isn't if I remember to set tmpImage to nil at the end of the function?

klem_johansen fucked around with this message at 17:19 on Sep 2, 2012

# ? Sep 2, 2012 14:52

Doc Block: Apr 15, 2003; Fun Shoe

No, there's not really a difference, so long as you nil your IBOutlets when the view is unloaded.

Are you making an entirely different view controller class for each page?!

If you ever refactor your app, it'd be worth it to have just a generic viewController that reads in what needs to happen/what images to show/etc. from a file and create the appropriate UI elements and animations as needed.

Also, how are you navigating between pages? A navigation controller?

# ? Sep 2, 2012 18:11

Toady: Jan 12, 2009

To clarify strong versus weak IBOutlets from the documentation:

quote:

From a practical perspective, in iOS and OS X outlets should be defined as declared properties. Outlets should generally be weak, except for those from File�s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene) which should be strong. Outlets that you create will therefore typically be weak by default, because:

Outlets that you create to, for example, subviews of a view controller�s view or a window controller�s window, are arbitrary references between objects that do not imply ownership.

The strong outlets are frequently specified by framework classes (for example, UIViewController�s view outlet, or NSWindowController�s window outlet).
@property (weak) IBOutlet MyView *viewContainerSubview; @property (strong) IBOutlet MyOtherClass *topLevelObject;

Presumably using weak outlets negates the need to nil them in -viewDidUnload since there's no ownership.

# ? Sep 2, 2012 22:19

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

klem_johansen posted:

Some practices have changed so I want to make sure I'm formatting my headers correctly.

The way I learned iOS, for IBOutlet stuff we added two references, one inside the interface and then another outside the brackets where you add a @property line with the nonatomic,retain info.

For example:

@interface fooViewController : UIViewController{
IBOutlet UIImageView *bar;
}
@property (nonatomic,retain) IBoutlet UIImageView *bar;

I've seen some tutorials that imply that it's not necessary to have the earlier declaration

Correct. Just to be clear here, the earlier declaration is an ivar (a "physical" field in the object, which you can access with ->bar), and the second declaration is a property (which declares instance methods that get implicitly used with .bar). If that seems needlessly redundant, well, most people agree with you, and on modern platforms (everything these days except 32-bit Intel), the first isn't required unless you really want to make the ivar public. But some people like to write out all their ivars explicitly so that they have one place they can check.

klem_johansen posted:

and it messes up attempts to use "weak" properties.

It doesn't mess them up, but there's some subtlety going on. In ARC, an ivar has its ownership inferred just like anything else, so UIImageView *bar; is implicitly __strong. If a property isn't just "logical" � that is, if the property methods actually read and write to some ivar � it's important that the ivar have the same ownership as the property. So if you declare a property weak (or unsafe_unretained), and you synthesize it to use an ivar that you declared explicitly, that ivar needs to have been declared __weak (or __unsafe_unretained as appropriate).

# ? Sep 2, 2012 23:32

Doc Block: Apr 15, 2003; Fun Shoe

Toady posted:

To clarify strong versus weak IBOutlets from the documentation:

Presumably using weak outlets negates the need to nil them in -viewDidUnload since there's no ownership.

Yeah, guess I hadn't thought of it that way...

An AVFoundation question:

Should I be looping over the capture connections in my -takePhoto: method, or do it when I set up the rest of the AVFoundation stuff and just save the AVCaptureConnection?

edit: so, should I be doing

Objective-C code:

AVCaptureConnection *videoConnection = nil;
	
for(AVCaptureConnection *connection in self.stillImageOutput.connections) {
	for(AVCaptureInputPort *port in connection.inputPorts) {
		if([port.mediaType isEqual:AVMediaTypeVideo]) {
			videoConnection = connection;
			break;
		}
	}
}

in -takePhoto:, or do it after I set up the rest of the AVFoundation stuff and save videoConnection for -takePhoto: to use later?

Doc Block fucked around with this message at 00:56 on Sep 3, 2012

# ? Sep 3, 2012 00:43

tarepanda: Mar 26, 2011; Living the Dream

tarepanda posted:

What's up with AVCaptureSession blocking audio playback? Was that ever fixed?

I've tried with AudioServicesPlaySystemSound and AVAudioPlayer, no sounds at all...

I've been trying a lot of things and this is seriously irritating me.

# ? Sep 3, 2012 01:17

hedgecore: May 2, 2004

This is a bit more of an abstract question than specifically for coding, but I'm wrapping up the development work on v1 of my first app and am preparing to send it in for review. Anyone have any first-time mistakes they'd like to share that I can possibly avoid? Or just things I might be overlooking in general? No need to repeat the bad kind of history

# ? Sep 3, 2012 20:33

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

The big one I guess is thoroughly test it from a completely clean build (i.e. delete DerivedData) on a device other than the one you mostly use for debugging. You don't want to get caught with e.g. an old nib hanging around on your development device that'll crash a release version.

Oh, and set the release date to a few months from now so you control when it gets released after successful review.

And good luck!

# ? Sep 3, 2012 21:10

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 00:12

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

tarepanda posted:

I've been trying a lot of things and this is seriously irritating me.

I know nothing about AVFoundation, and while a few people around here know more than that, I guess they don't have any ideas for you? Sorry.

# ? Sep 3, 2012 21:11

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

«‹›354 »