I have a screen in my app that consists of a UITableView with another opaque view overhanging on the top (which is also interactive). The content offset is set correctly such that the entire tableView is visible to a sighted user.
However, when using VoiceOver and paging up/down with three fingers the default scroll distance will place part of the tableView under the overhanging view, and thus prevent VoiceOver from reading part of the tableView[1].
Is there any way to change how tall a "page" is when using VoiceOver?
[1]: I know that there are still ways to cycle through all the elements, etc, but it's far easier and more discoverable for partially sighted users to skim over elements with their finger.
I think you are looking for this: https://developer.apple.com/library/prerelease/ios/documentation/UIKit/Reference/UIAccessibilityAction_Protocol/index.html#//apple_ref/occ/instm/NSObject/accessibilityScroll:
Re implement that method and scroll the amount of pixels you require instead of a whole page
Related
My use-case is like this:
The user defined some tags (text like "#asdf", "#qwerty", "#let_me_think_about_it" and "#decide later"). I want to display these in a box without scrolling (and don't know, how many tags the user created until I display the box).
The box itself should not be scrollable at all but be shown in a UITableViewCell (which is being scrolled). So it must compute the proposed height and respond to Autolayout mechanisms. If a (ARM) Mac user resizes the window to be smaller than before (or an iOS user rotates the device), the box should increase/decrease its height, as necessary (within the limits of Autolayout, since I know of some issues). Each of the tags should be (de)selectable at the same time (UILabel with UITapGestureRegognizer attachted?) and be able to displayed 'selected' (via a background view).
So, the box should primary try to align all content horizontal. If There's not enough horizontal space, do a "line break" and continue on the next "line".
My current solution is a UIScrollView that the user can scroll horizontal and tap any of the (UILabel) views. The displayed views itself are being loaded from a NIB file, like a UITableView does. The issue here is that not any of the selected tags might be visible at the first glance.
If there was no Autolayout, I'd exactly know what to do. But since there it is, I want to use Autolayout in my NIB files and wonder what you would do?
(How do you compute the required width of such a view and decide when a line break is to be done (and how?))
I think I need a simple hint. But if it needs code to explain, ObjC and Swift is both acceptable. :-)
So, the box should primary try to align all content horizontal. If There's not enough horizontal space, do a "line break" and continue on the next "line".
This sounds like a job for UICollectionView with UICollectionViewFlowLayout. You can disable scrolling, and the layout object will tell you the size of the content so that you can adjust the size of the box.
(How do you compute the required width of such a view and decide when a line break is to be done (and how?))
If you're doing it yourself, you add up the widths of all the items on the first line, and if it's larger than the available space, you move the item that extends past the limit and any subsequent items to the next line. Repeat as needed. But that's exactly what a flow layout does for a collection view, so there's no need to roll your own.
I work on a app, nothing fancy, but since is my first app, there alot of stuff I never did before.
So, I'm trying to build a view like the image attached.
I've looked up on the Internet how to do something like that but I don't know what is better/cleaner way to do.
As you can see I have 3 areas: the title, the tableview in the middle and a button on the lower side.
The table will expand based on the content (3 lines or 30 lines) so the button must move down and a scroll bar should appear.
So, my idea:
Using a tableview having 3 static cells: one to put my title, second to put a tableview having prototypes cells, and a third one for the button.
That way I would have a scroll bar when the table in the middle grows, pushing the button.
Here I have a question: how to have the table view (the inner tableview) resize itself, pushing the height of the middle row, instead of having a fixed width with a scroll.
Is the the best way to achieve that?
Thanks for any idea.
C.C.
Are you sure you want to push the bottom UI down as the table grows? You say whether the table has 3 or 30 cells, but what if it has 300 cells? Your user then has to scroll to the bottom to reach the button and tab bar. I think you'll find that it would be better to use Auto Layout and let the table fill the screen space between the title and the button. The table will scroll so if you have 300 cells then you can scroll through inside the table's available area.
The advantage here is you won't be fighting with Auto Layout. If your user rotates an iPhone 4S into landscape you'll only have a few rows displayed but conversely if they run in portrait on an iPad you'll fill all of that space.
As for how to do it, the other advantage is that you don't need the nested table you describe. Use a constraint to attach the title label to the top layout guide, then attach the tab bar to the bottom layout guide. Put a vertical space constraint between the button and the tab bar. Finally, put vertical space constraints between the table and the title & the table and the button. (You'll need to implement constraints for the horizontal axis as well, but that's pretty simple.)
There's are refinements you can put into place if you want the table to shrink to fit if there are only 3 rows, but this should get you started and you may not want that anyway.
Key point: the tableView wants to scroll naturally, inside a view sized to fit the display. Don't change that behavior unless you really have to. Neither your users nor UIKit expects what you're trying to do, and the table is going to fight you all the way about it.
Nesting UIScrollViews (which your nested table would do) works, but it opens up a lot of bad UI flow problems. In my experience every time somebody wants nested scrollViews there's some other approach which is more "natural" to iOS interface paradigms.
If you're dead set on the UI you described I wouldn't use a table for the outer structure. Just make it a UIScrollView and calculate your content size based on the number of rows the table will display. You can actually do that, and then use Auto Layout as I described.
I'm doing some UIAutomation testing using Xcode Instruments and have an issue accessing a staticText which I want to verify.
The situation:
I have some buttons that display different scroll views that contain multiple charts. These scroll views have 5+ items in each so when i initially do target.logElementTree() it only shows the visible ones. If i scroll down with window.scrollViews()[0].scrollDown() and again get a logElementTree() the bottom elements are shown however whenever i try to access them it keeps referring to the ones from the top of the scroll view.
Any ideas?
Cheers.
As per as my experience, whenever you do "taregt.logElementTree()", it will display you all the elements (visible & hidden or which are present even at the bottom of screen) which you can access by its name or index or position once scrolled down. But if you still face problem, I will recommend you to access the element by its position after scrolling down to make it visible.
I think it'd be a good start to take a look at the wireframe I'm implementing: http://imgur.com/J8Kgy
So this is a special table view, and the background image is much bigger than the table area. And what I want is to have the background scrollable and have the table stick to a specific position on the background, and the table moves together with the background.
EDIT: Besides, this position may change over some time.
I found it hard to do by extending UITableView since I didn't find the way to change the scrollable area and actually I didn't find how to access the view containing all the rows so I don't know how to position it.
Currently I'm doing this with a UITableView in a UIScrollView but I think that's a waste since UITableView is already a UIScrollView itself.
So anyone knows it's possible to change the scrollable area to the whole background and how to access the rows' container? Or it's not possible? If it's not possible it'd be easier to just make a simple list view by myself and get rid of UITableView I think.
Thanks!
Pine
I'm trying to create a kind of a "game mode" menu similar to the one used by the "Cut the Rope" game to select the level pack:
What I want in particular is to achieve the same effect of showing the "current item" (in this case, the "2. Fabric Box" item) plus a bit of the previous and following items (to make sure the user is aware that there are more modes available by scrolling), with pagination enabled (to make the scroll view automatically "center" on these items).
This seems like a natural job for a UIScrollView with pagination enabled, however from the documentation it seems the pagination occurs on multiples of the view bounds.
So: if pagination occurs on multiples of the view bounds, is there any way to achieve this effect with a UIScrollView?
The fact that we see the full width of the screen would suggest that the UIScrollView frame's width would be 320px in this case, but each individual item would need to be smaller than that in order to show that little bit of the previous and next items, thus messing up the pagination...
For your reference, you can see a sample implementation of a page control from here.
https://developer.apple.com/library/content/samplecode/PageControl/Introduction/Intro.html
For the implementation you want,
to your surprise, the scrollview's width is actually smaller than 320 (or 480). The magic property to set is:
scrollView.clipsToBounds = NO
The only problem with this implementation is that the scrollview get no touch events if the touch is outside the bounds of the scrollView. This can be fix by passing its parent hitTest event to scrollView.
Just to link to to a better explanation:
UIScrollView horizontal paging like Mobile Safari tabs
Slightly different from what I recommend but does the same thing.
Edit:
I have a small project called LXPagingViews that does the above, hopefully in an out of the box manner (Do drop me a pull request or feedback in issue): https://github.com/lxcid/LXPagingViews