Comments 21
UFO just landed and posted this here
Это ж не моя причуда, это воля заказчика.
Если приложение не пройдёт модерацию из-за того, что одно окно открывается слева, а все остальные справа — не вопрос, сделаем info модальным и никто уже не будет против.
Но, на мой взгляд, здесь нет никакого криминала — так только лучше выглядит и понятнее работает. Правая кнопка открывает окно справа, левая — слева. Дальше по ходу программы так везде (потому что все push только направо, а возвраты налево =)).
Если приложение не пройдёт модерацию из-за того, что одно окно открывается слева, а все остальные справа — не вопрос, сделаем info модальным и никто уже не будет против.
Но, на мой взгляд, здесь нет никакого криминала — так только лучше выглядит и понятнее работает. Правая кнопка открывает окно справа, левая — слева. Дальше по ходу программы так везде (потому что все push только направо, а возвраты налево =)).
Довольно логичное и очевидное, на мой взгляд, решение, хотя и кажется чем-то костыльным, но раз воля заказчика… :) Главное помнить потом, если понадобится вдруг куда-то сильно назад вернуться, что первый ViewController, который видит пользователь, не первый по очереди.
Вопрос — а когда вы пушите через pushViewController принудительно кодом — в ваш InfoViewController можно же вернуться простым жестом, проведя пальцем от левого края экрана вправо — это будет по идее эквивалентно нажатию кнопки «назад». Это не сломает случайно ваш User Experience? :)
Вопрос — а когда вы пушите через pushViewController принудительно кодом — в ваш InfoViewController можно же вернуться простым жестом, проведя пальцем от левого края экрана вправо — это будет по идее эквивалентно нажатию кнопки «назад». Это не сломает случайно ваш User Experience? :)
У вас пример с белыми окнами, там не заметно, но как это выглядит в приложении? У вас же не левое окно выезжает слева, а «основное» окно улетает вправо. Или до таких мелочей заказчику нет дела? :)
Не может быть такого, что улетевшее вправо «основное» окно вдруг уничтожится из-за нехватки памяти?
Не может быть такого, что улетевшее вправо «основное» окно вдруг уничтожится из-за нехватки памяти?
Видео с ограниченным доступом
В таблицах горизонтальные линии, на них ничего не видно :)
Текущее окно сдвигается влево где-то на треть, а новое окно выезжает полностью.
В обратную сторону аналогично — «верхнее» окно улетает вправо целиком, а «нижнее» в начале анимации сдвинуто на треть влево и движется всего на треть влево.
Анимация не зеркальная.
Видео с картинками: de.tinypic.com/r/vpg7qr/8 (для просмотра нужен Flash, открывайте в Google Chrome)
Следите за анимацией — левое окно начинает/заканчивает движение в районе кисти человека.
Но это всё придирки — заказчик и большинство пользователей не заметят подвоха :)
Текущее окно сдвигается влево где-то на треть, а новое окно выезжает полностью.
В обратную сторону аналогично — «верхнее» окно улетает вправо целиком, а «нижнее» в начале анимации сдвинуто на треть влево и движется всего на треть влево.
Анимация не зеркальная.
Видео с картинками: de.tinypic.com/r/vpg7qr/8 (для просмотра нужен Flash, открывайте в Google Chrome)
Следите за анимацией — левое окно начинает/заканчивает движение в районе кисти человека.
Но это всё придирки — заказчик и большинство пользователей не заметят подвоха :)
Объясню, почему поставил минус: вы понимаете, что сделали плохо (прикрываясь волей заказчика), и, тем не менее, «учите» других делать так же. Да еще и поощряете «отлично выглядит».
Если вдруг кому-то не очевидно, что плохо:
1. Нестандартное поведение.
2. Не будет работать свайп пальцем для возврата (особенно актуально для новых больших экранов).
3. Кнопка закрытия уезжает в противоположный угол экрана (и нарушение стандартного поведения, и, опять же, забыли про большие экраны).
Если вдруг кому-то не очевидно, что плохо:
1. Нестандартное поведение.
2. Не будет работать свайп пальцем для возврата (особенно актуально для новых больших экранов).
3. Кнопка закрытия уезжает в противоположный угол экрана (и нарушение стандартного поведения, и, опять же, забыли про большие экраны).
Предложите ваш вариант, с удовольствием применю его на практике.
Если ваше решение — переубедить заказчика, то это не решение поставленной задачи, а её изменение.
Если ваше решение — переубедить заказчика, то это не решение поставленной задачи, а её изменение.
Ну и по пунктам:
1. Единственное, что можно принять за недостаток. Тут я да, «прикрылся» волей заказчика. Вот такой я безответственный программист.
2. Будет, если не заменять backBarButtonItem своей иконкой.
3. То же самое происходит при обычном push segue. Открываешь новое окно кнопкой справа, а закрываешь — кнопкой слева. Как же быть владельцам больших экранов?
Напоминаю, что вы критикуете родной, стандартный push segue в iOS. Единственное, что здесь необычно — это показ второго окна при старте приложения, вместо первого.
Если модераторы Apple не поймут желания заказчика, анимация будет переделана на modal и нет проблем.
Но вот это решение может кому-то еще пригодится, потому что я его нигде не нашел. Походите по ссылкам, оцените костыли.
1. Единственное, что можно принять за недостаток. Тут я да, «прикрылся» волей заказчика. Вот такой я безответственный программист.
2. Будет, если не заменять backBarButtonItem своей иконкой.
3. То же самое происходит при обычном push segue. Открываешь новое окно кнопкой справа, а закрываешь — кнопкой слева. Как же быть владельцам больших экранов?
Напоминаю, что вы критикуете родной, стандартный push segue в iOS. Единственное, что здесь необычно — это показ второго окна при старте приложения, вместо первого.
Если модераторы Apple не поймут желания заказчика, анимация будет переделана на modal и нет проблем.
Но вот это решение может кому-то еще пригодится, потому что я его нигде не нашел. Походите по ссылкам, оцените костыли.
Как оказалось, точно такая же логика работы у родного приложения Mail.
Сначала показываются все письма и сверху активна кнопка возврата на список к ящиками. Так что, поведение вполне стандартное.
Сначала показываются все письма и сверху активна кнопка возврата на список к ящиками. Так что, поведение вполне стандартное.
Вся ваша проблема сводится к решению простой задачи – как сделать так, чтобы navigation controller после инициализации из storyboard уже имел два контроллера в стэке. Ваш вариант решения этой задачи обладает принципиальным недостатками:
1. Вы используете -viewDidLoad как место «мгновенного» перехода к следующему контроллеру, хотя это совершенно неподходящее место для выполнения подобных действий – нужно правильно понимать жизненный цикл UIViewController и назначение соотвествующих методов.
2. В вашем случае view первого (Info) контроллера всегда загружается, хотя в большинстве сценариев это бесполезно, т.к. пользователь его никогда не увидит – опять же нужно понимать жизненный цикл контроллера, в частности – когда инициализируется его view.
3. Вы реализуете логику *навигации* внутри отдельно взятого контроллера – это нарушает принятые в системе уровни абстракции. Представьте, что получится, когда вам потребуется показывать Info контроллер где-то в другой части приложения (или например в iPad-версии) – другим способом и в другом контексте навигации.
Есть много вариантов, которые не обладают такими недостатками, а главное – решают задачу на правильном уровне абстракции. В простом варианте можно реализовать соотвествующую логику в AppDelegate:
1. Вы используете -viewDidLoad как место «мгновенного» перехода к следующему контроллеру, хотя это совершенно неподходящее место для выполнения подобных действий – нужно правильно понимать жизненный цикл UIViewController и назначение соотвествующих методов.
2. В вашем случае view первого (Info) контроллера всегда загружается, хотя в большинстве сценариев это бесполезно, т.к. пользователь его никогда не увидит – опять же нужно понимать жизненный цикл контроллера, в частности – когда инициализируется его view.
3. Вы реализуете логику *навигации* внутри отдельно взятого контроллера – это нарушает принятые в системе уровни абстракции. Представьте, что получится, когда вам потребуется показывать Info контроллер где-то в другой части приложения (или например в iPad-версии) – другим способом и в другом контексте навигации.
Есть много вариантов, которые не обладают такими недостатками, а главное – решают задачу на правильном уровне абстракции. В простом варианте можно реализовать соотвествующую логику в AppDelegate:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
UINavigationController *navigationController = (UINavigationController *)self.window.rootViewController;
UIStoryboard *storyboard = [navigationController storyboard];
UIViewController *mainController = [storyboard instantiateViewControllerWithIdentifier:@"идентификатор контроллера из storyboard"];
navigationController.viewControllers = [navigationController.viewControllers arrayByAddingObject:mainController];
return YES;
}
Ну и забыл добавить, что использовать navigation controller для решения такой задачи навигации – это конечно «костыль». И пусть сейчас этот костыль может быть заметен только наметанному взгляду, никто не дает гарантии, что в одной из будущих версий что-нибудь (анимация перехода, взаимодействие с жестами, анимация navigation bar) не изменится так, что результат будет резать глаз даже неискушенному пользователю.
В iOS7 и iOS8 появилось несклько API, которые как раз подходят для решения подобных задач: View Controller Transitions, UIPresentationController
В iOS7 и iOS8 появилось несклько API, которые как раз подходят для решения подобных задач: View Controller Transitions, UIPresentationController
Делал такое три года назад, тогда без сторибоарда еще, через ручное манипулирование стеком NavController'a — по action'у добавлял в начало массива контроллеров нужный и делал `-popViewController...` Всё. Это было в детской книжке и выглядело красиво — как будто одна большая сцена скроллилась…
Sign up to leave a comment.
Нативный segue слева направо в iOS