А вот по этому тикету помочь как раз можете — пара снэпшотов (один на 2019.2, другой на 2019.1.2) при открытии одного и того же файла сильно помогли бы.
Я освобожусь попробую помочь по тикету.
Вот тут бы не с Xcode сравнивать (это занятие несколько бесполезное, если мы урежем кэши до функционала Xcode, то взлетать они будут быстрее, чем в нем), а с AppCode предыдущей версии. Банально — снэпшот на 2019.1, снэпшот на 2019.2.
Вы не поняли, я не с иксодом сравниваю. А показываю что аппкод не открывает этот метод вообще. Икскод хоть как то пытается это сделать.
«Целиком» посвятить — это значит, что работы не будет идти даже над какими-то совсем двухчасовыми мелочами. Это значит совсем целиком. В остальное время работа по оптимизации идет непрерывно.
Тут тоже маленькое недопонимание. Я не знаю упали ли у вас количества платящих пользователей в последнее время, но аппкод становится не пригодным для больших проектов. Я не единственный кто использует аппкод среди знакомых, и многие переключаются в XCode для написания кода, а в Аппкоде выполняют только рефакторинг. Именно потому что скорость работы становится неприемлемой.
Напрасно, это никак не умоляет достоинств среды. Меня тошнит каждый раз когда приходится переключаться в икскод. Эти проблемы то появляются то исчезают. И всегда можно использовать предыдущую версию. Икскод же так и остался мертворожденным.
Ребята, вы делаете отличную работу. Но я скажу тоже самое, что и автор выше. Я вынужден был пропустить последние EAP версии, потому что они были слишком медленными в поиске символов и автоподстановке. Я надеялся что проблема будет решена в стабильной версии, но сильно лучше не стало.
У нас не смешанный проект, обычный интернет магазин. Только свифт. Сравните версии 2019.1 и 2019.2, что изменилось в индексации что он стал таким мертвым.
Да, этого нет в приложении-примере, но по идее таким же образом как и с модальными. RouteComposer только выполняет шаги, и не закрывает никакие объекты и все их свойства доступны наружу. Вам нужно назначить ответственный объект делегатом UINavigationController-а, например используя NavigationControllerFactory.init(delegate: UINavigationControllerDelegate?...) и дальше действовать согласно документации. Если что то не получится — напишите.
Если у вас все сложнее, напишите
Попробую уточнить каждый пункт.
1. Входной порог в любой проект возрастает, если вы используете что то отличное от Massive View Сontroller.
2. Любая особенность расширяется или новой фабрикой, или фаиндером. Роутер лишь выполнит их по очереди.
3. Кастомные переходы остаются на вас и выполняются по всем тем же правилам, которые прописаны в UIKit. Делаете своего делегата презентации и, вперед, как по учебнику. Библиотека ничего не закрывает и не содержит кастомных оберток. Она лишь выполняет шаги по очереди и умеет решать какие из них нужны, а какие нет. По этой же причине не может быть вопросов к производительности. К тому же, итератор дерева вынесен в отдельный компонент и может быть заменен кастомной реализацией в любой момент не затрагивая основную функциональность.
4. Мы адаптировали ее поверх проекта который к тому времени был уже 3 года в релизе именно по причине полнейшей каши в диплинках. И еще в этот момент надо было сделать A/B тест гамбургер меню против таб бара. Тут, как говорится, попробуйте руками. Можно адаптировать по одному экрану или по экранам которым требуется диплинк, а потом все остальное. У нас до сих пор не все 100% покрыты, просто потому что есть куски которые никто не трогал, потому что и так работает. Но все новые скрины автоматом навешиваются на библиотеку. Сейчас в работе A/B/C тест, где и как разместить поиск и подход показывает себя с лучшей стороны.
5. Какой то совсем нестандарт (я не могу себе представить правда), в самом крайнем случае, вы можете исключить роутер и сделать этот переход руками. Прелесть подхода в том что он работает не зависимо от текущего состояния приложения.
6. Риск оправдан опять же тем что библиотека изымается и вы все снова делаете руками при желании. Только вам надо будет самому принимать решения о том показан пользователю экран и как его показать.
Надеюсь, я смог дать однозначный ответ по всем пунктам.
Она никуда не выносится. Остается в цепочке.
1. Вы сами решаете в начале как вы хотите обрабатывать когда приходит пуш когда пользователь в глубине сеттингов. Если сеттинги в другом табе, роутер переключит таб, потому что он знает что список чатов в другом табе. Если сеттинги показаны модально, зависит от вашей конфигурации, роутер может закрыть сеттинги (простой вариант), показать альтернативно час с этим пользователем модально над сеттингами, цепочка может иметь ветвления или вы можете подменить конфигурацию в момент входа пользователя в сеттинги (менее красиво)
2. С этим вообще нет проблем, LoginInterceptor или отрабатывает или нет. Так что этот вопрос даже не стоит.
Оба примера более менее охвачены в Example app. Первый в ProductConfiguration.swift, 2. Любая навигация закрытая LoginInterceptor. Приложение-пример также поддерживает простейший диплинки. Вы можете проверить интересующие вас сценарии имитируя пуш через мобайл сафари.
Там есть несколько причин, сейчас уже все подробности не вспомню, попробую по пунктам:
Классический пример координатора привносит знание во вью контроллер что будет происходить дальше (и у вас в начале статьи он есть). И это делает сложным A/B тестирование — например следующий контроллер будет показан пушем в текущий навигейшен контроллер или презентован модально. Та же проблема возникает с возвратом обратно
Конечно это решается более высоким уровнем абстракции как у вас или в других либах, но тем не менее.
Различные асинхронные диплинки: Допустим у нас в URL в письме может быть продукт код, а показать контроллер мы можем только по продукт айди, то есть сперва надо сделать запрос на сервер, перевести продукт код в продукт айди и потом показывать уже соответствующий контроллер.
На координатор начинают падать не свойственные ему функции значительной трассровки стека вью котнтроллеров на предмет — пользователь тапнул на пуш что бы показать ему продукт с таким то айди, а он уже находится в во вью контроллере ему его показывающим, пушить еще раз? Опеределить где он щас?
Прочие сложности похожие на вариант 1, стилист шарит продукт в аймеседж приложении (доступный не всем пользователям), пользователь кликает, но он не в программе-лояльности, ему нужно показать весь флоу (5 контроллеров) подключения к программе, и потом показать ему продукт если он удачно подписался.
Во время прохождения флоу на подключение к программе лояльности пользователь может забыть пароль от своего аккаунта, тогда ему придет письмо востановления пароля, где он тапнет в линк и внутри флоу будет еще один флоу восстановления пароля. После которого он может при желании продолжить флоу лояльности.
Пользователь на онбоардинг скринах (тупо картинки), тапает на пуш, показывать продукт нужно другим совершенно способом.
Куча логин составляющий и ограничений доступа, из серии что бы куда то попасть пользователь должен быть не только залогинен, но быть еще залогинен в программу доставки от другого вендора.
Все даже не упомню. Из серии анимация навигации в одно место еще не отиграла, а пользователь уже кликнул еще на какой то внешний енгейджмент.
Что было в голом остатке, сами координаторы являясь как бы архитектурным упрощающим паттерном требовали декомпозиция внутри, иначе они сами начинали выглядеть как спагетти. Туда начинала кроме того проваливаться бизнес логика, или они начинали обрастать координаторами координаторов. Координаторы сложно юнит тестить так как они завязаны жестко завязаны на UIKit.
Поскольку мы уже использовали подобный подход успешно прежде, решено было отказаться от координаторов и формализовать старый подход использованный в других приложениях разрабатывавшихся у нас, который показал себя хорошо решая те же задачи.
Используется формализованная библиотека уже более года — полет нормальный. Но конфигурация требует изучения. Примерно как автолайаут команды. Но щас все девелоперы с ней знакомы и ни у кого не возникает проблем.
Каждый этап разделен на сущности, которые можно тестировать отдельно.
Задачи имеют доступ к некоторому объекту мы его зовем wireframe где простые методы — goToProductArray(productArrayId: String), goToProduct(product: String), goToAccount() еоторые просто содержат внутри развернутую конфигурацию, которую проигрывает роутер библиотеки. Что и как ни одна из задач не знает и все работает на ура.
Мы поигрались с координаторами, но в итоге вернулись к подходу который использовали раньше в предыдущих проектах (swift и objc) и пока всем довольны. С координаторами начинается головная боль когда приходится решать вопросы диплинков и т.д. и задачи типа, а что если пользователь уже на этом экране, а что если пользователь в этот момент что то покупал, осталось только на кнопку нажать а тут он тапнул на пуш, и т.д. То есть поначалу казавшийся довольно изящным паттерн начинал обрастать странными иф/елсами, какие то вещи должны были быть весьма асинхронными и становились все более сложными в отладке. В итоге вернулись к старому подходу, и долизали его до библиотеки. Примерно описано тут: habr.com/ru/post/421097
А делегаты живут абсолютно отдельно. Кому надо — подписываться и становится делегатом.
Спасибо. Интересная статья.
Не совсем понимаю почему люди ударились в политику. У автора есть предпочтения. Он никого не угнетает. Кто то не любит Америку/Англию/Россию whatever. Он был честен. И никого не осуждал.
Я освобожусь попробую помочь по тикету.
Вы не поняли, я не с иксодом сравниваю. А показываю что аппкод не открывает этот метод вообще. Икскод хоть как то пытается это сделать.
Тут тоже маленькое недопонимание. Я не знаю упали ли у вас количества платящих пользователей в последнее время, но аппкод становится не пригодным для больших проектов. Я не единственный кто использует аппкод среди знакомых, и многие переключаются в XCode для написания кода, а в Аппкоде выполняют только рефакторинг. Именно потому что скорость работы становится неприемлемой.
Вот свеже открытый проект после индексации:
www.dropbox.com/s/9a33w7q30owi9sy/Symbol%20Search.mov?dl=0
Или вот:
www.dropbox.com/s/uu4jqajv6v80doq/Method%20%20Resolvign.mov?dl=0
В сравнении с не православным XCode
www.dropbox.com/s/e6xn46nixk833c8/Xcode%20resolution.mov?dl=0
Жаль что я не могу помочь больше. Я все логи и что еще запрашивали прикреплял.
У нас не смешанный проект, обычный интернет магазин. Только свифт. Сравните версии 2019.1 и 2019.2, что изменилось в индексации что он стал таким мертвым.
Да, этого нет в приложении-примере, но по идее таким же образом как и с модальными. RouteComposer только выполняет шаги, и не закрывает никакие объекты и все их свойства доступны наружу. Вам нужно назначить ответственный объект делегатом UINavigationController-а, например используя NavigationControllerFactory.init(delegate: UINavigationControllerDelegate?...) и дальше действовать согласно документации. Если что то не получится — напишите.
Если у вас все сложнее, напишите
<>
Удачи в этом нелегком поиске.
Malum consilium est, quod mutari non potest
1. Входной порог в любой проект возрастает, если вы используете что то отличное от Massive View Сontroller.
2. Любая особенность расширяется или новой фабрикой, или фаиндером. Роутер лишь выполнит их по очереди.
3. Кастомные переходы остаются на вас и выполняются по всем тем же правилам, которые прописаны в UIKit. Делаете своего делегата презентации и, вперед, как по учебнику. Библиотека ничего не закрывает и не содержит кастомных оберток. Она лишь выполняет шаги по очереди и умеет решать какие из них нужны, а какие нет. По этой же причине не может быть вопросов к производительности. К тому же, итератор дерева вынесен в отдельный компонент и может быть заменен кастомной реализацией в любой момент не затрагивая основную функциональность.
4. Мы адаптировали ее поверх проекта который к тому времени был уже 3 года в релизе именно по причине полнейшей каши в диплинках. И еще в этот момент надо было сделать A/B тест гамбургер меню против таб бара. Тут, как говорится, попробуйте руками. Можно адаптировать по одному экрану или по экранам которым требуется диплинк, а потом все остальное. У нас до сих пор не все 100% покрыты, просто потому что есть куски которые никто не трогал, потому что и так работает. Но все новые скрины автоматом навешиваются на библиотеку. Сейчас в работе A/B/C тест, где и как разместить поиск и подход показывает себя с лучшей стороны.
5. Какой то совсем нестандарт (я не могу себе представить правда), в самом крайнем случае, вы можете исключить роутер и сделать этот переход руками. Прелесть подхода в том что он работает не зависимо от текущего состояния приложения.
6. Риск оправдан опять же тем что библиотека изымается и вы все снова делаете руками при желании. Только вам надо будет самому принимать решения о том показан пользователю экран и как его показать.
Надеюсь, я смог дать однозначный ответ по всем пунктам.
1. Вы сами решаете в начале как вы хотите обрабатывать когда приходит пуш когда пользователь в глубине сеттингов. Если сеттинги в другом табе, роутер переключит таб, потому что он знает что список чатов в другом табе. Если сеттинги показаны модально, зависит от вашей конфигурации, роутер может закрыть сеттинги (простой вариант), показать альтернативно час с этим пользователем модально над сеттингами, цепочка может иметь ветвления или вы можете подменить конфигурацию в момент входа пользователя в сеттинги (менее красиво)
2. С этим вообще нет проблем, LoginInterceptor или отрабатывает или нет. Так что этот вопрос даже не стоит.
Оба примера более менее охвачены в Example app. Первый в ProductConfiguration.swift, 2. Любая навигация закрытая LoginInterceptor. Приложение-пример также поддерживает простейший диплинки. Вы можете проверить интересующие вас сценарии имитируя пуш через мобайл сафари.
Там есть несколько причин, сейчас уже все подробности не вспомню, попробую по пунктам:
Классический пример координатора привносит знание во вью контроллер что будет происходить дальше (и у вас в начале статьи он есть). И это делает сложным A/B тестирование — например следующий контроллер будет показан пушем в текущий навигейшен контроллер или презентован модально. Та же проблема возникает с возвратом обратно
Конечно это решается более высоким уровнем абстракции как у вас или в других либах, но тем не менее.
Различные асинхронные диплинки: Допустим у нас в URL в письме может быть продукт код, а показать контроллер мы можем только по продукт айди, то есть сперва надо сделать запрос на сервер, перевести продукт код в продукт айди и потом показывать уже соответствующий контроллер.
На координатор начинают падать не свойственные ему функции значительной трассровки стека вью котнтроллеров на предмет — пользователь тапнул на пуш что бы показать ему продукт с таким то айди, а он уже находится в во вью контроллере ему его показывающим, пушить еще раз? Опеределить где он щас?
Прочие сложности похожие на вариант 1, стилист шарит продукт в аймеседж приложении (доступный не всем пользователям), пользователь кликает, но он не в программе-лояльности, ему нужно показать весь флоу (5 контроллеров) подключения к программе, и потом показать ему продукт если он удачно подписался.
Во время прохождения флоу на подключение к программе лояльности пользователь может забыть пароль от своего аккаунта, тогда ему придет письмо востановления пароля, где он тапнет в линк и внутри флоу будет еще один флоу восстановления пароля. После которого он может при желании продолжить флоу лояльности.
Пользователь на онбоардинг скринах (тупо картинки), тапает на пуш, показывать продукт нужно другим совершенно способом.
Куча логин составляющий и ограничений доступа, из серии что бы куда то попасть пользователь должен быть не только залогинен, но быть еще залогинен в программу доставки от другого вендора.
Все даже не упомню. Из серии анимация навигации в одно место еще не отиграла, а пользователь уже кликнул еще на какой то внешний енгейджмент.
Что было в голом остатке, сами координаторы являясь как бы архитектурным упрощающим паттерном требовали декомпозиция внутри, иначе они сами начинали выглядеть как спагетти. Туда начинала кроме того проваливаться бизнес логика, или они начинали обрастать координаторами координаторов. Координаторы сложно юнит тестить так как они завязаны жестко завязаны на UIKit.
Поскольку мы уже использовали подобный подход успешно прежде, решено было отказаться от координаторов и формализовать старый подход использованный в других приложениях разрабатывавшихся у нас, который показал себя хорошо решая те же задачи.
Используется формализованная библиотека уже более года — полет нормальный. Но конфигурация требует изучения. Примерно как автолайаут команды. Но щас все девелоперы с ней знакомы и ни у кого не возникает проблем.
Каждый этап разделен на сущности, которые можно тестировать отдельно.
Задачи имеют доступ к некоторому объекту мы его зовем wireframe где простые методы —
goToProductArray(productArrayId: String),goToProduct(product: String),goToAccount()еоторые просто содержат внутри развернутую конфигурацию, которую проигрывает роутер библиотеки. Что и как ни одна из задач не знает и все работает на ура.habr.com/ru/post/421097
А делегаты живут абсолютно отдельно. Кому надо — подписываться и становится делегатом.
Не совсем понимаю почему люди ударились в политику. У автора есть предпочтения. Он никого не угнетает. Кто то не любит Америку/Англию/Россию whatever. Он был честен. И никого не осуждал.