Поэтому чел и написал, что его прибыльное приложение будет использовать правительство. Сразу же можно отмазываться, что все строго под секретом, иначе его арестуют. Хорошо придумал, молодец!
Девочка "маркетолог" не всегда принимает решения. Часто маркетологи лишь предлагают, некоторые настаивают. Но не всегда решение за ними. Но всегда балом правит выгода. Если владелец продукта уверится в правоте девочки, то беда.
Спасибо за статью эту и предыдущие! Мне очень нравится Ваш слог, пожалуйста, продолжайте :)Особенно нравится стиль перехода к выводам почти в каждом абзаце и, главное, их меткость.
Вот за это прям низкий поклон. А то меня тут уже нейросетью пару раз обозвали. Слог из "прошлой" жизни остался, как и структурирование текстов - юрист я по первому образованию. И опыт написания неимоверного объема документов из прошлого сказывается - пишу легко и быстро, мыли на бумагу удобно ложатся. Ну и выводы в каждом разделе оттуда же.
1) Оставить один стиль, не смешивая GCD и async-await: в дальнейшем в статье последний используется;
Согласен, кода надергал из разных проектов, потому и каша (не уследил). Стараюсь в статье подчеркивать, что это всего лишь примеры, но чаще забываю.
2) Не в init'е стартовать, а отдельными методами рулить старт/стоп
Ну а почему бы и да? Хороший пример, соглашусь.
3) Некритично: предлагаю упомянуть как SwiftData, так и NSPersistentContainer (если всё-таки Core), как сильно упрощающие жизнь в простых же сценариях.
чуть позже добавлю, спасибо
1) банковские приложения при протухании токена вовсе не дадут операцию "протыкать", ибо тебя уже выкинуло на экран авторизации;
2) я б UX-ово предпочёл явное а-ля "для операции (еёКороткоеОписание) необходимо авторизоваться" для первой попавшейся из очереди, а в последующих протухших также сразу обновить токен после успешной ре-авторизации
Тут можно подискутировать немного. Я сам разработчик банковского приложения (и сейчас, и ранее).
У нас сейчас два подхода к обновлению токенов:
протухший — сразу переводим пользователя на авторизацию. Тут нет вариантов что-то протыкать, юзер неизбежно должен авторизоваться снова. Ну и еще нужно не забывать, что у банковских приложение есть запросы на сервер вне авторизованного контекста - информация о продуктах (не персонифицированная), адреса, контакты и много другого. Я это к тому, что не всегда пользователя перекидывает на авторизую. Но это, опять же, редкие случаи (разработчикам проще написать общую логику "протухания" токенов, не учитывая контекст).
протухший — не трогаем юзера до момента отправки первого запроса на сервер. То есть у юзера есть возможность пройти заполнение анкеты до последнего шага и закэшировать результат его действий по вводу данных (разработчики чаще таким не заморачиваются).
В ответ на первое утверждение могу сказать, что банковские приложения разные: некоторые могут и дать юзеру возможность попользоваться функциональностью без перекидывания на экран авторизации. Ну а после авторизации можно же вернуть юзера обратно — на то место, где он остановился.
Ну а на второе утверждение — да, принято, хороший вариант. Спасибо за ваши предложения и комментарий. Думаю, многим будет полезно.
.font(.largeTitle) - это динамический шрифт. Его размер пользователь может увеличивать в настройках телефона ползунком. И, да, согласен, для динамического шрифта, хардить фрейм - плохое решение. При увеличении юзером, например до 150% от просто не влезет во фрейм. Но если шрифт задан строго 20 поинтов и его захардкоженный фрейм его вмещает, то проблем не будет.
И все мною приведенное не относится к локализованным приложениям. Этот контекст в статье не рассматривается. Но и lineLimit при локализации использовать ИМХО тоже не подходит. В одном переводе тайтл в три слова, а в другом языке - это уже может быть не одна, а две строки. Тут получим обрезание текста и троеточие.
Ну и если поделитесь инструментом, который позволяет автоматизировать локализацию на 20-30 языков, буду очень благодарен. Или все «руками» переводите?
Если не использовать динамический шрифт, то работает безотказно и всегда. Linelimit затримит текст - это не всегда подходит. Если у вас текста на две строки и фрейм не задать то при изменении и пересчете фреймов других элементов на экране, получаем некрасивые скачки элемента с текстом на экране. А если у вас такой текст в ячейке списка, то получаем неимоверную красоту. Linelimit не во всех случаях поможет. И еще раз уточню, что мое предложение установить жесткий фрейм - это ситуация, где мы получаем скачки элементов из-за наличия анимаций - довольно не частая ситуация. Если не использовать динамический шрифт, то работает безотказно и всегда. Linelimit затримит текст - это не всегда подходит. Если у вас текста на две строки и фрейм не задать то при изменении и пересчете фреймов других элементов на экране, получаем некрасивые скачки элемента с текстом на экране. А если у вас такой текст в ячейке списка, то получаем неимоверную красоту. Я для себя пока нашел такое решение. Предлагайте свое, я ж не претендую на единственно верное решение. И нейросети использую только для генерации картинок. Зря вы так. Даже грамматику им не даю проверять.
К сожалению функция по отслеживанию движения глаз у Apple работает еще не очень качественно, но это лишь вопрос времени. Да и разработчики не все готовы к подготовке приложений для людей с ограничениями. Это довольно много времени отнимает. Я когда впервые voice over попробовал с полностью отключенным экраном, понял насколько же несоизмеримы затраты времени разработчиков той сложности, с которой приходится сталкиваться незрячим людям. Из своих pet project приложений только два всего перевел на работу с voice over. Оно хоть и из коробки уже видит все (даже не подготовленное) приложение, но зачастую такими прилами просто невозможно пользоваться. Чего уж говорить про тех, кто не может клавой пользоваться :(
Тут работает иначе: надо сначала прочитать статью, которая написана для пользователей, которые не знают, что абсолютно слепые люди могут и должны пользоваться мобильными приложениями, а потом уже писать что-то «умное» в комментах. Но, спасибо, что обозначили свою позицию.
С какой-то из осей (не вспомню), ниже 60 программно запретили. На WWDC в одном из видео было. Не буду искать, извините, полдня займет поиск видео. Да и при современных процессорах 10 уже и добиться сложно будет.
Текстов накопилось за последние годы работы пачка. На месяц писанины хватит хоть через день публиковать. А там уже и к новым исследованиям подключусь. Самая сложность разбить на читаемые куски и не потерять суть. Подумываю над тем как линковать в статьи ссылки на Github, что бы код не раздувал статьи. Но пока идеи на этот счет не очень. Поэтому статья с координатором вышла огромная. А ИИ «помог» только заголовок для этой статьи сляпать. Минусов напихали, больше не буду :)
Да, есть надежда, что они уже когда-то остановятся на так называемом «развитии» навигации и сообщество уже просто само выработает подходы и не придется вечно костыли писать или переписывать.
А по поводу захардкоженной навигации в UIKit - это не проблема в небольших проектах, где нет десятков экранов, которые нужно вызывать откуда угодно. Когда пользовательские пути прямые как лом, то все нормально. А когда экран успеха транзакции нужно вызвать из пяти разных мест, то тут уже хардкод навигации придется ломать.
Навскидку не придумал для чего мне могло бы понадобиться передавать данные из одного State case в другой. Но поразмыслю над этим, спасибо.
А про запрет UI во ViewModel - да, если у вас есть необходимость импортить UIKit во viewModel, то это порочная практика. Именно об этом и пишу. Этого всегда можно избежать. В случае с атрибутированной строкой можно написать отдельный helper, который помогал бы решить эту проблему и дергать его из ViewModel. Кмк это бы решило проблему чистого ViewModel.
Название метода - просто сложившаяся и устоявшаяся практика. Просто так привыкли. А если доработать немного метод start() из примера кода, то лекго можно получить желаемое - указывать координатору как отобразить контроллер. Пару слов об этом в статье было. Вы немного забежали вперед. На горизонте еще пара статей с координатором :) А так, вы абсолютно правы - если есть несколько способов отображения контроллеров, то координатор - отличное место для указания способа их отображения. Подписывайтесь, впереди еще много интересного.
Поэтому чел и написал, что его прибыльное приложение будет использовать правительство. Сразу же можно отмазываться, что все строго под секретом, иначе его арестуют. Хорошо придумал, молодец!
А это точно профессиональный дизайн, как написано на 3 скрине? А то есть сомнения
Девочка "маркетолог" не всегда принимает решения. Часто маркетологи лишь предлагают, некоторые настаивают. Но не всегда решение за ними. Но всегда балом правит выгода. Если владелец продукта уверится в правоте девочки, то беда.
Опасно, до развода так не дойдет, если она пропустит скидку на ее любимые духи?
Ну в своих проектах я на это влияю (они ж мои), в рабочих отчасти. Иногда удается убедить владельца продукта не творить дичь, но не часто :)
Вот за это прям низкий поклон. А то меня тут уже нейросетью пару раз обозвали. Слог из "прошлой" жизни остался, как и структурирование текстов - юрист я по первому образованию. И опыт написания неимоверного объема документов из прошлого сказывается - пишу легко и быстро, мыли на бумагу удобно ложатся. Ну и выводы в каждом разделе оттуда же.
Согласен, кода надергал из разных проектов, потому и каша (не уследил). Стараюсь в статье подчеркивать, что это всего лишь примеры, но чаще забываю.
Ну а почему бы и да? Хороший пример, соглашусь.
чуть позже добавлю, спасибо
Тут можно подискутировать немного. Я сам разработчик банковского приложения (и сейчас, и ранее).
У нас сейчас два подхода к обновлению токенов:
протухший — сразу переводим пользователя на авторизацию. Тут нет вариантов что-то протыкать, юзер неизбежно должен авторизоваться снова. Ну и еще нужно не забывать, что у банковских приложение есть запросы на сервер вне авторизованного контекста - информация о продуктах (не персонифицированная), адреса, контакты и много другого. Я это к тому, что не всегда пользователя перекидывает на авторизую. Но это, опять же, редкие случаи (разработчикам проще написать общую логику "протухания" токенов, не учитывая контекст).
протухший — не трогаем юзера до момента отправки первого запроса на сервер. То есть у юзера есть возможность пройти заполнение анкеты до последнего шага и закэшировать результат его действий по вводу данных (разработчики чаще таким не заморачиваются).
В ответ на первое утверждение могу сказать, что банковские приложения разные: некоторые могут и дать юзеру возможность попользоваться функциональностью без перекидывания на экран авторизации. Ну а после авторизации можно же вернуть юзера обратно — на то место, где он остановился.
Ну а на второе утверждение — да, принято, хороший вариант.
Спасибо за ваши предложения и комментарий. Думаю, многим будет полезно.
.font(.largeTitle) - это динамический шрифт. Его размер пользователь может увеличивать в настройках телефона ползунком. И, да, согласен, для динамического шрифта, хардить фрейм - плохое решение. При увеличении юзером, например до 150% от просто не влезет во фрейм. Но если шрифт задан строго 20 поинтов и его захардкоженный фрейм его вмещает, то проблем не будет.
И все мною приведенное не относится к локализованным приложениям. Этот контекст в статье не рассматривается. Но и lineLimit при локализации использовать ИМХО тоже не подходит. В одном переводе тайтл в три слова, а в другом языке - это уже может быть не одна, а две строки. Тут получим обрезание текста и троеточие.
Ну и если поделитесь инструментом, который позволяет автоматизировать локализацию на 20-30 языков, буду очень благодарен. Или все «руками» переводите?
Если не использовать динамический шрифт, то работает безотказно и всегда. Linelimit затримит текст - это не всегда подходит. Если у вас текста на две строки и фрейм не задать то при изменении и пересчете фреймов других элементов на экране, получаем некрасивые скачки элемента с текстом на экране. А если у вас такой текст в ячейке списка, то получаем неимоверную красоту. Linelimit не во всех случаях поможет. И еще раз уточню, что мое предложение установить жесткий фрейм - это ситуация, где мы получаем скачки элементов из-за наличия анимаций - довольно не частая ситуация. Если не использовать динамический шрифт, то работает безотказно и всегда. Linelimit затримит текст - это не всегда подходит. Если у вас текста на две строки и фрейм не задать то при изменении и пересчете фреймов других элементов на экране, получаем некрасивые скачки элемента с текстом на экране. А если у вас такой текст в ячейке списка, то получаем неимоверную красоту. Я для себя пока нашел такое решение. Предлагайте свое, я ж не претендую на единственно верное решение. И нейросети использую только для генерации картинок. Зря вы так. Даже грамматику им не даю проверять.
Виктория, спасибо за практические советы, буду брать на вооружение
К сожалению функция по отслеживанию движения глаз у Apple работает еще не очень качественно, но это лишь вопрос времени. Да и разработчики не все готовы к подготовке приложений для людей с ограничениями. Это довольно много времени отнимает. Я когда впервые voice over попробовал с полностью отключенным экраном, понял насколько же несоизмеримы затраты времени разработчиков той сложности, с которой приходится сталкиваться незрячим людям. Из своих pet project приложений только два всего перевел на работу с voice over. Оно хоть и из коробки уже видит все (даже не подготовленное) приложение, но зачастую такими прилами просто невозможно пользоваться. Чего уж говорить про тех, кто не может клавой пользоваться :(
Тут работает иначе: надо сначала прочитать статью, которая написана для пользователей, которые не знают, что абсолютно слепые люди могут и должны пользоваться мобильными приложениями, а потом уже писать что-то «умное» в комментах. Но, спасибо, что обозначили свою позицию.
С какой-то из осей (не вспомню), ниже 60 программно запретили. На WWDC в одном из видео было. Не буду искать, извините, полдня займет поиск видео. Да и при современных процессорах 10 уже и добиться сложно будет.
Да порой открываешь сайт, а там целые мультфильмы на экране из компонентов. На десктопе это бы еще и выглядело, но в мобиле оно просто не к месту.
Про slug надо было упомянуть, когда про регулярки в ендпоинтах писали
У меня в Sequence 44 ни разу не попадался, 52 редко, а вот 149 почти всегда. И в сети 2,4 обещанный 6 канал ни разу не поймал.
Спасибо! Покопаю еще немного и поменяю в статье на что-нибудь нейтральное, если все же не найду подтверждения.
А можно ссылку на пруфы? А то что-то не нахожу пока подтверждения. Если так, то исправлю в статье.
Текстов накопилось за последние годы работы пачка. На месяц писанины хватит хоть через день публиковать. А там уже и к новым исследованиям подключусь. Самая сложность разбить на читаемые куски и не потерять суть. Подумываю над тем как линковать в статьи ссылки на Github, что бы код не раздувал статьи. Но пока идеи на этот счет не очень. Поэтому статья с координатором вышла огромная. А ИИ «помог» только заголовок для этой статьи сляпать. Минусов напихали, больше не буду :)
Да, есть надежда, что они уже когда-то остановятся на так называемом «развитии» навигации и сообщество уже просто само выработает подходы и не придется вечно костыли писать или переписывать.
А по поводу захардкоженной навигации в UIKit - это не проблема в небольших проектах, где нет десятков экранов, которые нужно вызывать откуда угодно. Когда пользовательские пути прямые как лом, то все нормально. А когда экран успеха транзакции нужно вызвать из пяти разных мест, то тут уже хардкод навигации придется ломать.
Навскидку не придумал для чего мне могло бы понадобиться передавать данные из одного State case в другой. Но поразмыслю над этим, спасибо.
А про запрет UI во ViewModel - да, если у вас есть необходимость импортить UIKit во viewModel, то это порочная практика. Именно об этом и пишу. Этого всегда можно избежать. В случае с атрибутированной строкой можно написать отдельный helper, который помогал бы решить эту проблему и дергать его из ViewModel. Кмк это бы решило проблему чистого ViewModel.
Название метода - просто сложившаяся и устоявшаяся практика. Просто так привыкли. А если доработать немного метод start() из примера кода, то лекго можно получить желаемое - указывать координатору как отобразить контроллер. Пару слов об этом в статье было. Вы немного забежали вперед. На горизонте еще пара статей с координатором :) А так, вы абсолютно правы - если есть несколько способов отображения контроллеров, то координатор - отличное место для указания способа их отображения. Подписывайтесь, впереди еще много интересного.