|
Doc Block posted:The new iOS 6 autorotation methods don't get called if your app's deployment target is anything earlier than iOS 6. So really we don't have to worry about these new methods unless our app is iOS 6-only? Does the same go for the Game Center API changes? I spent a lot of trial-and-error time trying to get both of those working correctly for < 6 devices in my game framework, and I would hate to do that all over again. As long as I can support the iPhone 5 screen AND still only use the < 6 methods, I'd be happy.
|
#
?
Jan 23, 2013 23:47
|
|
|
|
| # ? May 16, 2024 00:46 |
|
|
What are people's thoughts on the new Autolayout feature? I'm pretty familiar with the iOS 5 layout system, but I'd love to know if I'm missing out on something amazing here. Have you guys used it and found it indispensable? Is it better for certain situations more than others? Universal apps? Share your wisdom, plox.
|
|
#
?
Jan 24, 2013 10:40
|
|
|
Incoming wall of text... I've been using autolayout on OS X for the last several months. I like the idea of it, but I find it very frustrating to use in practice. The increase in flexibility compared to springs and struts is great, and it works really well in certain situations, but as things get more complicated it starts to become very unwieldy. The first problem I have with it is that managing constraints in interface builder sucks. Trying to wrestle with the constraints that get automatically added and turn them into the layout you want can be a huge hassle if your interface isn't very simple. Part of the problem is that interface builder never allows you to have an invalid set of constraints. This means that as you're trying to create, delete or edit constraints, IB will be adding its own constraints that you'll most likely need to delete or edit afterwards. You also can't edit a constraint directly from a view that it's attached to. You have to manually select the constraint, which is a cumbersome process when trying to edit several of a view's constraints at once. The layout will generally be ruined if you move or resize anything in IB unless you do it strictly by modifying the constraints themselves. I've found this to be particularly problematic when I want to add some new element to an interface and I need to shift things around to accomodate it. So overall using autolayout in interface builder is really annoying unless you can get by with the default constraints that it creates for you. Hopefully in future versions of Xcode they'll improve the experience. Managing constraints in code has a whole different set of problems. The basic API for adding/removing constraints isn't bad -- the visual layout strings are pretty neat and relatively convenient to use, although they only work for basic layouts. But the biggest problem I have with autolayout is the process of creating a view with dynamic subviews -- something like NSTableView, which adds/removes subviews for its rows at run time. The majority of the custom views in the app I'm working on work this way, in that subviews need to be added/removed and constraints need to be updated dynamically at run time as model data changes. Creating such a view is extremely complicated. I've watched every WWDC video on autolayout and layer-backed views several times and I still don't really understand how it's supposed to work. They don't go into nearly enough depth on this type of situation, and the examples they give are confusing and not explained well. With autolayout there are three phases to the view update cycle. You have updateConstraints, layout and drawRect: (or updateLayer depending on the view), and you call setNeedsUpdateConstraints:, setNeedsLayout: or setNeedsDisplay: to flag a particular phase for updating. This seems straightforward, and in many cases it is, but if you need to manage dynamic subviews, things get complicated quickly. Based on WWDC videos, the process involves a satanic ritual that requires some combination of adding/removing subviews inside of layout, making sure to call [super layout] a whole bunch of times (you might need to wrap some of them in zero-duration animations for some reason), invalidating your constraints again and manually calling updateConstraintsForSubtreeIfNeeded every once in a while. There is no real documentation on this. But according to the WWDC videos, this is the recommended way of creating a custom view. It would be extremely helpful if Apple would put together an actual programming guide on this topic. Honestly, ever since I've adopted autolayout I've really hated writing custom views. Since it's such a new technology there isn't even anyone writing about it beyond the very basics as far as I've been able to tell, so getting information is a crapshoot. Oh, and debugging autolayout sucks too. They've clearly tried to make it easier by adding various tools for debugging constraints, but in my experience the tools have been unhelpful the vast majority of the time. So I guess my overall thoughts on autolayout are that it's way too complicated. If Apple wants to push this as the recommended layout technology in Cocoa, I hope they make some significant improvements to it, or at the very least to its documentation. Fake edit: I don't have any experience with iOS when it comes to autolayout. I'm not sure how much of what I said applies on that platform.
|
|
#
?
Jan 24, 2013 13:30
|
|
|
Quoting myself:Kallikrates posted:
Autolayout is annoying in IB, because the interface can and will break/remove hours of work fiddling with constants, and constraint types Autolayout is annoying in Code because it's hard to debug preview and write. The above code is not a complex layout. Autolayout debugging could be worse. My experience is MaxOS centric and likely to have more subviews growing and shifting than on iOS.
|
|
#
?
Jan 24, 2013 17:02
|
|
|
Has anyone seen a good write-up on implementing the popular "pull down to trigger an event" UI behavior for iOS? I'd like to do something similar to what the Yelp app does when you're looking at the details of a place that has an image. (Tweetbot for iOS does something similar on profile pages, though it doesn't trigger anything; all it does is stretch the user's cover image.) Here's a rough sketch of what I'm talking about :  Essentially, what I'm talking about is having an image whose top edge is flush with the top of the view, but which is not entirely visible. When you pull down on the "info" portion of the view, the image remains flush with the top, but as you pull down, it reveals the rest of the image. If you pull down far enough and release, an event or method is triggered; however, if you don't pull down far enough, the "info" portion will snap back up to its earlier position.
|
|
#
?
Jan 24, 2013 18:10
|
|
|
XCode is driving me up the loving wall right now. When I'm editing one specific file, it likes to randomly jump to some completely blank area of the screen (where any scrolling will actually swap files, so I'm not sure where it's actually going). I think it has something to do with multi-line warning messages that cannot seem to be minimized (as they normally would be until you click the warning symbol). What in the gently caress is going on here, and how do I make it stop? It's making it extremely difficult to edit that file.
|
|
#
?
Jan 24, 2013 18:29
|
|
|
stray posted:Has anyone seen a good write-up on implementing the popular "pull down to trigger an event" UI behavior for iOS? I'd like to do something similar to what the Yelp app does when you're looking at the details of a place that has an image. (Tweetbot for iOS does something similar on profile pages, though it doesn't trigger anything; all it does is stretch the user's cover image.) Look up how pull to refresh makes use of negative content offsets, or something?
|
|
#
?
Jan 24, 2013 18:30
|
|
|
stray posted:Has anyone seen a good write-up on implementing the popular "pull down to trigger an event" UI behavior for iOS? I'd like to do something similar to what the Yelp app does when you're looking at the details of a place that has an image. (Tweetbot for iOS does something similar on profile pages, though it doesn't trigger anything; all it does is stretch the user's cover image.) If your image view is added to a parent scroll view, you simply move your image view up offscreen by the maximum pullable distance, then implement pull to refresh like normal (e.g. here or here) And that's a quality sketch!
|
|
#
?
Jan 24, 2013 18:44
|
|
|
stray posted:Has anyone seen a good write-up on implementing the popular "pull down to trigger an event" UI behavior for iOS? I'd like to do something similar to what the Yelp app does when you're looking at the details of a place that has an image. (Tweetbot for iOS does something similar on profile pages, though it doesn't trigger anything; all it does is stretch the user's cover image.) My initial thought is to add the "info view" as a sub-view over the image, and then use a gesture recognizer to listen for swipe down... move the info subview in concert with the swipe, and when the swipe is released, check the distance of the swipe vs. your "trigger" value, then move the info-subview back, or leave it and run whatever code you want.
|
|
#
?
Jan 24, 2013 19:08
|
|
|
We're making our iPad app. There's a main content box, and to the right we have a vertical menu (it will only be like, 50pt wide in both landscape and portrait). I think there are two options: 1. Use a UISplitViewController and have the "Master" view be my main content view, and the "detail" view be my menu and change the behavior to not hide the "master" view when in portrait. 2. Use some sort of custom vertical UITabBarController and have the rest of the content view be however wide everything is. Which would be the more correct way? The only thing holding me back from using a UISplitViewController is that normally, you have the left view as the menu and the right side as the main content, but we'd be the opposite way. Does Apple not like that?
|
|
#
?
Jan 24, 2013 21:10
|
|
|
Doh004 posted:Which would be the more correct way? The only thing holding me back from using a UISplitViewController is that normally, you have the left view as the menu and the right side as the main content, but we'd be the opposite way. Does Apple not like that? Facebook does this though on their iPad app. Chat is on the right with content on the left.
|
|
#
?
Jan 24, 2013 21:48
|
|
|
PT6A posted:XCode is driving me up the loving wall right now. When I'm editing one specific file, it likes to randomly jump to some completely blank area of the screen (where any scrolling will actually swap files, so I'm not sure where it's actually going). I think it has something to do with multi-line warning messages that cannot seem to be minimized (as they normally would be until you click the warning symbol). I'm not having this issue but I'd like to contribute to the XCode bashing. Why the gently caress is IB randomly making my custom UIButtons rounded rect? Why XCode? Seriously, does this only happen to me? No one else in my office seems to have this happen. I'll open a xib, not modify it, and it'll somehow be modified and the only change is now all the UIButtons are rounded rect. 
|
|
#
?
Jan 24, 2013 22:06
|
|
|
take boat posted:If your image view is added to a parent scroll view, you simply move your image view up offscreen by the maximum pullable distance, then implement pull to refresh like normal (e.g. here or here) Thanks. What you see there is the absolute limit of my "artistic" abilities. And thanks for the tip; I'll try that out. What do people generally think about XIBs? Yea or nay? I've heard some people say it makes things easier, while others say that going without produces easier-to-maintain code.
|
|
#
?
Jan 24, 2013 23:15
|
|
|
Gordon Cole posted:autolayout Man, really doesn't sound like you've been having a good time there.. think I'l stick to the old school approach for now, thanks for clarifying why you didn't like it though.
|
|
#
?
Jan 24, 2013 23:40
|
|
|
Doh004 posted:We're making our iPad app. Strongly recommend avoiding UISplitViewController if you are doing anything other than exactly what it was designed for. It's entirely inflexible in every way. Crib someone's library as a starting point and/or roll your own.
|
|
#
?
Jan 25, 2013 00:02
|
|
|
I knew something was wrong with autolayout when I made a simple UIImageView and some UISliders in IB, and the default constraints smooshed the view and pushed the sliders off the screen when it rotated. Having not encountered autolayout before I spent 10 minutes fighting with it until I turned it off.Gordon Cole posted:Part of the problem is that interface builder never allows you to have an invalid set of constraints. Yeah this is really rough.
|
|
#
?
Jan 25, 2013 00:04
|
|
|
Gordon Cole posted:You also can't edit a constraint directly from a view that it's attached to. You have to manually select the constraint, which is a cumbersome process when trying to edit several of a view's constraints at once. When a view is selected, if you click the size inspector (the one with the ruler icon), the constraints are listed and selectable.
|
|
#
?
Jan 25, 2013 00:13
|
|
|
Is it an okay thing to put a category header in your .pch file? For example, if I make a category on UIColor that has one method +(UIColor *)random, and I want that available project-wide, am I doing something bad by putting it in there?
|
|
#
?
Jan 25, 2013 00:18
|
|
|
AutoLayout drove me nuts when I first adopted it for 10.7. After more experience with it in Interface Builder, as well as the improved support for it in NSSplitView in 10.8, I like it now and recommend it for everything. I only have it disabled for one window which displays an NSComboBox. In Lion and Mountain Lion, at least on my machine, the field editor doesn't get laid out correctly in an NSComboBox if it's the initial first responder, causing it to overlap the insides of the control as well as the blue highlight. The issue goes away with AutoLayout turned off. I filed a bug and hope it gets fixed.
|
|
#
?
Jan 25, 2013 00:21
|
|
|
cheese eats mouse posted:Facebook does this though on their iPad app. Chat is on the right with content on the left. I've actually asked the Facebook iOS lead about this before, since I know him. It's just a bunch of views manually managed and uses gesture recognizers to trigger the sliding. I don't think there's any split view controller voodoo going on.
|
|
#
?
Jan 25, 2013 00:32
|
|
|
stray posted:Thanks. What you see there is the absolute limit of my "artistic" abilities. And thanks for the tip; I'll try that out. I like setting things up in Xibs but they're basically impossible to merge and localizations are more annoying to handle.
|
|
#
?
Jan 25, 2013 01:10
|
|
|
Doctor w-rw-rw- posted:I've actually asked the Facebook iOS lead about this before, since I know him. It's just a bunch of views manually managed and uses gesture recognizers to trigger the sliding. I don't think there's any split view controller voodoo going on. Good to know for the future. I could see someone asking me to make it "just like the Facebook app".
|
|
#
?
Jan 25, 2013 01:33
|
|
|
cheese eats mouse posted:Good to know for the future. I could see someone asking me to make it "just like the Facebook app". I get told that at least once a week.
|
|
#
?
Jan 25, 2013 01:35
|
|
|
NSScreencast has an article about doing the slide out thing, basically he went over a bunch of open source libraries for doing it and listed the pros/cons of each one.
|
|
#
?
Jan 25, 2013 01:46
|
|
|
lord funk posted:Is it an okay thing to put a category header in your .pch file? For example, if I make a category on UIColor that has one method +(UIColor *)random, and I want that available project-wide, am I doing something bad by putting it in there? Totally fine. I do get some spurious "compiler" warnings in Xcode from time to time if I do this and don't import the .h file where I use it. Which makes sense as the .pch file is literally a "precompiled header". The goal is to quicken compiles. But it works ok as a global import list too.
|
|
#
?
Jan 25, 2013 02:06
|
|
|
Awesome. Also categories are great.
|
|
#
?
Jan 25, 2013 02:22
|
|
|
Toady posted:When a view is selected, if you click the size inspector (the one with the ruler icon), the constraints are listed and selectable. Right, but you can't actually edit them from there. You have to click the gear to open the drop-down menu, then click the edit option, which will select the individual constraint for editing. This also switches from the size inspector to the attributes inspector, since that's where the constraint attributes are. Once you're done, if you want to edit a different constraint on that view you have to re-select the view, go back to the size inspector and repeat the process. If you need to edit four or five constraints on a view it's a very tedious process.
|
|
#
?
Jan 25, 2013 02:39
|
|
|
Also, I've noticed that sometimes if I move an object, it will remake constraints for OTHER objects -- in particular, I have a button I want centered along the bottom of the screen and the constraints on that change almost every single time I edit the drat thing.
|
|
#
?
Jan 25, 2013 02:46
|
|
|
cheese eats mouse posted:Good to know for the future. I could see someone asking me to make it "just like the Facebook app". Let me quote directly: Facebook dude posted:There isn't anything particularly difficult about it; it's just a container view controller, with the central view controller's view placed above the side controllers', and the side ones are not loaded until they are revealed I must have lost some other parts of the conversation because I swear he went into a little more detail than that
|
|
#
?
Jan 25, 2013 03:00
|
|
|
How do you guys manage multiple people working on one app? I'm really not clear on how (well?) that would work with xcode and all of the certifications.
|
|
#
?
Jan 25, 2013 08:08
|
|
|
tarepanda posted:How do you guys manage multiple people working on one app? I'm really not clear on how (well?) that would work with xcode and all of the certifications. https://github.com/adobe/webkit/blob/master/Tools/Scripts/sort-Xcode-project-file Hugely useful.
|
|
#
?
Jan 25, 2013 15:00
|
|
|
pokeyman posted:Strongly recommend avoiding UISplitViewController if you are doing anything other than exactly what it was designed for. It's entirely inflexible in every way. Crib someone's library as a starting point and/or roll your own. I found this implementation: https://github.com/mattgemmell/MGSplitViewController It seems to work pretty well for keeping the master view visible when in portrait mode. That said, I could see just creating my own container ViewController with some sort of TableViewController for my menu items on the left and another "Content" ViewController.
|
|
#
?
Jan 25, 2013 16:56
|
|
|
Doh004 posted:I found this implementation: https://github.com/mattgemmell/MGSplitViewController Look around for forks of that lib that make it work in iOS 6, and with ARC if you care. But I'd just roll my own, it's not hard, and you get exactly what you need. Container view controllers are very easy to make as of iOS 5.
|
|
#
?
Jan 25, 2013 18:17
|
|
|
pokeyman posted:Look around for forks of that lib that make it work in iOS 6, and with ARC if you care. I think you're right. I'm pretty sure I already essentially did this with our profileviewcontroller, so it shouldn't be that hard to just roll it ourselves.
|
|
#
?
Jan 25, 2013 19:22
|
|
|
Gordon Cole posted:Once you're done, if you want to edit a different constraint on that view you have to re-select the view, go back to the size inspector and repeat the process. If you need to edit four or five constraints on a view it's a very tedious process. Ah, I see what you mean.
|
|
#
?
Jan 27, 2013 06:34
|
|
|
I'm enrolled in a course on iOS programming and we've just completed our first app: a card matching game. We've been tasked with extending our game into two different games. The other game will be made available in our app using a UITabView. The second card game will have similar controls and UI to the first one, so I'm looking for intelligent ways to share code. I've started by subclassing the first game's original View Controller into something specific for that first game. Next, I am attempting to push all first-game specific code to this specific View Controller subclass. This is where I'm encountering a hurdle. My professor has mentioned that there is an elegant solution that uses "object-oriented techniques without making ANY outlets or actions public." With this in mind, I'm having a hard time imagining how this might work. For instance, my IBActions that are connected to buttons in the view all call game specific code and perform functions on the model. It seems perfectly reasonable to make these actions public so that my game-specific subclass can override and append additional game-specific statements. One alternative I've considered is calling some helper function from each of these IBAction methods, making these helpers public, and overriding these helpers in the game-specific subclasses. However, this extra level of indirection raises red flags about design simplicity. Is there a common design pattern used in iOS programming that is applicable to this situation?
|
|
#
?
Jan 27, 2013 12:48
|
|
|
Final release of Xcode 4.6 and iOS 6.1 are out.
|
|
#
?
Jan 28, 2013 19:38
|
|
|
Star War Sex Parrot posted:Final release of Xcode 4.6 and iOS 6.1 are out. w00t. Time to swoon over release notes. Re: Jam2, my best guess is that you would use key value observing to react to actions on your cards, but then I'm not sure how the cards would react to user interaction from the UITableView. Please let us know what your prof. was thinking about in the end.
|
|
#
?
Jan 28, 2013 21:51
|
|
|
Star War Sex Parrot posted:Final release of Xcode 4.6 and iOS 6.1 are out. Woop woop. I was wondering if this was coming after last night's awkward "oh, we forgot to increment the beta and now your 6.1 devices are bricked" deal. ( My poor iPad mini  )
|
|
#
?
Jan 28, 2013 22:17
|
|
|
|
| # ? May 16, 2024 00:46 |
|
|
Wait what? Your Mini is bricked?
|
|
#
?
Jan 28, 2013 22:21
|
|