I have a NavigationController that stacks UIViewcontrollers that have UITableView among other UI elmeents. The tables I use are actually custom tables that use custom cell views. With this arrangement those tables don't show scrollbars of any kind even though I have configured in IB the Shows Vertical Scrollers to show them.
I've tried several ways of debugging this without success. If I print to console the value of this property (showsVerticalScrollers), it prints 1, so the property is properly set, and no, my table is not wider than its parent view, actually it's way more narrow than its parent view.
Are there reasons why a table won't show it's scrolls?... btw, this happens in iOS5 running in simulator. I'm using xcode 4.2 with SLeopard. I don't have access to an iPad to test it in the hardware but other tables I have in the same project, show their scroll bars without a problem.
EDIT
thanks for the answer... I did one last test and found that one of the causes for not showing a scrollbar is the number of elements shown in the table, when they fit in it without the need to actually scroll. Say if you have a table with 1 row and the vertical size of the table is too big for just one row?, then iOS won't show the scrollbar when bouncing.
It's hard to provide a possible solution without seeing any code, but the advice I can offer is to update your code to the bare minimum needed code to implement a UITableView and see if scrolling works, if it does, add in functionality in small increments, testing the scrolling with each new code addition till you reach the point that scrolling breaks. Incremental testing in this fashion helps to avoid issues like this where you are unable to effectively debug your application.
Related
I have a UITableView with a search bar. The table can contain thousands of cells. Performance is fine, since only cells on-screen are actually fetched/rendered.
I'm trying to interact with the tableview using a UI Test, even trying to tap the search bar doesn't seem to work properly:
app.tables.searchFields["identifier"].tap()
Will cause the app to become unresponsive (100% CPU and ever-rising memory). When I do the exact same thing with only a small set of cells, it works just fine.
My guess is, some part the stack is fetching all the cells to query through.
Is there a way to prevent this?
Maybe it will help to use firstmatch
https://developer.apple.com/documentation/xctest/xcuielementtypequeryprovider/2902250-firstmatch
When you call firstMatch, XCTest stops traversing your app's accessibility hierarchy as soon as it finds a matching element, speeding up element query resolution.
Its also possible to use element(boundBy: Int):
https://developer.apple.com/documentation/xctest/xcuielementquery/1500842-element
I've got a fairly intricate IOS application with icons, tables, text fields, etc spanning across over 20 different view controllers. I built the entire application in portrait mode, and have of course realized that things look screwy when in landscape.
For the really simple screens I've had little issues using autolayout's constraints to accommodate any orientation changes. However, when there are multiple (5+) items on the screen I've found it incredibly hard to use constraints to manage everything. In fact some views look like they need the entire layout transformed to flow well.
Is there a better alternative to constraints? My only other thought is to make duplicate views, one for portrait and one for landscape. Then I can just switch on the deviceOrientationChange listener.
You can always switch off constraints by selecting the xib/storyboard file and unchecking Use Autolayout. To do this only for the more complicated views, I think breaking out into separate xibs is feasible.
Also, sometimes landscape really calls for a complete rearrangement of the view (or even adding / hiding certain elements). You should not shy away from defining separate views for this, with or without xib documents.
I'm an iOS developer looking for a solution to a tricky problem.
I need to create a grid view/ mosaic view to layout cells of different sizes (both width and height).
I basically need the functionality of a GMGridView, with horizontal scrolling/paging, the ability to edit, and drag cells to new locations, thus rearranging the entire grid view. I've looked at all of the current open source grid views out there, and found none with variable sized cells.
One solution I have thought about is 2 tableviews both rotated for the horizontal scrolling, and then intercept some UITableView scrolling methods, to then scroll the other tableview together. This is not ideal, as I will be unable to move a cell from one view to another, and I'm not sure how happy apple will be about it.
I also know of some possible (confidential?) support for this coming in the next version of iOS, but would like to keep my app supporting previous versions of iOS.
Thanks for any insight you can provide.
I realize this post is kind of old, but here is a list of relevant projects: *https://github.com/betzerra/MosaicUI
*https://github.com/betzerra/MosaicLayout
GridViews on iOS are a pain. Fortunately Apple is coming up with UICollectionViews that are optimized to build grids. This is coming in iOS6 and it's still under NDA so check out the documentation on Apple's website for more information.
The question you need to solve now is whether you want iOS5 retro-compatibility or not
I'm trying to workaround a long-running bug in Apple's SDK here, but I can't see how to achieve it without huge amounts of code.
Here's the bug:
Create a view.
Put another view inside it, with an origin ANYTHING except (0,0).
Configure the subview to resize to fill
...then, at runtime:
4. Set the superview size to zero
5. Set the superview back to ANY non-zero size
BANG! Apple's SDK goes haywire, resets the origin of the subviews, loses all ability to tell up from down, etc. (seems like the programmer "Forgot" to include a variable to record what the spring/strut-size was before it went to 0).
I've heard this bug has existed in OS X for 5 years or so, and Apple still hasn't fixed it. What I would like is some way (any way!) of working around it, without re-writing Apple's entire springs/struts system and implementing it properly, without the bug. Unfortunately, I can't even find the original references to the OS X bug that someone showed me previously.
EDIT:
...I have a resizing "drawer" at the bottom of the screen that has to shrink to small height. The problem is subviews "collapsing" all down to origin 0 (amongst other things) at the drop of a hat (technically: they're reducing their origin.height, but not re-increasing it).
The best solution I have found is to limit your minimum window size so that none of your views can ever hit zero size.
EDIT: an hour later, the collapsing behaviour has returned, without me touching the source files. I'll use source-control to double-check, but I believe all that happened is I added other files to a different part of the view-hierarchy and re-built. Argh!
(what follows SEEMED to work, but is now failing again, in the same way)
Hmm. So, I had two UIVC's on one screen. Refactoring so that I only had one made the resizing bug vanish. It seems to be a bug in the UIVC layout code.
NB: I had the idea this might be a problem because I know Apple currently advises you to only have one UIVC on screen at once with iPhone, even though this means you have to ignore their MVC architecture for complex apps. So, technically, they warn you away from this. But, at the same time, I'm now unable to use the MVC stuff for this code.
The following worked (for my current example - may not be universal!).
HOW:
If you're adding any UITableViewController instances ... give up. You'll have to re-implement that class yourself
Find my subviews that were in UIVC instances, and change the extended class in the UIVC header from "UIViewController" to "NSObject"
Move all code from viewDidLoad to init (remembering that "init" has special rules about first few lines etc)
Replace the instantiation of that UIVC from "[[vc alloc] initWithNibName:nil bundle:nil]" with a plain "[[vc alloc] init]"
Another potential workaround (that works in my current situation):
The only View I have right now that MUST have a non-zero origin and MUST resize-to-fit is a UITableView.
Apple has a special feature of letting you put any view as a "table-header".
So ... I've taken all my other components, stuck them in a large view, and made that the table-header view.
The downside is that they now scroll off the top when you scroll the table, but it allows me to give the table a zero-origin, working around the SDK bug.
In reference to my previous question, I would like to know how to implement a large grid of cells in an iPhone application.
I'm working on an interface which would be similar to an Excel spreadsheet, with many rows and columns. Do I have to handle each cell separately? How can I handle user interaction in each cell?
Is there a standard way to create this type of control?
There is no real standard mechanism.
If all of the cells in a given row will always fit in the width of the screen, one way to do it would be to create a UITableViewCell with several UILabels and vertical separators between them. If all of these rows had "columns" of the same width, you would get the appearance of a grid.
If that isn't possible, it might be helpful to think about what the table view control truly is. A table view is just a scroll view that automatically adds, removes, and recycles its subviews so that only the ones that are visible at a given time are in memory. There is no reason you could not write a GridView control that did the same thing, but in two dimensions. It wouldn't be as easy as using the built-in table view, of course, but if the table view can't do what you need, well, that's why Apple isn't writing all the apps.
Sounds like the exact thing that UICollectionView was made for!
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UICollectionView_class/Reference/Reference.html
Look at my answer to this question: MS Excel type spreadsheet creation using objective-c for iOS app.
Basically there's no standard way to do this. You will need to made everything by hand and there's 3 ways to go:
Use a UIWebView and layout everything using html/js.
Modify a UICollectionView.
Make everything by hand using Core Data.