In an iOS app written with Objective C, when Voice Over is on, The cancel button on the top-left and the save button on the top-right, those two buttons are in the same top bar on the view, now the order is cancel->save->other views on the page. But I need to actually traverse and edit all other elements before I can save, so I need to set the traverse order as cancel ->all other view->save button.
I saw some solutions that create new views to group elements or reorder accessibilityElementOrders. But I am just changing one button, is there an easy way like android:accessibilityTraversalAfter in Objective C?
It is rarely a good idea to modify the order of elements on the screen, especially in iOS. VoiceOver is used by people of many different abilities, including partially-sighted people, who would be confused about why the order doesn’t match the display. And even those who are completely blind will expect to interact with your app in the way other apps work. It’s a very common pattern to have buttons at the top when you can skip the action, but at the bottom if you have to do something with the content first. As much as possible, you should follow those conventions so users won’t be surprised at how your app behaves (a bigger issue for users of AX tools, since recovering can be much more challenging).
The way VO works is by creating a parallel object hierarchy and traversing that using a few simple rules like geometric order. So no, if you insist on modifying the order of the buttons, you will have to modify that hierarchy which means something like modifying accessibilityElements.
Related
I am making modifications to an existing iPad application, and I'm having a hard time dealing with really messy scenes in storyboards. Almost every scene in the app consists of multiple views laid one on top of the other, each containing a different set of controls. Depending on the situation or data coming into the scene, some views are hidden, and others are shown.
It takes a LOT of time to decipher such scenes, and even when I figure out what changes I need to make it's terribly difficult to make those changes, and easy to screw up other things.
As an example, the following scene has 3 views that could appear (Start View, End View, Drawer History), depending on the situation, and they are all laid out on top of each other...
This seems like a terrible way to handle this, and I'm having a hard time believing this is standard practice, but I'm not finding much in the way of alternatives. I find very little in the way of questions where people are dealing with this problem, and the tutorials on how to design user interfaces seem to be too simplistic and never deal with scenes that are complex enough to run into this problem.
Unfortunately, this app is my primary introduction to doing user interfaces in iOS, so it has apparently become the default solution in my head. I've tried many tutorials, but they take a long time and don't seem to ever get to a situation that needs such a technique to solve it.
I would hope there would be a solution where each alternate view in the scene could be laid out on its own, and be made to appear within a placeholder view as needed.
What would be a more enlightened / more manageable approach?
That's what you'll get with Storyboards/Nibs/Xibs. I'm not saying coding your UI is better than using interface builder, but it is, at least for me. I believe, as far as I know, there's no other way to handle such multiple layers of views in one view controller in interface builder. I actually used to use interface builder before and that's how I add multiple layers of controls too. Sometimes some views are initially made hidden, but that would probably confused me or the other developer looking at the layout. Sometimes I extend the viewcontroller height to know that there's a view container with a constraint a thousand constant or a negative thousand constant to make it hidden and ready to animate when it's needed to be shown.
There are ways to somehow improve and organize your Storyboards. You can separate modules into different storyboard files; you can use references; avoid segues; and whatnot. It's still an individual or team's preferences.
Some ref:
https://cocoacasts.com/organizing-storyboards-with-storyboard-references
https://medium.com/#stasost/xcode-a-better-way-to-deal-with-storyboards-8b6a8b504c06
EDIT:
I'm thinking you could also layout separate view containers into a separate xibs, and then call them or layout them when needed. But that would add more files to your project.
I am working on a bowling scoring app and am having a tough time figuring out what UI classes and controls to use for the paradigm I want. Here's the ideal:
I want to draw on an ipad (in landscape) a bowling scoresheet exactly like the oldstyle paper you see in a bowling alley with the 11 boxes for each scorer. I want to be able to input scores by touch the boxes etc, be able to print an old school bowling scoresheet (with the lines etc) at the end, and have the app essentially be what I call "hot paper". I want a full scoring sheet for 5 bowlers for example inside appropriate scroll controls so an olde phart using it can pinch or swipe to move around the paper to input scores.
This is targeted at olde pharts exclusively and they want it to act like paper. While I have written simple apps with TableViews and the like, I am not sure whether to use a Collection, Grid, or what, and what is the right way to draw so that I can send the completed "paper" scoresheet to a printer.
I am looking for some iOS genius who can recommend simply what classes I should be using for the elements - for example each row of the score sheet etc. Also shwhat elements should I use storyboards for and what should I do programmatically? I am quite storyboard challenged and usually do everything programmatically - I amgreat with making things work but awful on making them pretty.
I assume you want something like this:
Personally, I would draw/construct it entirely in code, as it so straightforwardly geometrical and repetitive. Just think of it as a hierarchy of views, each of which is itself a class that knows how to draw/construct itself. For example, MyFrameView is the box for one frame, which might or might not be the tenth frame. Then MyPlayerRowView simply gives itself ten MyFrameViews horizontally, and MySheetView gives itself five MyPlayerRowViews vertically. And presto, just three self-drawing classes so far and yet we've constructed almost the entire grid.
The only question is the underlying interactive interface. How should information be entered? What is the user to be allowed to do? That is a problem for you to solve. For example, should a MyFrameView just contain a UITextField? Or do you want the user to tap it and have some sort of "enter score" interface pop up? Those are the sorts of things you'll have to think about; in the latter case, you'll use a gesture recognizer to detect the tap and respond accordingly.
I'm starting a new project and I have some doubts about storyboard good practices, specifically about optional hidden views (show only under certain circumstances).
Let's say you have an pdf downloader app, when the user select a download button a UIProgress bar appears and show the download progress. Should this progress bar be included in the storyboard or generated programmatically when the user press the download button?
It's a simple example but what about if there isn't only a UIProgressBar but also multiple hidden (optional) buttons? What if some of the buttons are overlapped? (I know overlapped button is bad design but just for the purpose of exemplify)
Should this ones be hidden or added programmatically? What about performance? Some say it takes more time to parse a Storyboard/Xib than a programmatically build view.
In DonaldKnuth's paper "Structured Programming With GoTo Statements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
So, you are trying to solve a performance problem you do not really have (at the moment).
You decision to have a view permanently or temporarily should be based on context of the view usage, not some hearsay performance issues between xib/stb vs programmatic approach, that resembles platform-wars, but otherwise, given how LLVM compiler works today, and what the HW performance of iPhone 4 or higher is, is basically nonsense.
Here's a simple rule. Have all the views in IB, hide or unhide them as necessary, and add/remove a view programatically only if you can give a good reason why.
I understand you instinctive desire to make it right, so instead of trying to manage one milion views in one controller, take a look at the problem that is satirically called Massive View Controller.
Proper decomposition into custom views, separation of concerns, clearly defined responsibilities split into more view controllers, view controller containment, is the answer to to address your concerns.
You want your app first and foremost to work correctly.That you can achieve by having a sound architecture so that you will be able to stay in control. Users will not appreciate that you instantiated some button programatically, because they couldn't care less. But if the app has inconsistent state because your view controller has 7000 lines and is spaghetti hell or is crashing, that is a problem.
if you are planning to use storyboards; would suggest to have view/buttons etc included . you can always hide / unhide the same from the code.
have a thought process and not cluster your view. Have multiple views and make your app look neat
This values get from web servies. Totally i want to show 4 layer to display[i show here only 2 layer]. some times in web servies values are come more means the layer become big and show the values.same and anther 3 layers are displayed. help me..!
Use UIScrollView or Freeform make it independent means don't use static value make it dynamic whatever number of layers you are getting from server and according to that adjust content size of UIScrollView.
First of all. This view (and design) doesn't really follow any iOS consistency. The Apple human interface guidelines are there to help you with finding the correct way to do something.
Right...
Do you need to show all the options at the same time? i.e. do you need all four "layers" on the screen at the same time? If so, why? What is the user supposed to do with this screen?
Is the user selecting one option from each layer? Multiple options from each layer? etc...
With either of these I would go down the route of using a navigation controller with a single UITableViewController to display each layer.
So, the user gets a nice list of options...
dumbell
E-Zbar
cable
barbel
...
And selects one (or many) of them.
Then the second "layer" is pushed onto the navigation stack and the user gets another nice list...
incline
decline
close-grip
rotating
...
This way the user has to only concentrate on one task and each list is deployed nicely and readably for them.
If I was a user and was presented with a big list of buttons like your design I wouldn't know what I was supposed to do.
Im trying to do app with a card based ui, kind of like Jelly. I was wondering the how this would be done. Im thinking by using a collection view but Im not sure. Are there any open source libraries that would make it easier to do this? Thanks.
You're probably not going to be able to accomplish this using out-of-the-box components. I don't think UICollectionView is going to get you very far. You will almost certainly need to roll your own.
I would start by creating a View Controller class for the "cards", instantiate a few of them, add the views as subviews to the main view, and get to the point where you can comfortably push these cards around with your fingers. You will want to read up on animating UIViews, and UIGestureRecognizers. Make sure the momentum is right. Apps like this really really demand highly-tuned physics, otherwise they'll feel awkward.
Once you get to the point where your cards are happily zipping around the screen, it's just a matter of getting them to "sink" into a couple pre-defined positions (focused front-and-center, and resting in a stack down below). You would probably also want to give your view controllers some sort of state that indicates whether they're "active", or not.
Easier said than done, obviously.