I have a UITableView with about 10 subviews. Some of the subviews are acting strangely in a few older iOS versions. I'd like to determine where the various subviews are being added to the tableView. What's the best way to do this?
Perhaps I can attach a callback to the tableView such that it's called whenever a subview is added?
This doesn't sound like a good plan to me at least but a question is a question.
What you could do is observe the subviews property(NSArray) for changes, receive the callback and handle your case.
Again, if that's a good idea (looking at it form an architectural perspective) is a totally different question.
Edit: Sorry I think I misread, if you only want to figure out when what happens, ...guess you can do what I described above.... Or breakpoint into the drawing/layout methods. Either way.
Related
I'd really like to do something similar to Tinder's "pile of cards" interface, but with a UICollectionView.
I would assume that if you need the other cells to dynamically move given the cell you are interacting with, one would be in Edit Mode on a UICollectionView, but I'm not sure.
Please don't reply with specific Cocoapods that do this and "why don't I just use those?"; it goes beyond just that. I have all sorts of content, and this is just one of the layouts / presentation types I need. Sometimes it's a grid. A lot of the controller actions are the same; just the display and interaction is different.
That said, please DO refer me to any code that may already do this, that I could use as a starting point.
Otherwise, I would be grateful to know where I would get started. I'm thinking maybe one of those projects that re-creates Springboard with a collection view??
EDIT: I was looking for something like a card stack, but not like Tinder in that you can interact with the top card before swiping or letting it return. In the end what I was trying to accomplish was similar to the old iPod-style 'Cover Flow' view.
I'll try to answer my own post. I made a few incorrect assumptions. In the end it was a lot less complex than I thought.
To get a collection view whose layout isn't just 'static within a scrollview' but changes dynamically with the contentOffset property, you need to subclass UICollectionViewLayout and make sure first of all you return YES for - (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds
from there, most of your heavy lifting will be done in the - (void)prepareLayout method.
I basically used the following tutorial as a starting point and kind of followed what they were trying to do (or just downloaded the final project and saw how they did it, and mimicked the same effect), but obviously had a different prepareLayout method:
Ray Wenderlich
Is the iOS 7 Apple Mail app is using a UITableview for the composing and viewing message screens? If so, why?
The composition screen appears to be using a UITableView with a UITextfield for the subject row and a UITextView for the message row. What is the benefit? There aren't any table rows similar enough to be reused (Max is 6 if you include cc and bcc), so I don't see a performance benefit. There is no Edit mode (i.e. move, delete rows) on these two screens. The resizing table rows necessary to accommodate long messages seems like an unnecessary headache.
I'm working on an app with a similar text input layout and number of fields. I initially planned to use a UIViewController with UITextField and UITextView placed on a UIScrollView. Examining the Mail app, I'm assuming there's a reason Apple would use a UITableView. Though I don't see what it is.
Insight appreciated.
Table views are REALLY good at a few things, and one of those things is creating forms. All you really need to do is add the fields to the cells and do a little cell customization, and the table view handles all the spacing, formatting, rotation, scrolling, etc.
I built an open source iOS form building library that is build on top of UITableView for just these reasons. (https://github.com/mamaral/MAFormViewController) In my case, if you need to move around or add a new field to the form, it's as simple as updating the data source with a new form-field cell, as opposed to creating a totally new textField, configuring it, determining the frame, moving everything above and below it around accordingly, etc. I would suspect these reasons are similar to why Apple would use table views for forms like the above.
The class chain is:
NSObject - everything subclasses this. you have to be really crazy to not subclass it
UIResponder - anything that responds to user input should be a subclass of this. the message view responds to user input
UIView - anything that draws to the screen should subclass this. the message view draws to the screen
UIScrollView - anything that scrolls should subclass this (note: that's not how it works on OS X! Only on iOS!). The message view scrolls, so it needs to subclass UIScrollView
UITableView - anything that has rows of data should subclass this. The message view has four rows, so it should subclass it.
Basically, it subclasses UITableView because it needs all of UITableView's functionality. So why not subclass it? You are saving yourself thousands of lines of code by doing so.
Duplicating all of UITableView's functionality is very difficult.
Chances are if you write an app without subclassing UITableView, it will be so sucky Apple might even reject it from the store, telling you to go back and make it work properly. Which would mean subclassing UITableView or else writing thousands of lines of code — for example Voice Over is a huge pain in the ass if you don't subclass UITableView.
If you don't want to restrict yourself to rows of data, consider using a Collection View.
I'd like to implement a feed in iOS 7 that is only pulling new data if it appears the user has a chance of viewing it. I know UITableView is a subclass of UIScrollView that does this well, but I can't get the cells to behave the way I'd like - I'd like it to look similar to facebook or twitter's newsfeed where you can reload by pulling down and load more by hitting the bottom.
I've seen other questions such as this but I'm looking for vertical scrolling only, with absolutely no horizontal movement. I'd like to use a method calling (for example) nextTenPostsFromIndex: that instantiates from zero, and applies to whatever index was the last on the screen if hitting the bottom.
My question: Is the best way to go about this to create a UIScrollView, place a subview inside of it, and programmatically space them on the available scrollview space, and apply the same drawing methods again with repopulated data if nextTenPostsFromIndex is called or checkForNewPosts (if pulling down from the top)? Would this be a reasonable way to implement Facebook's iOS7 newsfeed, or others like it?
Short answer: No. You really ought to use UITableView for things like this. You can use a custom cell or whatever you want. If it helps you, also know that since UITableView is a subclass of UIScrollView, you can do anything you would normally do with a scrollview, including assigning a delegate which acts based on the current position when scrolling.
I have a UITableView displaying a table of data with a somewhat large contentInset value. As a result, the user cannot trigger the UIRefreshControl because it expects them to scroll too far.
Basically, I'm wondering if it's possible to make UIRefreshControl adjust for contentInset values.
Edit: This question is mostly about curiosity, so I removed the extra details and rephrased the question to be more direct.
I think you're going about this a bit wrong. If you've encountered this issue because of the mechanism you've created to preload cells, you should think of a different approach for preloading them. If there's any content to be rendered / loaded / downloaded, you could be doing this in a background thread and leave a minimal amount of work for cellForRowAtIndexPath. If you insist on keeping this implementation, I'd suggest looking up a custom refresh control as there is no way to customize the build in UIRefreshControl in terms of content offset for refresh (AKA sensitivity). I believe this is ultimately a good thing - there should be consistent user experience across apps running on iOS which use a refresh control.
this is the situation:
I need horizontal scrolling, and table views inside every page. This is something like news app, it should display news from different categories, when scrolled in one horizontal direction, and inside one category it should display about 30 news, vertically scrollable, of course.
I have successfully done what i need, but...
I have following scenario:
UINavigationController
|__ UIViewController, which contains ScrollView and PageControl
|__ UITableViewController, which holds data in rows, and is displayed inside parent, which is actually ScollView
I know that this is not an ideal solution, but at least it works. As a base, i used Apple's code and tutorial for PageScroll found on this link. Instead of simple viewController to add to ScrollView, i used TableViewController, so basically i add tableController.tableView to the ScrollView.
I know, also, that adding tableViews inside scrollview is sort of adding a car inside a truck and driving that car, but i couldn't find more reasonable way of doing same thing.
So, i need your thoughts about how this can be accomplished using some other approach. I use storyboarding and iOS 5 for this, and everything seems (and looks) messy right now.
Thanks in advance, a lot.
I did something similar a few months ago, and it was like this:
UINavigationController
UIViewController with a UIScrollView
UIViewController with a UITableView inside (I use this because I simply hate UITablewViewController)
I followed the Apple's documentation about creating custom containers. There is a great video about that in the WWDC 2011 video's section if I am not mistaken. I can proudly say that the code is really clean and simple to understand.
Answer 1.0
The one thing is, did you managed to get proper orientation handling of the tableView, without any hack, or you don't use it?
No, in this case I didn't, but I am sure I would have been able to do it without any problem. You see, most of the problems come when you just [self.view addSubView:newViewController.view];. You just add the UIView, all the logic of the rotation is handled by the newViewController and not in the controller where the UIView will be.
The other thing is, if i'm gonna try to implement, say, GridView or something like that, for iPad, orientation handling and animations become very ugly.
I implemented this in another project and it was quite easy to implement once you understand what's going on:
I used a UIViewController with a UITableView so I could get all the goodies from the dequeueReusableCellWithIdentifier:, creation of section's titles, table's headers and footers, etc. I just figure that no matter what I would do with a UIScrollView a UITableView is always going to be more optimized. As the UITableViewCell's I just used an holder with 3 squares, each one being a picture. (my application was a showcase of pictures)
http://www.raywenderlich.com/4680/how-to-make-an-interface-with-horizontal-tables-like-the-pulse-news-app-part-1
Chk out above link