Использует подпредставления в Alert без документов

Question

Я задал похожий вопрос здесь и получил несколько ответов, поэтому прежде всего извините за то, что вы, люди, снова беспокоитесь.

Но на этот раз у меня есть аргумент. Сначала я покажу свой кусок кода

- (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]];
    }

}

И мое последнее предупреждение выглядит как

Теперь я путаюсь с тем, что [alertView subviews] не задокументировано, как могут сказать некоторые люди, но alertview - это подкласс UIView, у которого есть свойство, называемое subviews.

Так что я использую документированное свойство суперкласса, которое определенно разрешено.

Так, может ли это предупреждение вызвать отклонение моего приложения или нет? (Я не думаю, что у яблока будет основание говорить, что я использую недокументированный или частный API. Внешний вид также похож на представление о предупреждении.)

Answer 1

Apple Руководство по интерфейсу пользователя iPhone о представлениях предупреждений четко гласит:

Частота появления предупреждений помогает пользователям относиться к ним серьезно. Обязательно> минимизируйте количество предупреждений, которые отображает ваше приложение, и убедитесь, что каждое из них предлагает> критическую информацию и полезные варианты. В общем, старайтесь избегать создания оповещений, которые :

• Обновление пользователей по задачам, которые прогрессирует нормально. Вместо этого рассмотрите возможность использования прогресса просмотр или индикатор активности обеспечить связанную с прогрессом обратную связь с пользователи (эти элементы управления описаны в «Прогрессах» и «Активности» Показатели»).

• Запросите подтверждение Действия, инициируемые пользователем. Чтобы получить подтверждение действия, инициированного пользователем, даже потенциально опасного действия, такого как удаление контакта, необходимо использовать лист действий (описанный далее в разделе «Использование листов действий»).

• Информирование пользователей об ошибках или проблемах о котором они ничего не могут сделать. Хотя может быть необходимо использовать оповещение, чтобы сообщить пользователям о критическая проблема, которую они не могут решить, это лучше интегрировать такую ​​информацию в пользовательский интерфейс, если это возможно. Например, вместо того, чтобы рассказывать пользователям каждый раз, когда соединение с сервером не удается, отображать время последнего успешное соединение.

Итак, мой совет, время ожидания потенциального отказа не стоит вашего времени. Не рискуйте.

Answer 2

Чтобы последовать ответу Хенрика, в разделе «Руководство по интерфейсу пользователя iPhone» «Разработка оповещения» говорят следующее:

Хотя вы можете выбрать количество кнопки для оповещения, двухкнопочное оповещение часто является наиболее полезно, потому что это проще всего для пользователям выбирать между двумя альтернативы. Это редко хорошая идея отображать предупреждение с одним кнопка, потому что такое предупреждение не может дать пользователям любой контроль над ситуация; вместо этого он может только отображать информацию и предоставлять кнопка отклонения предупреждение, которое содержит три или более кнопок значительно более сложный, чем двухкнопочное оповещение, и следует избегать, если это возможно. В Факт, если вы обнаружите, что вам нужно предложить пользователям более двух вариантов, вы следует рассмотреть возможность использования листа действий вместо этого (см. «Использование листов действий» и «Разработка листа действий» для более информация об этом виде просмотра).

Поскольку пользователи иногда отвечают на оповещения, не читая их внимательно, не забудьте предоставить соответствующий выбор по умолчанию. Чтобы помочь руководство невнимательные пользователи к этому выбору, сделать светлую, правую кнопка сейф, альтернатива по умолчанию. Например, вы можете сделать эта кнопка отмена, чтобы помочь пользователи избегают непреднамеренного опасное действие, или вы можете сделать это представляют наиболее распространенный ответ, если итоговое действие не разрушительный.

Следующие рекомендации описывают, как кнопки настроены в предупреждении:

• В предупреждении с двумя кнопками кнопка слева всегда темного цвета и кнопка на право никогда не бывает темным.

• В предупреждении с двумя кнопками, которое предлагает потенциально опасное действие, кнопка что отменяет действие должно быть на правый и светлый.

• В предупреждении с двумя кнопками, которое предлагает мягкое действие, кнопка, которая отменяет действие должно быть на слева (и, следовательно, темного цвета).

• В предупреждении с одной кнопкой кнопка светлая.

Вы явно нарушаете указания по размеру, форме, количеству и цвету кнопок в вашем окне предупреждений (красный цвет имеет очень четкое значение как разрушительное действие, а не подтверждение). Даже если Apple не отклонит ваше приложение на рассмотрении (что они, как правило, делают для явного нарушения Руководства по интерфейсу пользователя), это будет крайне запутанным для ваших пользователей.

Кроме того, навигация по скрытой иерархии представлений для любого предоставленного Apple элемента пользовательского интерфейса является очень плохой практикой. Иерархии представлений недокументированы и часто меняются. Многие из приложений, которые начали аварийно завершать работу, когда люди переходили на iPhone OS 3.0, делали это, потому что эти приложения делали что-то необычное с подпредставлениями элементов пользовательского интерфейса, и эти элементы изменились в новой версии ОС. Apple даже специально упомянула это в документах по миграции на iPhone OS 3.0 (которые я сейчас не могу найти).

Из-за проблем, которые это вызвало, они, похоже, подавили эту практику и отклоняли приложения из-за этого. Даже если они этого не делают, это показывает презрение к вашим пользователям, если вы делаете это, потому что это означает, что вам все равно, не сломается ли ваше приложение при будущем обновлении ОС.

Answer 3

Я вполне уверен, что изменение UIAlertView путем копания в иерархии представлений - нет-нет. Во-первых, потому что он "использует стандартные изображения на экране iPhone нестандартным способом, что может привести к путанице среди пользователей" , а во-вторых, потому что, если они изменяют иерархию представлений, ваше приложение нарушается.

Я могу ошибаться, я никогда не пытался получить что-то подобное в магазине, но моя интуиция говорит, что не рискуйте.

Вы можете получить красную кнопку, используя стандартный UIActionSheet, не так ли?