MetricKit дополняет XCode Organizer, предоставляя программный способ получения данных, чтобы мы могли управлять ими по своему усмотрению, например, отправляя на сервер. Если в XCode Organizer отсутствовали данные, то возможно из-за того, что приложением пользуется недостаточное количество пользователей.
Сейчас всё ещё существует достаточное количество приложений с использованием сторибордов. Да, HEIF действительно редко используется, но полезно знать о такой возможности оптимизации, так как выбор способа реализации связан с требованиями проекта.
Proxyman – однозначно хорош, но не стали перечислять все инструменты, поскольку статья получилась бы довольно большой :) Автор рассказал о том инструментарии, который ему близок.
Что касается Charles, то 30 минут можно пользоваться бесплатно, после чего нужно перезапустить приложение и продолжать работу – этого обычно достаточно для дебаггинга. Postman – бесплатно до 1000 запросов в месяц, чего тоже хватает для дебаггинга.
Автор не сталкивался с Burp suite Community Edition :)
Как уже писали выше это, выбор инструмента – это дело вкуса и удобства. Многие аналоги схожи по своему основному функционалу, главное, чтобы было комфортно работать с выбранным инструментом.
Очевидно, что не получится указать все инструменты, поскольку их очень много :) Как было сказано в начале статьи – наш iOS-разработчик Альберт поделился своим актуальным набором инструментов, который использует в своей работе. Никто не запрещает применять аналоги – это дело вкуса и удобства. Спасибо, что дополнили список :)
Спасибо! Несмотря на то, что использование print в методе deinit может помочь выявить утечки памяти, такой подход дает неполную информации и результат в первом приближении. Рассмотренные инструменты помогут сузить круг поиска и локализовать проблему.
Конечно, мы не используем MLKit на проде, у нас реализован свой анализатор для этих целей. Тут он приведен в качестве демонстрационного решения. А что касается проблемы передачи событий от платформы к Flutter, то ли к радости, то ли к великому страху - с таким не сталкивался. Не могли бы, пожалуйста, поделиться ссылкой на github issue или статью, где эта ситуация описана?
Спасибо! К сожалению, поддержку ТСД в такой пакет не поместить из-за того, что моделей ТСД великое множество, а библиотеки к ним распространяются не по MIT/BSD лицензии. А если речь только про сканер через камеру, то уже есть пакеты, реализующие это (как верно заметил @nikita_dolниже)
Привет! По двум причинам: 1. Нужна поддержка ТСД, редкий поставщик ТСД предоставляет плагин для Flutter, обычно это aar/jar библиотеки. 2. Хочется иметь больший контроль за процессом сканирования.
Спасибо за вопросы!) В Combine есть разделение на горячие/холодные потоки, а также механизмы «ожидания» подписки до выполнения блока кода. Также есть разные виды паблишеров, по типу эмита событий: one-shot и continuous broadcasting. Для обработки ошибок и дебага тоже есть инструмены, например, операторы .replaceError(), а также .print() и .breakpointOnError().
Ответы на ваши вопросы остались за пределами вводной части, поскольку заслуживают отдельной статьи. Мы их осветим в следующем материале о Combine.
Спасибо за уточнение! Да, Virtual Table и Witness Table тоже работают в рантайме. А пример с протоколом, возможно, для некоторых разработчиков будет считаться и фичей. Но чаще разработчики ошибаются в этом и получают неожиданный результат
Добрый день! Хоть и с запозданием, отвечаем :) Объект (в данным случае структура) будет реализовывать Witness Table соответственно. Но переменные, которые относятся именно к самой структуре, будут по-прежнему реализоваться с Direct Dispatch. Соответственно, у данной структуры будут реализованы Direct Dispatch и Witness Table.
Согласны, что простые решения на определённых проектах лучше. Например, Koin на небольших проектах гораздо легче чем Dagger. А иной раз достаточно и использования Service Locator. Исходя из нашего опыта, с ростом размера проекта и команды достоинства сложных решений перевешивают их недостатки.
Добрый день. Подходы к тестированию могут быть разными в зависимости от команды и проекта. Например, разработчики зачастую пишут юнит-тесты на бизнес-логику для проверки различных граничных случаев, а QA и SDET занимаются более сложными кейсами, интеграционным тестированием и тестированием ui.
Технологии под каждый проект выбираются с учетом всех его особенностей и требований заказчика. ML Kit разделен на пакеты, нет необходимости включать его в проект целиком. В данном случае для сканирования barcodes подключали только ML Kit barcode scanning.
Мы выбрали этот способ для того, чтобы опираться на абстракцию, а не реализацию при продвижении от "глупых" сущностей (data) к "умным" (ui). Это соответствует составляющей D (dependency inversion) в принципе SOLID. Практическая цель - повышение тестируемости компонентов
Что называется, если нужен был знак, то это он)
MetricKit дополняет XCode Organizer, предоставляя программный способ получения данных, чтобы мы могли управлять ими по своему усмотрению, например, отправляя на сервер. Если в XCode Organizer отсутствовали данные, то возможно из-за того, что приложением пользуется недостаточное количество пользователей.
Сейчас всё ещё существует достаточное количество приложений с использованием сторибордов. Да, HEIF действительно редко используется, но полезно знать о такой возможности оптимизации, так как выбор способа реализации связан с требованиями проекта.
Proxyman – однозначно хорош, но не стали перечислять все инструменты, поскольку статья получилась бы довольно большой :) Автор рассказал о том инструментарии, который ему близок.
Благодарим за информацию, добавили)
Что касается Charles, то 30 минут можно пользоваться бесплатно, после чего нужно перезапустить приложение и продолжать работу – этого обычно достаточно для дебаггинга.
Postman – бесплатно до 1000 запросов в месяц, чего тоже хватает для дебаггинга.
Автор не сталкивался с Burp suite Community Edition :)
Как уже писали выше это, выбор инструмента – это дело вкуса и удобства. Многие аналоги схожи по своему основному функционалу, главное, чтобы было комфортно работать с выбранным инструментом.
Очевидно, что не получится указать все инструменты, поскольку их очень много :) Как было сказано в начале статьи – наш iOS-разработчик Альберт поделился своим актуальным набором инструментов, который использует в своей работе. Никто не запрещает применять аналоги – это дело вкуса и удобства. Спасибо, что дополнили список :)
Спасибо) Добавили в статью вместе с dump() =)
Спасибо! Несмотря на то, что использование print в методе deinit может помочь выявить утечки памяти, такой подход дает неполную информации и результат в первом приближении. Рассмотренные инструменты помогут сузить круг поиска и локализовать проблему.
Конечно, мы не используем MLKit на проде, у нас реализован свой анализатор для этих целей. Тут он приведен в качестве демонстрационного решения. А что касается проблемы передачи событий от платформы к Flutter, то ли к радости, то ли к великому страху - с таким не сталкивался. Не могли бы, пожалуйста, поделиться ссылкой на github issue или статью, где эта ситуация описана?
Спасибо! К сожалению, поддержку ТСД в такой пакет не поместить из-за того, что моделей ТСД великое множество, а библиотеки к ним распространяются не по MIT/BSD лицензии. А если речь только про сканер через камеру, то уже есть пакеты, реализующие это (как верно заметил @nikita_dolниже)
Привет! По двум причинам:
1. Нужна поддержка ТСД, редкий поставщик ТСД предоставляет плагин для Flutter, обычно это aar/jar библиотеки.
2. Хочется иметь больший контроль за процессом сканирования.
Спасибо за вопросы!)
В Combine есть разделение на горячие/холодные потоки, а также механизмы «ожидания» подписки до выполнения блока кода.
Также есть разные виды паблишеров, по типу эмита событий: one-shot и continuous broadcasting. Для обработки ошибок и дебага тоже есть инструмены, например, операторы .replaceError(), а также .print() и .breakpointOnError().
Ответы на ваши вопросы остались за пределами вводной части, поскольку заслуживают отдельной статьи. Мы их осветим в следующем материале о Combine.
Спасибо за уточнение! Да, Virtual Table и Witness Table тоже работают в рантайме. А пример с протоколом, возможно, для некоторых разработчиков будет считаться и фичей. Но чаще разработчики ошибаются в этом и получают неожиданный результат
Добрый день! Хоть и с запозданием, отвечаем :) Объект (в данным случае структура) будет реализовывать Witness Table соответственно. Но переменные, которые относятся именно к самой структуре, будут по-прежнему реализоваться с Direct Dispatch. Соответственно, у данной структуры будут реализованы Direct Dispatch и Witness Table.
Да, совершенно верно, отредактировали статью.
Согласны, что простые решения на определённых проектах лучше. Например, Koin на небольших проектах гораздо легче чем Dagger. А иной раз достаточно и использования Service Locator. Исходя из нашего опыта, с ростом размера проекта и команды достоинства сложных решений перевешивают их недостатки.
Добрый день. Подходы к тестированию могут быть разными в зависимости от команды и проекта. Например, разработчики зачастую пишут юнит-тесты на бизнес-логику для проверки различных граничных случаев, а QA и SDET занимаются более сложными кейсами, интеграционным тестированием и тестированием ui.
Технологии под каждый проект выбираются с учетом всех его особенностей и требований заказчика. ML Kit разделен на пакеты, нет необходимости включать его в проект целиком. В данном случае для сканирования barcodes подключали только ML Kit barcode scanning.
Да, это будет правильно, спасибо
Мы выбрали этот способ для того, чтобы опираться на абстракцию, а не реализацию при продвижении от "глупых" сущностей (data) к "умным" (ui). Это соответствует составляющей D (dependency inversion) в принципе SOLID. Практическая цель - повышение тестируемости компонентов