14:18 После доклада меня спросили "почему enum? enum - антипаттерн!" Далее я пытался доказать, что enum - это не антипаттерн, а структура языка. К сожалению, тогда не все хотел сказать, что хотел. Да, действительно, одно из правил рефакторинга - это замена enum на полиморфизм. Но это не тот кейс. Мы не хотели менять принцип KISS на какие-то огромные абстракции и городить огороды. То есть, да, можно было нагородить огородов и обойтись без enum, и непосвященный в наши задачи человек так бы и предложил сделать. Но, учитывая необходимость иногда кастомного хендлинга для совершенствования каких-нибудь анимаций, при соблюдении DI, огородов мы бы нагородили на еще одно приложение авито. С энамом все просто, у нас есть одно приложение и там энам живет хорошо. Если бы мы стали выделять диплинкинг в отдельную либу и распространять с целью того, чтобы в других проектах это можно было бы переиспользовать, то мы бы еще подумали, но в нашем приложении enum - это идеальное простое решение, которое снижает затраты на поддержку по сравнению с решением без энама (первое что приходит в голову среднестатистическому программисту - фабрики для конкретных диплинк хендлеров вместо одной общей с энамом и свичем). Качество кода не должно идти в ущерб поддерживаемости и простоты изменения, поэтому у нас тут enum.
29:45 Вопрос о том как обрабатывается ситуация, когда приходит неподдерживаемый диплинк. Тут мне надо было добавить, что мы такие ситуации избегаем версионированием апи, то есть у нас фактически только в одном месте реально приходит необрабатываемый диплинк - в iOS приложении главной странице на список магазинов, для этой ситуации мы не заморачивались с версиями апи, так как это накладно. В основном так совпадает, что и делается все хорошо без заморочек и фолбеки не выполняются на практике (типа скрытия или деактивации элементов). Но фолбеки мы делаем всегда. Нет диплинка - нет действия - нет элемента (или он задизейблен). На презентации рука потянулась показать серенькие кнопки, но потом я вспомнил, что таких де-факто нет.
14:33 то есть вы в результате все равно парсите это в название действия (экрана) и параметры его открытия для роутера. Напрашивается вопрос: в чем тогда смысл всего этого? :) Кейс с переходом с пуш-нотификации понятен, т.к. айос не может сам никак сказать приложению какой экран открыть если не получает диплинка, какой смысл специально себе отдавать диплинки, чтобы их потом парсить вместо того чтобы сразу отдавать действие с аргументами?
20:29 Человек, который мне сказал, что enum - это антипаттерн также сказал, что ему не нравятся такие вот функции, которые модифицируют стейт. Но нет, register здесь - это noescape closure, он не модифицирует стейт. Этим кложуром просто итерируются данные.
8:26 - Почему вы не собираете диплинки на лету из названия действий и уже имеющихся аргументов? Ну или просто не вызываете какой-нибудь роутер с этими аргументами, т.е. по сути из того же енама? Енам выглядит более гибким решением за счет того что не нужно под каждую платформу отдельно генерировать диплинки на стороне сервера (для айоса и андроида они еще могут выглядеть одинаково, но с вебом это уже не прокатит) и серверу не нужно ничего знать про логику навигации в приложении.
> Почему вы не собираете диплинки на лету из названия действий и уже имеющихся аргументов? Имеется в виду, собирать класс, ответственный за поведение диплинка? Уже так и делаем. От энама отказались. Причина энама - были ситуации, когда нужно было на экране, из которого открывали диплинк, обработать или перехватить обработку диплинка. В таких ситуациях мы свитчились по энаму. Сейчас перешли на даункасты в этих местах (к счастью, их не так много). Даункасты - тоже плохо. Да и кастомная обработка конкретных диплинков на конкретных экранах, тоже плохо. В каждом случае можно было сделать универсально с помощью АПИ. Если нужно кастомно отображать список опций (представленных диплинками), то в АПИ можно разграничить это. Как-то было дело (сейчас этого нет) брался список опций, засовывался в навбар в кнопку "...", из списка опций выбирался диплинк на телефон и засовывался в соседнюю кнопку. Хотя можно было в АПИ эту кнопку "позвонить" выделить отдельно. Бонусом получили бы возможность в кнопку "позвонить" встраивать любой диплинк (не только на звонок), например, диплинк на аналитику на какой-то другой диплинк (на тот же "Позвонить"). Энам был нужен для того, чтобы было легко "не делать некоторые вещи нормально". Нормально - это в АПИ разделять диплинки, кастомизацию можно также выделять в диплинки-врапперы, не делая кастомизацию на клиенте. Как в вебе - все ссылки с результатов поиска в гугле являются врапперами на реальные ссылки. > Енам выглядит более гибким решением за счет того что не нужно под каждую платформу отдельно генерировать диплинки на стороне сервера (для айоса и андроида они еще могут выглядеть одинаково, но с вебом это уже не прокатит) и серверу не нужно ничего знать про логику навигации в приложении. Не понял. У нас изначально АПИ диплинков не было никак связано с реальной навигацией внутри приложения. И это зависит не от реализации у нас в iOS, а от АПИ. В АПИ нет никаких намеков на навигацию. Диплинки описывают только то, что приложение должно сделать или куда прийти после обработки. Как именно это будет сделано в АПИ нигде не фигурирует. ---- От энама пока не избавились, прямо сейчас рефакторим. На этот момент у нас почти до 100 дошло количество диплинков, команда выросла, поделилась на "юниты", так что сейчас рефакторим для того, чтобы все это было более масштабируемо, красивее, чтобы было минимум действий по добавлению нового диплинка. Рефакторится также весь код около, в сторону утоньшения/разбиения, например, раньше был толстый класс, который юзался Deep Link Handler'ами и предоставлял интерфейс открытия экранов. Сейчас разбили на Model Opener'ы. Но, где-то примерно год после доклада все жило без особых изменений. Из интересного по АПИ диплинков: есть 2 диплинка с редиректами на диплинки. Сделали разные стандарты - по именованию, по прокидыванию параметров в запросы к АПИ (приложение их всегда просто передает как есть). В целом просто обтесываем то что было, отсекаем лишнее, улучшаем. Что было хорошего даже в решении из доклада - универсальность. Можно совать разные диплинки в любое место и без ведома разработчика, и они будут корректно отрабатывать.
Можно было сразу даункасты использовать (либо с помощью АПИ решать, конечно же, что тоже не бесплатно), просто именно в тот момент я еще не отошел от кода с кучей даункастов (много и не к месту). Сейчас отошел, даункасты будем юзать при рефакторинге, потом постепенно, если все будет хорошо, то и АПИ улучшится.
14:18 После доклада меня спросили "почему enum? enum - антипаттерн!" Далее я пытался доказать, что enum - это не антипаттерн, а структура языка. К сожалению, тогда не все хотел сказать, что хотел. Да, действительно, одно из правил рефакторинга - это замена enum на полиморфизм. Но это не тот кейс. Мы не хотели менять принцип KISS на какие-то огромные абстракции и городить огороды. То есть, да, можно было нагородить огородов и обойтись без enum, и непосвященный в наши задачи человек так бы и предложил сделать. Но, учитывая необходимость иногда кастомного хендлинга для совершенствования каких-нибудь анимаций, при соблюдении DI, огородов мы бы нагородили на еще одно приложение авито. С энамом все просто, у нас есть одно приложение и там энам живет хорошо. Если бы мы стали выделять диплинкинг в отдельную либу и распространять с целью того, чтобы в других проектах это можно было бы переиспользовать, то мы бы еще подумали, но в нашем приложении enum - это идеальное простое решение, которое снижает затраты на поддержку по сравнению с решением без энама (первое что приходит в голову среднестатистическому программисту - фабрики для конкретных диплинк хендлеров вместо одной общей с энамом и свичем). Качество кода не должно идти в ущерб поддерживаемости и простоты изменения, поэтому у нас тут enum.
29:45 Вопрос о том как обрабатывается ситуация, когда приходит неподдерживаемый диплинк. Тут мне надо было добавить, что мы такие ситуации избегаем версионированием апи, то есть у нас фактически только в одном месте реально приходит необрабатываемый диплинк - в iOS приложении главной странице на список магазинов, для этой ситуации мы не заморачивались с версиями апи, так как это накладно. В основном так совпадает, что и делается все хорошо без заморочек и фолбеки не выполняются на практике (типа скрытия или деактивации элементов). Но фолбеки мы делаем всегда. Нет диплинка - нет действия - нет элемента (или он задизейблен). На презентации рука потянулась показать серенькие кнопки, но потом я вспомнил, что таких де-факто нет.
14:33 то есть вы в результате все равно парсите это в название действия (экрана) и параметры его открытия для роутера. Напрашивается вопрос: в чем тогда смысл всего этого? :) Кейс с переходом с пуш-нотификации понятен, т.к. айос не может сам никак сказать приложению какой экран открыть если не получает диплинка, какой смысл специально себе отдавать диплинки, чтобы их потом парсить вместо того чтобы сразу отдавать действие с аргументами?
19:00 Если что, JLRoutes позволяет делать то же самое (как справедливо заметил один из слушателей). Хотя да, мне нравится мой велосипед.
20:29 Человек, который мне сказал, что enum - это антипаттерн также сказал, что ему не нравятся такие вот функции, которые модифицируют стейт. Но нет, register здесь - это noescape closure, он не модифицирует стейт. Этим кложуром просто итерируются данные.
8:26 - Почему вы не собираете диплинки на лету из названия действий и уже имеющихся аргументов? Ну или просто не вызываете какой-нибудь роутер с этими аргументами, т.е. по сути из того же енама? Енам выглядит более гибким решением за счет того что не нужно под каждую платформу отдельно генерировать диплинки на стороне сервера (для айоса и андроида они еще могут выглядеть одинаково, но с вебом это уже не прокатит) и серверу не нужно ничего знать про логику навигации в приложении.
> Почему вы не собираете диплинки на лету из названия действий и уже имеющихся аргументов?
Имеется в виду, собирать класс, ответственный за поведение диплинка?
Уже так и делаем. От энама отказались. Причина энама - были ситуации, когда нужно было на экране, из которого открывали диплинк, обработать или перехватить обработку диплинка. В таких ситуациях мы свитчились по энаму. Сейчас перешли на даункасты в этих местах (к счастью, их не так много). Даункасты - тоже плохо. Да и кастомная обработка конкретных диплинков на конкретных экранах, тоже плохо. В каждом случае можно было сделать универсально с помощью АПИ. Если нужно кастомно отображать список опций (представленных диплинками), то в АПИ можно разграничить это. Как-то было дело (сейчас этого нет) брался список опций, засовывался в навбар в кнопку "...", из списка опций выбирался диплинк на телефон и засовывался в соседнюю кнопку. Хотя можно было в АПИ эту кнопку "позвонить" выделить отдельно. Бонусом получили бы возможность в кнопку "позвонить" встраивать любой диплинк (не только на звонок), например, диплинк на аналитику на какой-то другой диплинк (на тот же "Позвонить").
Энам был нужен для того, чтобы было легко "не делать некоторые вещи нормально". Нормально - это в АПИ разделять диплинки, кастомизацию можно также выделять в диплинки-врапперы, не делая кастомизацию на клиенте. Как в вебе - все ссылки с результатов поиска в гугле являются врапперами на реальные ссылки.
> Енам выглядит более гибким решением за счет того что не нужно под каждую платформу отдельно генерировать диплинки на стороне сервера (для айоса и андроида они еще могут выглядеть одинаково, но с вебом это уже не прокатит) и серверу не нужно ничего знать про логику навигации в приложении.
Не понял. У нас изначально АПИ диплинков не было никак связано с реальной навигацией внутри приложения. И это зависит не от реализации у нас в iOS, а от АПИ. В АПИ нет никаких намеков на навигацию. Диплинки описывают только то, что приложение должно сделать или куда прийти после обработки. Как именно это будет сделано в АПИ нигде не фигурирует.
----
От энама пока не избавились, прямо сейчас рефакторим. На этот момент у нас почти до 100 дошло количество диплинков, команда выросла, поделилась на "юниты", так что сейчас рефакторим для того, чтобы все это было более масштабируемо, красивее, чтобы было минимум действий по добавлению нового диплинка. Рефакторится также весь код около, в сторону утоньшения/разбиения, например, раньше был толстый класс, который юзался Deep Link Handler'ами и предоставлял интерфейс открытия экранов. Сейчас разбили на Model Opener'ы. Но, где-то примерно год после доклада все жило без особых изменений.
Из интересного по АПИ диплинков: есть 2 диплинка с редиректами на диплинки. Сделали разные стандарты - по именованию, по прокидыванию параметров в запросы к АПИ (приложение их всегда просто передает как есть). В целом просто обтесываем то что было, отсекаем лишнее, улучшаем. Что было хорошего даже в решении из доклада - универсальность. Можно совать разные диплинки в любое место и без ведома разработчика, и они будут корректно отрабатывать.
Можно было сразу даункасты использовать (либо с помощью АПИ решать, конечно же, что тоже не бесплатно), просто именно в тот момент я еще не отошел от кода с кучей даункастов (много и не к месту). Сейчас отошел, даункасты будем юзать при рефакторинге, потом постепенно, если все будет хорошо, то и АПИ улучшится.