I have an app where it will be a setting whether or not to allow the screen to auto-lock during idle periods.
My question: what's the user-friendly (and user-understandable) way to present the option. It'll be in a UITableView with a UISwitch, so i'll look somewhat like:
What's the best language to use?
Keep screen on
Prevent auto-lock
Is there a common-practice to adhere to?
Something else?
I certainly like "Disable Auto-Lock" with a UISwitch, like you have in your screenshot. I've seen this used in a number of apps, and it makes sense to me.
Related
I want to make Switch, which have three states.Basically I need to store value 0 or 1 or 2.
By checking the state of Switch.
Please Help to make this switch.If it can be made Using IB that will be very nice because it will be easy to place in the right place.
(I have image but not able to show bec am new, dont have 10 reputation yet)
Thanks in advance for your creative thinking
You should use a UISegmentedControl for this. It's part of the standard set of controls, Apple has taken care of accessibility support, and users will know what to do with it.
Making a custom control that looks like UISwitch but behaves differently is a bad idea.
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.
Maybe this can solve out the ugly delay with touchesBegan: to touchesMoved:. It is caused artifically by iPhone OS to check if the user really wants to move. In some situations the finger must be tracked without delay, otherwise it just looks ugly. You see that everywhere through iPhone OS. Sliders, Scroll Views.
Maybe accelerating the system time makes the delay smaller.
You can set UIScrollView:delaysContentTouches to be NO, which will solve this.
You really don't want to change the system time to hack out something like this. Do you want apps you're using to screw up your calendar and alarms and your phone log, etc?
I asked a similar question, still open.
I don't think there's a way around it for now, seeing as even the ultra lickable "slide to unlock" slider suffers from the problem.
At this point I think the only solution is try smoothing this initial bump out with a bit of position interpolation.
I just used UIAlertView to show "loading..." with a progress bar showing how much data my app is loading so far. And as the HIG says, I'm doubt Apple reviewers will approve that action. Since the alert is not supposed to "alert" users when things are going on normally.
So, if I override it with a custom background, would the Apple reviewers still reject it? My code is something like this:
#interface MyCustomAlert : UIAlertView {
UILabel *alertTextLabel;
UIImage *backgroundImage;
}
I dont believe they will. I added a couple of text boxes and had no problem with multiple submissions.
While it's probably not the most ideal solution, I also think they'll allow it. If they don't, you can cite their own iPhone commercial http://www.apple.com/iphone/gallery/ads/#office-large as having something nearly identical (if I'm understanding you correctly) in one of the feature applications (skip to 15 seconds into that "Office" iPhone commercial).
I dont think they will reject it for that, you can argue that the the dialog is used to "alert" the person of the progress of what the app is doing. Only way youll find out for sure though is when you submit the app, i would recommend to have a backup plan just in case, but I think it will be ok.