Да, спасибо!
Хорошо, что уже оно в в реальных проектах работает.
Входной порог в любой проект возрастает
Ну использование Rx сильно повышает порог, а стандартный GCD нет. я об этом.
Massive View Сontroller
Это люди так пишут, можно писать нормальный MVC, но не будем этом тут :)
A/B тест гамбургер меню против таб бара
Интересная задача на самом деле. Одна если нет переходов из любого места в них) ибо много чего придется оборачивать, что по идеи у вас и делается.
У вас интересные подходы, возможно когда-то на досуге разберусь.
Все таки хочется найти чего-то более простого, более легковестного.
Чтобы было easy to learn hard to master как UIKit :)
Однако, я добавил элементов копированием существующих, менял layout проскролив в конец списка и уже анимация не выходила такой гладкой. (некоторые элементы становились на свои места поментально, а некоторые с анимацией, что сильно коробит глаз) Не знаю, можно ли сделать ее лучше.
Есть артефакты при скроле обратно, после нескольких изменений layout'а. (Текст запоминает старые размеры и анимируется в новые, чего быть не должно).
Если это как-то исправить, то выйдет очень хороший способ.
А метод collectionView.setCollectionViewLayout(UICollectionViewLayout, animated: Bool)
не трогали для подобного изменения представления?
ну не пара строк) кода будет тоже прилично, однако он будет не в отображении, а при создании этих ячеек, что думаю уже не страшно ибо он там будет простой. однако будет немало кода чтобы отрабатывать разные нажатия на них.
проблема при таком случаи это воссоздать все элементы таблицы, чтобы они выглядели как таблица обычная. а это стрелочки, секции, разделители и нажатие на нее. но это справедливо только если в дизайне обычная таблица, что достаточно редко.
и вторая проблема которую я вижу: съедание памяти. для больших таблиц не очень круто будет, особенно если оно будет висеть в navVC в несколько экземпляров (аля регистрация длинная). но опять же, это достаточно редкие случаи.
ну и мини проблема это минимум iOS 9, однако мало кого осталось, кто ее поддерживает ниже нее.
есть вопрос: а можно в StackView просто сделать разные высоты для ячеек без навешивания констрейнта высоты на них, в том же коде?
if let typedCell = cell as? TitledConfigurable, let titled = model as? Titled
При таком подходе очень много лишних операций будет работать.
Так же этот метод разрастется при наличии уже нескольких статичных экранов,
ведь даже на примерах выше много уникальных ячеек.
Лучше тогда сделать подобный StaticDataSourceDelegate для каждого экрана в отдельности, а не делать один на все.
Сомнительная настройка ячеек, опять же разрастется для уникальных ячеек.
Как например будет настраиваться cell.accessoryType, что часто нужно?
Все эти Generic работают только в теории.
На практике выкатывают такие требования, что 10 раз пожалеешь, что их использовал.
п.с.
Тоже задумывался над подобным, но пришел к самому простому решению — просто реализовать стандартные методы. Оказывается самым гибким и легко читаемым решением. Да, есть то что повторяется, но код остается простым, который поймет любой кто его видит в первый раз.
А в чем смысл кидать пользователю все permissions единовременно, а не по мере необходимости?
Терпеть не могу приложения, которые что-то требуют на стартовом экране, да еще и несколько сразу.
Тут конечно можно реализовать и по одному, но тогда весь смысл этой либы теряется.
А зачем Вы везде прописываете "@objc" и "optional"? Поддержки Objective-C я не вижу, так почему не использовать swift реализацию опциональных методов?
Самом собой. Есть несколько паттернов для этого. Самый простой совет — не писать запросы в контроллерах =) Ну а чтобы все это сильно не обсуждать, в самом начале статьи я написал:
«Здесь не будет best practice, создание сервисов, репозиториев и прочей оптимизации кода...».
А так, да, все правильно.
Парсинг json'а в структуры отдал бы на сторону json парсеров библиотек, коих уже сотни
Целью было показать основы. А с выходом Swift 4 вроде как отпадет необходимость в этих библиотеках.
Rx + RxMoya
пока больше понравился паттерн repository service и SOA,
но ищу и рассматриваю другие варианты.
как минимум есть ошибка в "исправить отступ": должно быть Control + i
Как я понимаю Ваше решение только для синхронных функций подойдет.
Любой банальный async и работать не будет.
То что fatalError и его не стоит пихать туда - конечно, эт погорячились.
Но проблема такая существует.
> пока не попадем в багованную ветку
надо просто assert использовать и уже будет очень хорошо.
ну и можно написать тесты, если прям так хочется)
Безусловно. Это так, для справки остальным, кто не в курсе вдруг.
хотел бы посмотреть на это))
Хорошо расписал, подчеркнул многие особенности UISplitViewController.
XR вроде тоже, и остальные "плюс" версии (6+, 7+)
оно же c iOS 11 только, а Вас приложение с iOS 9.3.
Соответственно вопрос: как у Вас на iOS < 11?
Да, спасибо!
Хорошо, что уже оно в в реальных проектах работает.
Ну использование Rx сильно повышает порог, а стандартный GCD нет. я об этом.
Это люди так пишут, можно писать нормальный MVC, но не будем этом тут :)
Интересная задача на самом деле. Одна если нет переходов из любого места в них) ибо много чего придется оборачивать, что по идеи у вас и делается.
У вас интересные подходы, возможно когда-то на досуге разберусь.
Все таки хочется найти чего-то более простого, более легковестного.
Чтобы было easy to learn hard to master как UIKit :)
Выглядит круто, пользоваться ею вроде не сложно.
Однако поддерживать это стороннему человеку будят тяжко, если потребуется какая-то особенность.
Также сильно возрастает входной порог в проект.
Я бы не рискнул взять это в проект ибо кода достаточно много.
Так же есть вопросы к производительности и кастомным анимационным переходам(не успел еще найти их).
Однако как сделать лучше я тоже не знаю.
Простой и эффективный способ оказался, неплохо!
Однако, я добавил элементов копированием существующих, менял layout проскролив в конец списка и уже анимация не выходила такой гладкой. (некоторые элементы становились на свои места поментально, а некоторые с анимацией, что сильно коробит глаз) Не знаю, можно ли сделать ее лучше.
Есть артефакты при скроле обратно, после нескольких изменений layout'а. (Текст запоминает старые размеры и анимируется в новые, чего быть не должно).
Если это как-то исправить, то выйдет очень хороший способ.
А метод
collectionView.setCollectionViewLayout(UICollectionViewLayout, animated: Bool)не трогали для подобного изменения представления?
ну не пара строк) кода будет тоже прилично, однако он будет не в отображении, а при создании этих ячеек, что думаю уже не страшно ибо он там будет простой. однако будет немало кода чтобы отрабатывать разные нажатия на них.
проблема при таком случаи это воссоздать все элементы таблицы, чтобы они выглядели как таблица обычная. а это стрелочки, секции, разделители и нажатие на нее. но это справедливо только если в дизайне обычная таблица, что достаточно редко.
и вторая проблема которую я вижу: съедание памяти. для больших таблиц не очень круто будет, особенно если оно будет висеть в navVC в несколько экземпляров (аля регистрация длинная). но опять же, это достаточно редкие случаи.
ну и мини проблема это минимум iOS 9, однако мало кого осталось, кто ее поддерживает ниже нее.
есть вопрос: а можно в StackView просто сделать разные высоты для ячеек без навешивания констрейнта высоты на них, в том же коде?
При таком подходе очень много лишних операций будет работать.
Так же этот метод разрастется при наличии уже нескольких статичных экранов,
ведь даже на примерах выше много уникальных ячеек.
Лучше тогда сделать подобный StaticDataSourceDelegate для каждого экрана в отдельности, а не делать один на все.
Сомнительная настройка ячеек, опять же разрастется для уникальных ячеек.
Как например будет настраиваться
cell.accessoryType, что часто нужно?Все эти Generic работают только в теории.
На практике выкатывают такие требования, что 10 раз пожалеешь, что их использовал.
п.с.
Тоже задумывался над подобным, но пришел к самому простому решению — просто реализовать стандартные методы. Оказывается самым гибким и легко читаемым решением. Да, есть то что повторяется, но код остается простым, который поймет любой кто его видит в первый раз.
вот парочка примеров: (они не идеальные)
https://github.com/bonyadmitr/XcodeProjects/blob/master/Settings/Settings/Controllers/AboutController.swift
(как раз реализовывает экран выше "О нас", только отличается
accessoryType)https://github.com/bonyadmitr/XcodeProjects/blob/master/Settings/Settings/Controllers/SettingsController.swift
Во viewDidLoad неправильно. Размеры не выставлены еще.
Вроде оно может зависеть от iOS и симулятора.
Сам использую viewWillLayoutSubviews для данной задачи.
А в чем смысл кидать пользователю все permissions единовременно, а не по мере необходимости?
Терпеть не могу приложения, которые что-то требуют на стартовом экране, да еще и несколько сразу.
Тут конечно можно реализовать и по одному, но тогда весь смысл этой либы теряется.
А зачем Вы везде прописываете "@objc" и "optional"? Поддержки Objective-C я не вижу, так почему не использовать swift реализацию опциональных методов?
iPhone SE есть
На сколько я помню это стало возможно с Xcode 7, приблизительно 2 года назад.
Очень годная статья!
За это отдельное спасибо!
Ага
Первая строка в классе:
Почему название пустое?
Самом собой. Есть несколько паттернов для этого. Самый простой совет — не писать запросы в контроллерах =) Ну а чтобы все это сильно не обсуждать, в самом начале статьи я написал:
«Здесь не будет best practice, создание сервисов, репозиториев и прочей оптимизации кода...».
А так, да, все правильно.
Целью было показать основы. А с выходом Swift 4 вроде как отпадет необходимость в этих библиотеках.
пока больше понравился паттерн repository service и SOA,
но ищу и рассматриваю другие варианты.