If it is a hack or I am doing right? ( Custom UIAlertView )

Question

Hi all,

I have asked a similar question here and got some answers, so first of all sorry for making you people bother once again.

But I have an argument this time. First I will show my piece of code

- (void) showTheAlert{
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Hey!" message:@"?" delegate:self cancelButtonTitle:nil otherButtonTitles:@"Yes",@"No",@"Don't know eaxactly.",nil];
    [alertView setTag:101];
    [alertView show];
}

- (void)willPresentAlertView:(UIAlertView *)alertView{
    if(alertView.tag == 101){
        [[[alertView subviews] objectAtIndex:2] setBackgroundColor:[UIColor colorWithRed:0.5 green:0.0f blue:0.0f alpha:0.5f]];
        [[[alertView subviews] objectAtIndex:3] setBackgroundColor:[UIColor colorWithRed:0.0 green:0.5f blue:0.0f alpha:0.5f]];
    }

}

and my final alert looks like Now my confusion is that, [alertView subviews] is not documented as some people may say but alertview is a subclass of UIView, which has a property called subviews.

So I am using the documented property of a superclass which is definitely allowed.

So if this alertview may cause rejection of my app or not? ( I don't think apple will have any base to say I am using the undocumented or a private api. The look and feel is also alike to alertview.)

Guys please help me out.

And sorry for bothering you people for a similar question.

Thanks,

Madhup

Answer 1

I'm fairly sure altering UIAlertView by digging through the view hierarchy is a no-no. Firstly because it "uses standard iPhone screen images in a non-standard way, potentially resulting in user confusion", and secondly because if they change the view hierarchy your app is broken.

I might be wrong, I've never tried to get something like this onto the store, but my gut says don't risk it.

You can get a red button using a standard UIActionSheet, can you not?

Answer 2

Apples iPhone Human Interface Guidelines about alert views clearly states:

The infrequency with which alerts appear helps users take them seriously. Be sure to > minimize the number of alerts your application displays and ensure that each one offers > critical information and useful choices. In general, try to avoid creating alerts that:

• Update users on tasks that are progressing normally. Instead, consider using a progress view or an activity indicator to provide progress-related feedback to users (these controls are described in “Progress Views” and “Activity Indicators”).

• Ask for confirmation of user-initiated actions.To get confirmation for an action the user initiated, even a potentially risky action such as deleting a contact, you should use an action sheet (described next in “Using Action Sheets”).

• Inform users of errors or problems about which they can do nothing. Although it might be necessary to use an alert to tell users about a critical problem they can’t fix, it’s better to integrate such information into the user interface, if possible. For example, instead of telling users every time a server connection fails, display the time of the last successful connection.

So, my advice, the time waiting for a potential rejection isn't worth your time. Don't risk it.

Answer 3

To follow on Henrik's reply, in the iPhone Human Interface Guidelines section "Designing an Alert", they say the following:

Although you can choose the number of buttons to place in an alert, a two-button alert is often the most useful, because it is easiest for users to choose between two alternatives. It is rarely a good idea to display an alert with a single button because such an alert cannot give users any control over the situation; instead, it can only display information and provide a dismiss button. An alert that contains three or more buttons is significantly more complex than a two-button alert, and should be avoided if possible. In fact, if you find that you need to offer users more than two choices, you should consider using an action sheet instead (see “Using Action Sheets” and “Designing an Action Sheet” for more information on this type of view).

Because users sometimes respond to alerts without reading them carefully, be sure to provide an appropriate default choice. To help guide inattentive users towards this choice, make the light-colored, right-hand button the safe, default alternative. For example, you might choose to make this button the Cancel button, to help users avoid inadvertently causing a dangerous action, or you might make it represent the most common response, if the resulting action isn’t destructive.

The following guidelines describe how buttons are configured in an alert:

• In an alert with two buttons, the button on the left is always dark-colored and the button on the right is never dark-colored.

• In a two-button alert that proposes a potentially risky action, the button that cancels the action should be on the right and light-colored.

• In a two-button alert that proposes a benign action, the button that cancels the action should be on the left (and therefore dark-colored).

• In an alert with a single button, the button is light-colored.

You are clearly violating the guidelines in size, shape, number, and color of the buttons in your alert view (red has a very clear meaning as a destructive action, not a confirmation). Even if Apple doesn't reject your application in review (which they tend to do for clear violations of the Human Interface Guidelines), this would be extremely confusing to your users.

Also, navigating the hidden view hierarchy for any Apple-supplied user interface element is a very bad practice. The view hierarchies are undocumented, and do change often. Many of the applications that started crashing when people upgraded to iPhone OS 3.0 did so because those applications did something funky with subviews of UI elements, and those elements changed in the new OS version. Apple even specifically called this out in the iPhone OS 3.0 migration documents (which I can't find now).

Because of the problems this caused, they appear to have cracked down on this practice and have been rejecting applications because of it. Even if they don't, it shows contempt for your users if you do this, because it means that you don't care if your application breaks with future OS upgrade.