In my app, I have a button that triggers an action. However, I'd like to do the following instead.
If the user taps the button, then trigger tapAction.
If the user holds the button down for, say 1 second (getting a sense of the right length of time here would be great, too), then trigger holdAction instead.
Many standard apps seem to have this capability, so I'm certain it's possible. If you could point me to the right place in the documentation, that would be great.
Thanks.
The answer to this question should cover it. The question talks about UITableViews but the method is the same for any UIView :)
You should take a look at UIGestureRecognizers to see what else is out there.
Related
Does anyone know how CNN is doing their top pull down menu?
It looks like a UITableView that is called with a touch drag event but wasn't sure. Googled various keywords but was not able to turn anything up. Just looking for some guidance on how to replicate this behavior.
I've no idea how it's actually done, but I know how I would do it: any view can sit completely or partially offscreen and be dragged onscreen by the user in the usual ways (e.g. a swipe or pan gesture recognizer). There's nothing special about that.
I guess they are doing something like https://github.com/mikefrederick/MFSideMenu
You have to customize "MFSideMenu" a lot though. If you dont want to show this menu on every view you need to disable UIGestureRecognizerDelegate on that view.
There is also something like https://www.cocoacontrols.com/controls/pullableview but you may need to add UIGestureRecognizer to this class.
How do you setup in your application to show little bubbles with text and block the rest of the screen from being used and only allow a small section / button to be pressed. I am wanting to create a walkthrough to show users how to use the application and where to find things within the application when it is opened for the first time.
I would like to dim the rest of the application except for the part I want them to click on. Is there a framework already with these features?
There's no frameworks that provide this functionality, as far as I know.
One way you could do this though is to have a set of overlay images which you overlay over the whole screen the first time the user goes to that screen. To determine if the user has already been to a screen, I suggest you look at NSUserDefaults. To create the overlay images, I'd make the image the full size of the screen (i.e. 460x320 if you are showing the status bar) and then have transparent sections where you want to "see through" to the element below. Add a gesture recogniser to the overlaid image view to detect a tap and then hide the image and set the flag in NSUserDefaults to make it not happen the next time the user goes to that screen.
If you don't get a better answer, you could look at MAAttachedWindow on the page at this link. It's written for Cocoa, not Cocoa Touch, so you would have to convert it. I am considering doing this myself. You might find it to be worth the trouble, but I haven't looked at every detail, yet, so I couldn't say for sure. There are only tow files that are involved (.m and .h).
I realized that people have been implementing their own UIButton derivates to create radio buttons on iPhone, as this blog post shows.
This question's accepted answer states you can use Picker Views or Grouped Table views with a check mark, but it seems like a poor man's solution to me. Hence, my question: what is Apple's likely reasoning?
Are radio buttons a bad UI solution for touch interfaces?
Is it so rarely used that it's not worth cluttering IB with?
Another reason I don't quite see, maybe? I believe it's important to find this out, because if Apple thinks radio buttons suck, I'd rather not use them, and rethink my interface whenever I "believe" I should use one...
Radio buttons are a bad UI solution if they are poorly implemented. i.e. too small to reliably work with touches - which is why it's usually better to either use a toolbar or segmented control of options or a tableview of options.
Actually seeing it with a different angle, Apple has neither provided Radio buttons or even Check Box and maybe not because they think that it is a bad UI solution. But instead they've empowered the UIButton control very much that we can configure it as a Radio button or a check box or a switch or anything else with few lines of code.
A UIButton object can be configured and designed in various ways. We've seen various apps using the UIButton very creatively. I personally like the versatility of UIButton rather than Apple directly providing the radio button and Check box to drag and drop it in the interface.
When I've learned that I have to write some code to make the iphone keyboard go away. I was quite surprised. I was surprised even more when it become apperent that it is just the top of the iceberg.
What are the expected UI behaviors that aren't provided by system OOTB?
Is the list below complete?
The expected UI behaviors:
Focusing next text field when [done] is hit
Hiding the keyboard when background is hit
Using Touch Up Inside to fire a button action. (To give user opportunity to change his/her mind)
Supporting the screen rotation.
Some of that is silly, but some of it has uses as well.
Focusing next text field when [done] is hit
Which field is "next"? If you have a large form with fields both next to and above/below each other, next might not be so obvious. Even if they are in some linear layout, the iPhone would have to work to figure out which one is next. Do you want to wrap around at the end of the form, or dismiss the keyboard, or submit the form?
Hiding the keyboard when background is hit
I mostly agree with you here, though there are a few cases where this is useless. For example, adding a new phone number in the contact app.
Using Touch Up Inside to fire a button action
This one I really don't get. I can only guess that it's designed to allow you to use buttons instead of the touchesBegan/Moved/Ended methods. I guess it could be useful, but I've never used anything but Touch Up Inside.
Supporting the screen rotation
Many apps just don't work in any other orientation, such as games. If you want to use rotation, you only have to add two lines of code assuming you've done your layout well.
I hope this helps explain some of the strangeness. Aside from the keyboard dismissal, I've never really found anything too annoying. The one thing I wish they supported was using the highlight state of UIButtons for the set state. It would be a quick and easy toggle button, but I've taken to screenshotting a highlighted button and using that for the background image of a selected button.
Want a rounded rectangular button that isn't white? Since that one uses a background image, you can't just click something somewhere that makes it the color of your choice. You have to create your own image or you could even use CSS (WTF!?) to do it.
Unfortunately, the iPhone SDK lacks a lot of helpful things one would think would just be there. However, many people have taken the time to write wrappers for many of these kinds of things to help facilitate development - a quick google search into the functionality you are expecting may turn up a lot of useful answers!
For example, you could make the keyboard go away when you tap outside of it by creating a new view when it appears, and placing that view behind any user-interactable views on the screen. When that new view is tapped, it will become first responder and cause the keyboard to slide away (because the UITextField is no longer first responder).
Such a thing could be easily implemented as a drop-in fix for pretty much anything you'd need it for with very little code.
Still should have been included in the SDK in the first place, though!
The Apple UI design guide suggests that a UIPageControl is ideal for presenting the top view of a utility app.
Would a paging view that appears at the 2nd or 3rd level down inside the main UINavigationController view trigger a fail during the App review process?
In my App I have inserted a 3 page view at the second navigation level down in my productivity style app. Each page presents a question and requires an answer that might by a multichoice tick or text box entry. The questions could be stacked vertically in a multi-section table but in my prototype flicking through the questions horizontally feels very natural.
However I have not seen an App store program that uses paging as I have.
I asked Apple a similar question recently and got back:
"Thank you for contacting the iPhone Developer Program. Apple is not able to provide pre-approval to developers for proposed application submissions."
In the end it really depends on the reviewer, the specifics of your app, full moon, etc.
Personally, I would simply try it. If the interface looks good and you think it will not confuse users, then just submit it.
Also, being rejected for stuff like that is not the end of the world. You just have to replace it with something similar. Happened to me once or twice. It is usually not a complete blocker.
Although you will probably not fail app review, I believe using a UIPageControl may be confusing to your users. As you pointed out, I can't think of any apps using the UIPageControl in this manner. The following quote from the iPhone Human Interface Guidelines is informative:
A page indicator gives users a quick
way to see how many views are open and
an indication of the order in which
they were opened; it does not help
users keep track of the steps they
took through a hierarchy of views.
Because the views in a utility
application tend to be peers of each
other, a page indicator is sufficient
to help users navigate through them. A
productivity application that displays
hierarchical information, on the other
hand, should offer navigation through
the elements in the navigation bar
(for more on this, see “Navigation
Bars”).
From your description of how this portion of your app is supposed to display, it doesn't sound like these pages with questions on them would be considered 'multiple views'. In addition, you probably want your users to answer each question sequentially and move on to the next. The UIPageControl is designed so that a user can switch between any of the views in any order they choose, not only in one direction.
This sounds much more like a hierarchical design, and this portion of your app would probably work a lot better if you used a navigation bar along with a UITableView. Requiring your users to answer a question by tapping a multichoice tick box, and then make them figure out that they need to swipe in a certain direction to get to the next question would not be obvious to a user, and could be much more intuitive. For example, as soon as the user selects a tick box, you could just programmatically navigate to the next question. Or, have a button at the bottom of each screen that's labelled "Next Question", which would transition to the next screen.
Hope this helps!