|
The recommendation is to only use exceptions for programmer error. Never for flow control. Usually it makes the most sense to return nil or NO if something fails, and document why it could happen. You may want to have an NSError too, if details are needed. Check out the error handling guide: http://developer.apple.com/library/.../uid/TP40001806
|
#
?
Oct 30, 2012 01:59
|
|
|
|
| # ? Jun 4, 2024 05:28 |
|
|
Exceptions combine pretty terribly with manual memory management, so pre-ARC you'd have to be crazy to use them for non-fatal errors. With ARC I guess you could make it work, but fighting against the established style of a language is rarely a good idea.
|
|
#
?
Oct 30, 2012 02:52
|
|
|
Are there any good guides out there for understanding all the different types of certificates involved in developing and deploying iOS apps? Provisioning profile and all that jazz. I had to regenerate the development cert when I added push notifications through Parse to the app and then some magic happened and the profiler won't run on the development cert and bla bla.. Plus there's the whole aspect where Organizer will add certificates to your Keychain when running XCode even when you just removed them (to address XCode complaining about there being two certs with the same name). It's just not sane in any way and I have strong reservations about being able to get all of the certs right by the time I need to submit the app for review.. DreadCthulhu fucked around with this message at 06:11 on Oct 30, 2012 |
|
#
?
Oct 30, 2012 06:08
|
|
|
I'm now about 2 months in iOS development and I haven't touched the interface builder. Back when I was doing Silverlight (C# and XAML), we never used the GUI and instead did everything by hand as it seemed easier to have exact control over everything. What's the general consensus on using the IB over doing everything by hand? I'm pretty comfortable doing everything in code right now, but I'd prefer to not be shooting myself in the foot.
|
|
#
?
Oct 30, 2012 13:47
|
|
|
I can write the interface in code if needed, but I prefer to use IB most of the time. It provides faster feedback and means I don't have to type out a giant wall of code just to get a view with a few buttons on it.
|
|
#
?
Oct 30, 2012 14:07
|
|
|
Doh004 posted:I'm now about 2 months in iOS development and I haven't touched the interface builder. Back when I was doing Silverlight (C# and XAML), we never used the GUI and instead did everything by hand as it seemed easier to have exact control over everything. Storyboards are great. They let you lay everything out so you can see the overview of your entire program and really speed up UI dev time, although I've never tried to build an app from code alone, but I imagine that being able to plop down a window is easier than copy/pasting code. One of the main things is that you don't have to use it alone. If you prefer not to have a bunch of buttons with segue connections, you can call segue's directly, or even just not have any segue connections at all in your storyboard and just initiate views from the storyboard as you need them. Carthag posted:The recommendation is to only use exceptions for programmer error. Never for flow control. Usually it makes the most sense to return nil or NO if something fails, and document why it could happen. You may want to have an NSError too, if details are needed. Plorkyeran posted:Exceptions combine pretty terribly with manual memory management, so pre-ARC you'd have to be crazy to use them for non-fatal errors. With ARC I guess you could make it work, but fighting against the established style of a language is rarely a good idea. Alright cool. This is what I've been thinking/doing. I just wanted to see what others thought!
|
|
#
?
Oct 30, 2012 16:48
|
|
|
I generally go with IB for speed but frequently end up coding things in that can't be done in IB. The benefits of being able to see, resize, and drag pieces of my interfaces around outweigh the IB headaches. I still haven't touched storyboards.
|
|
#
?
Oct 31, 2012 00:52
|
|
|
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.
|
|
#
?
Oct 31, 2012 01:47
|
|
|
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
|
|
|
Check out the WWDC video about auto layout... They cover doing it in code with ASCII markup. It's pretty drat cool. You can create various constraints, eg: - is one standard unit so @"[btn1]---[btn2]" constrains btn1 and btn2 to be three standard widths apart. Or @"[btn1(==btn2)]" which makes btn2 keep the same width as btn1. "V:" makes the layout turn vertical. Here is the doc about it: https://developer.apple.com/library...0010853-CH3-SW1
|
|
#
?
Oct 31, 2012 02:54
|
|
|
On my iPhone 4S (6.0), iPhone 5 (6.0), iPad 3 (6.0), and the simulators (6.0/5.1) it draws the gradient correctly. On my old iPhone 3GS (5.0) the stroke around the gradient is drawn but the gradient interior itself draws sometimes, other times it doesn't (and it just shows the view behind the button). If I tap on the button, which draws the highlighted state, the highlight gradient draws. And sometimes if I open up a view the main gradient *does* draw correctly. But if I tap, scroll or if I just wait it suddenly disappears. When it renders offscreen and I scroll it on-screen, it mostly shows up OK since the scroll view is just moving the offscreen buffer around but as soon as the scroll stops and the gradient has to draw itself, it disappears again. Unfortunately I'm stuck by Apple's refusal to sign older OSes because if I upgrade this test device I can only upgrade to iOS 6, then I won't have any iOS 5 devices. I have an iPod Touch Retina but I can only upgrade it to iOS 6 for the same reason; I wish I had upgraded it before iOS 6 was released but then I wouldn't have an iOS 4.x device. edit: Very similar gradient code is drawing my cell backgrounds and it works just fine, so I'm officially confused. I tried setting the layer to shouldRasterize so it would cache the draw result but it doesn't seem to matter for the buttons (of course it speeds up table view scrolling by a ton). edit2: OK CGGradientCreateWithColors is returning NULL so that explains it somewhat... edit3: False alarm, cancel red alert... Apparently if you screw up and feed an array with a capacity greater than the number of objects in for the colors to CGGradientCreateWithColors, on iOS 5 and/or non-retina screens it will fail to create the gradient... but only under certain circumstances. No idea why it would care that the array has more slots than objects but there you go. Simulated fucked around with this message at 04:03 on Oct 31, 2012 |
|
#
?
Oct 31, 2012 03:20
|
|
|
Plorkyeran posted:Exceptions combine pretty terribly with manual memory management, so pre-ARC you'd have to be crazy to use them for non-fatal errors. With ARC I guess you could make it work, but fighting against the established style of a language is rarely a good idea. Exceptions in ARC are basically the same as manual memory counting. Objective-C exceptions are meant to signal that something went unrecoverable wrong, so, again, not for control-flow. The general rule in Cocoa is that if you capture an exception and keep running, you've probably ended up leaking something (At least by virtue of the fact that "you're doing it wrong" in the first place).
|
|
#
?
Oct 31, 2012 15:40
|
|
|
Here is one of my auto layout strings I am most 'proud' of.Objective-C code:
|
|
#
?
Oct 31, 2012 16:17
|
|
|
Kallikrates posted:Here is one of my auto layout strings I am most 'proud' of.  good lord, I think I should start re-learning IB.
|
|
#
?
Oct 31, 2012 16:52
|
|
|
The horror part is that the strings can only really be debugged/checked at runtime. Whereas in IB you can enable preview mode(OSX).
|
|
#
?
Oct 31, 2012 16:59
|
|
|
Is there a way to get a message when an HTML5 audio file is played in a UIWebview?
|
|
#
?
Nov 1, 2012 04:03
|
|
|
Any words of wisdom and guidelines regarding what to do about logging and tracking crashes when the application is NOT running locally under the debugger? I really need a strategy for the following scenarios: - app running in release mode during local testing. I have access to the phone. - app running on beta-tester devices provisioned through Testflight, I don't have access to the device. - app running on customer devices.
|
|
#
?
Nov 1, 2012 04:09
|
|
|
Local testing: open up the Organizer window in Xcode and look at the crash logs for the device. TestFlight: they provide crash reporting. You can even upload your DSYMs and TestFlight will symbolicate the crash logs for you. Customer devices: if they said No to sending usage information to Apple then iOS won't send crash logs from that device. If you left TestFlight in your app store build then you should still get crash logs from them. edit: if you're using Flurry, you can use it to do crash reporting with a custom exception handler, like so: Objective-C code:Doc Block fucked around with this message at 06:32 on Nov 1, 2012 |
|
#
?
Nov 1, 2012 06:20
|
|
|
Is there a way to manually set exposure/white balance values? I'm guessing no since I've scoured the documentation and all I can find is turning on auto balance/exposure and locking it.
|
|
#
?
Nov 1, 2012 06:39
|
|
|
No. You can't permanently lock the exposure either, like you can with focus, at least not for still photos. The best you can do is set an exposure point of interest (if the device supports it), then change the exposure mode to AVCaptureExposureModeContinuousAutoExposure (or whatever it is), which will cause the camera to set correct exposure for the set point of interest and then sort of "soft lock" the exposure (exposure will stay the same unless there's a significant change in the scene).
|
|
#
?
Nov 1, 2012 07:00
|
|
|
Ugh. The white balance is driving me absolutely insane because it's screwing with color, which in turn screws with my analysis... I can lock it, but depending on the lighting when I lock it down, it can be great or terrible. I've been trying to think of a way to trick the camera into balancing a certain way and locking, but I can't... Edit: It's a lovely solution, but I can apply CIWhitePointAdjust to every single frame... tarepanda fucked around with this message at 08:24 on Nov 1, 2012 |
|
#
?
Nov 1, 2012 07:06
|
|
|
DreadCthulhu posted:Any words of wisdom and guidelines regarding what to do about logging and tracking crashes when the application is NOT running locally under the debugger? I really need a strategy for the following scenarios:
|
|
#
?
Nov 1, 2012 10:14
|
|
|
Doc Block posted:Local testing: open up the Organizer window in Xcode and look at the crash logs for the device. Thanks, very helpful!! Another question: should/can I use the same profile for both TestFlight distribution and AppStore, or do I have to have two separate profiles for that purpose?
|
|
#
?
Nov 1, 2012 12:10
|
|
|
NoDamage posted:I've started using Hockey for beta and production crash reporting, and really like it so far. It's compatible with iOS/Mac/Android so we can keep all of our crash reports in one place. How does it compare to Flurry? I'm using that per Doc Block's recommendation since it was already in the app for analytics, but if I can get significantly better quality reports then I'm down to switching.
|
|
#
?
Nov 1, 2012 12:11
|
|
|
Bonefish posted:Is there a way to get a message when an HTML5 audio file is played in a UIWebview? The only way you can really have a web view push information out into the app is with URL callbacks. Basically you set up a delegate with a "-(BOOL)webView:shouldStartLoadWithRequest:navigationType:" defined, then you check the url on the request. What'd you'd do is stick something like a javascript "window.location = 'app://soundplayed'" every time there's a sound, and capture it in the app by matching request.url with "app://soundplayed", doing what you want, and returning NO (shouldStartLoadWithRequest returning NO means that the webview won't perform a navigation). Obviously you'd have to have control over the page content. DreadCthulhu posted:How does it compare to Flurry? I'm using that per Doc Block's recommendation since it was already in the app for analytics, but if I can get significantly better quality reports then I'm down to switching. I'd throw in Crashlytics, too. Both are better than what Flurry has, really. Crashlytics has a Mac App component that captures the symbol tables for each build, which means you don't have to do any extra work to symbolicate a crash. It's a nice feature that becomes a clincher if you're working on a team with multiple devs, because it does away with the easily-skippable step of having to put the DSYMs in a certain place.
|
|
#
?
Nov 1, 2012 21:14
|
|
|
I haven't done much coding experimentation in OS X; only iOS. I want to make my own window minimizing effects to start since there are only three I know of. How would I go about doing this, and would something like this be allowed in the App Store?
|
|
#
?
Nov 2, 2012 02:32
|
|
|
If you mean like the genie effect or something, that's done by the OS.
|
|
#
?
Nov 2, 2012 04:22
|
|
|
Right, so if people have made Apps to override the controls of a window, couldn't I make one that overrides the effects of minimizing a window?
|
|
#
?
Nov 2, 2012 14:12
|
|
|
An app just asks the OS to minimize one of its windows, it doesn't do the actual minimizing itself. You'd need some way to put a minituarized version of the window in the dock without actually using the minimization effect from the OS. Not sure that's possible. I mean I suppose you can override NSWindow's -performMiniaturize: and do your own animation with the window without calling up to super, but after that you'd still need to have it sit in the dock like users would expect. Hmm, maybe -miniaturize: and -deminiaturize: can help?
|
|
#
?
Nov 2, 2012 15:24
|
|
|
Carthag posted:An app just asks the OS to minimize one of its windows, it doesn't do the actual minimizing itself. All I really know is that you can minimize a window by typing this into Terminal (in this case minimizing Terminal): /usr/bin/osascript -e 'tell application "System Events" to click (first button of (every window of (application process "Terminal")) whose role description is "minimize button")' But that will still perform the animation.
|
|
#
?
Nov 3, 2012 00:48
|
|
|
Looks like that's just some AppleScript that clicks on the window's minimize button. The OS still handles doing the actual minimizing.
|
|
#
?
Nov 3, 2012 00:56
|
|
|
Yeah, that's what that does. It's just a button click.
|
|
#
?
Nov 3, 2012 05:14
|
|
|
What is the recommended JSON parser library if I want to target OSX pre-10.7? I realize that 10.7 comes with an Apple-provided JSON parser but I'd prefer to target all the way back to 10.5 or 10.6 if I can help it.
|
|
#
?
Nov 4, 2012 05:14
|
|
|
Martytoof posted:What is the recommended JSON parser library if I want to target OSX pre-10.7? I realize that 10.7 comes with an Apple-provided JSON parser but I'd prefer to target all the way back to 10.5 or 10.6 if I can help it. I've always used SBJson to target iOS versions that don't support the Apple parser, I assume there's an OS X version (or the same code works).
|
|
#
?
Nov 4, 2012 07:12
|
|
|
https://github.com/johnezang/JSONKit
|
|
#
?
Nov 4, 2012 07:13
|
|
|
Awesome, thank you both. Speed isn't too much of an issue so I'm going to not use JSONKit due to his grave warnings about ARC compatibility.
|
|
#
?
Nov 4, 2012 07:40
|
|
|
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
|
|
|
Any good patterns out there that you would recommend to handle dynamically generated buttons and their respective actions? Say you want to present a multiple choice question that can have anywhere between 2 and 5 answers and you want to determine in a handler which of the buttons was tapped. Should I use tags, and for example, assign 1 through 5 to each button in succession or is there a cleaner way of doing this?
|
|
#
?
Nov 5, 2012 12:13
|
|
|
I'd do that. Other options include: using unique handlers for each button (tappedA, tappedB, etc.), and setting some specific value on the buttons other than the tag (subclass and add a property, or associate an object).
|
|
#
?
Nov 5, 2012 12:57
|
|
|
|
| # ? Jun 4, 2024 05:28 |
|
|
Another option is to have a single "-(IBAction)tapped:(id)sender" method that asks the sender what the title of the button is and switches on that.
|
|
#
?
Nov 5, 2012 16:51
|
|
