Is there a way to programmatically tap a key, just as a user would so the key pop up animation takes place?
Yes, it's possible but a good amount of work. It depends what your goal is.
UISpec is a good place to start looking. If you are interested in simulating clicks for testing purposes, then you can just use the library. Otherwise, it would contain the source and pointers to how you can do it yourself.
Related
I'm looking to implement a UIPickerView where the user presses spin and the picker selects a random option. I'm curious if there are any ways to make the spinning effect last longer?
The only way I've really thought of, or seen, is increasing the number of items in the component simulating that the picker is really "spinning". Is this my only option?
Thanks.
You may test the actual performance with the huge number UIPickerView first, or actually build a slot machine component like this one:
iPadSlotMachine
With the stock iOS controller, no, I do not believe this is really possible.
Your idea might work, but will probably suffer from some graphical glitches as you add/remove elements during animation. Definitely worth trying though, to see if it is good enough for your needs.
Unfortunately, I think you'd have to write your own custom controller to really get the "slot machine" effect you're after properly. I would suggest google around and checking github, etc to see if anyone has written an open source one.
Is pinch for font size changes in tableview ok re usability?
Seems a good idea from my perspective, but wondering would users find it ok, or does it break an iPhone best practice?
I read through the tableView human interface guidelines and didn't see anything explicit there. In the Direct Manipulation section it says:
people can use the pinch gestures to directly expand or contract an area of content
If the user is using a pinch and zoom to change all text in a tableview it doesn't really seem to me like it is really proper "direct manipulation." It seems like it is more of a global setting change with a generic gesture. I think the real decision would come down to why are you planning to offer this gesture to the user? Is there a common use case for your app that the user would want to adjust the font size often? Are they going to change it more than once per session?
I know it is nice to offer lots of features, but any extra features are just going to obfuscate the real features. It may confuse the user if they accidentally do a pinch and then the text size is changed and they don't make the connection.
Overral, I don't think it breaks and explicit rule, but I would be really careful about deciding to add this "feature." If there is a really good reason to do it, I would say go for it, otherwise, it probably isn't worth the risk of getting rejected from the store and/or possibly confusing the user.
I vote no if it's key to the functionality of your app. You're having to train people to do something that may not be intuitive for them to realize that's there. If you look that the Twitter official app, they do something similar to expand the content in that cell, but you could totally live without that capability if you didn't know it was there.
Is there a best practice or common pattern for allowing users to select a precise location on a map using MapKit?
I've seen examples where a user can enter an address in a search box. But what about the case where a user doesn't know the exact address and wants to select a location from the map?
It's a bit more complex task than it seems.
Here is the guide how to detect single taps on a Web View.
I've used the same pattern to detect single taps on Map View but allowing zooming and dragging at the same time.
Hope it helps.
I would say that replicating the Maps application is close to a best practice for map applications.
You can test it for yourself; tap and hold somewhere on the map and a pin that you can move around by dragging will be dropped where you held your finger.
The Google Maps app seems to tackle what is a reasonable idea by touching the map by instead allowing you to drop a pin on the map; the SO post might help out.
I want to make a little in-app demo like Tapbots does in Convertbot. Maybe there is a better solution than mine?
make everything programmatically controlable
write a huge class with hundreds of performSelector:withObject:afterDelay: calls to control the whole app for the demo
The demo actually only does two things:
Simulate touches on controls (i.e. programmatically pressing buttons)
Show text message bubbles when appropriate to explain what is going on
How would you do it?
I don't think there is an easy way to accomplish this.
My suggestion would be to create a class that runs a script of actions for you. The script itself could be as simple as an NSArray of objects representing steps in the demo, each with values such as text for a callout bubble, an action/target pairing (for calling selectors), delay, and so forth. Use NSButton setHighlighted: to simulate button presses. Your class then runs through the array of steps to conduct the demo. You could code this directly, or construct the script at runtime from a YAML file (or other file format that you find easy to edit).
I would expect that investing some time in a mechanism like this will make your life a lot easier when it comes time to a) write and b) fine tune your demo, particularly down the road when you want to add features. You don't want to be managing a huge list of hardcoded calls. And you might even be able to re-use the demo-running code on other projects.
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!