Мнение разработчиков: лайфхаки для дизайнеров, ч1.🖥
Hola, Amigos! На связи Flutter-разработчики Amiga: Саша Чаплыгин и Антон Мартышков.
Мы поделимся «болями» из личного опыта при работе с дизайнерами. Обозначим общие ошибки и дадим рекомендации, как при дизайне для Flutter не переделывать бизнес-логику и дизайн-системы по несколько раз. Поехали!
Особенность Flutter в том, что дизайн под этот фреймворк создается адаптивным, его можно сделать уникальным, не опираться на дизайн других платформ. В работе заметили, что некоторые дизайнеры дублируют элементы одного и того же функционала iOS и Android. Это не есть хорошо для пользователя, он начинает путаться при использовании приложения. К тому же это вынуждает делать лишние проверки.
Кейс из практики: мы делаем проект, на главной странице размещаются нижний bottom navigation bar с активными окнами: главная, запись, приемы, чат. Дизайнер решил в этот момент добавить кнопку выхода на главную страницу как в iOS на всех вкладках. Это дублирует функционал bottom navigation bar.
Совет: не смешивайте User experience элементы iOS и Android, которые отвечают за один и тот же функционал, сразу. Вместо этого проанализируйте, не дублирует ли дизайн возможности Flutter.
Привычная работа с iOS и Android может выйти боком. Flutter подходит под все операционные системы, а их больше 10. Часто дизайнеры автоматически подстраивают макеты под 1 платформу, еще реже под 2. Но тут нужно поменять сам подход.
Кейс из практики: дизайнер создал кнопки навигации, которые красиво и гармонично смотрелись на iOS. Но при тестировании на Huawei эти же кнопки занимали пол экрана.
Совет: абстрагируйтесь от привычных операционок iOS и Android. Подумайте, как приложение будет выглядеть на Windows, Web и других.
Когда создается кроссплатформенное приложение, то видно заимствованные элементы. Когда ты пользуешься Android и видишь в приложении виджет iOS, то сразу становится понятно – это Flutter.
Совет: делайте один уникальный дизайн приложения, в котором не будет стандартных решений. Лучше добавьте кастомности. Flutter это позволяет. Да, конечно, никто не запрещает использовать уже понятные пути, но это скучно. Зачем делать то, что скучно?
В следующем посте поделимся еще 3 лайфхаками, не переключайтесь!
Hola, Amigos! На связи Flutter-разработчики Amiga: Саша Чаплыгин и Антон Мартышков.
Мы поделимся «болями» из личного опыта при работе с дизайнерами. Обозначим общие ошибки и дадим рекомендации, как при дизайне для Flutter не переделывать бизнес-логику и дизайн-системы по несколько раз. Поехали!
Особенность Flutter в том, что дизайн под этот фреймворк создается адаптивным, его можно сделать уникальным, не опираться на дизайн других платформ. В работе заметили, что некоторые дизайнеры дублируют элементы одного и того же функционала iOS и Android. Это не есть хорошо для пользователя, он начинает путаться при использовании приложения. К тому же это вынуждает делать лишние проверки.
Кейс из практики: мы делаем проект, на главной странице размещаются нижний bottom navigation bar с активными окнами: главная, запись, приемы, чат. Дизайнер решил в этот момент добавить кнопку выхода на главную страницу как в iOS на всех вкладках. Это дублирует функционал bottom navigation bar.
Совет: не смешивайте User experience элементы iOS и Android, которые отвечают за один и тот же функционал, сразу. Вместо этого проанализируйте, не дублирует ли дизайн возможности Flutter.
Привычная работа с iOS и Android может выйти боком. Flutter подходит под все операционные системы, а их больше 10. Часто дизайнеры автоматически подстраивают макеты под 1 платформу, еще реже под 2. Но тут нужно поменять сам подход.
Кейс из практики: дизайнер создал кнопки навигации, которые красиво и гармонично смотрелись на iOS. Но при тестировании на Huawei эти же кнопки занимали пол экрана.
Совет: абстрагируйтесь от привычных операционок iOS и Android. Подумайте, как приложение будет выглядеть на Windows, Web и других.
Когда создается кроссплатформенное приложение, то видно заимствованные элементы. Когда ты пользуешься Android и видишь в приложении виджет iOS, то сразу становится понятно – это Flutter.
Совет: делайте один уникальный дизайн приложения, в котором не будет стандартных решений. Лучше добавьте кастомности. Flutter это позволяет. Да, конечно, никто не запрещает использовать уже понятные пути, но это скучно. Зачем делать то, что скучно?
В следующем посте поделимся еще 3 лайфхаками, не переключайтесь!
🔥8👍5🤔1
Hola, Amigos!
Мы разработали мобильное приложение на Flutter с интеграцией программы лояльности PRO.Expert
В нем сервисные специалисты компании Vaillant могут регистрировать работы и получать за это баллы. Их можно копить, выводить на карту или получать подарки из каталога.
Что мы сделали:
— разработали приложение с нуля;
— сократили время заполнения данных с 5 минут до 30 секунд;
— создали упрощенный функционал регистрации работы;
— внедрили офлайн-регистрацию;
— унифицировали сбор данных и соединили их в единую систему.
Задавайте вопросы, мы обязательно ответим на них.
Мы разработали мобильное приложение на Flutter с интеграцией программы лояльности PRO.Expert
В нем сервисные специалисты компании Vaillant могут регистрировать работы и получать за это баллы. Их можно копить, выводить на карту или получать подарки из каталога.
Что мы сделали:
— разработали приложение с нуля;
— сократили время заполнения данных с 5 минут до 30 секунд;
— создали упрощенный функционал регистрации работы;
— внедрили офлайн-регистрацию;
— унифицировали сбор данных и соединили их в единую систему.
Задавайте вопросы, мы обязательно ответим на них.
🔥14⚡2👍1
Мнение разработчиков: лайфхаки для дизайнеров, ч2.⌨️
Hola, Amigos! На связи Flutter-разработчики Amiga: Саша Чаплыгин и Антон Мартышков.
Мы продолжаем делиться болями в работе с дизайнерами, которые создают макеты для Flutter. В первом посте мы рассказали об общем подходе в работе, сегодня пойдем по деталям.
Для Android и iOS иконки нужны в разных форматах и размерах. При нативной разработке привычнее подстраиваться под платформу, но c Flutter все не так. Плагин flutter_launcher_icons автоматически подгоняет иконку под нужный размер, но для этого нужен векторный формат.
Cовет: сразу делайте иконки в векторе.
С большим текстом разработчикам не всегда очевидно, как его отображать. На макете он смотрится органично, но при разработке вскрываются проблемы.
Совет: если текстовое поле подразумевает длинный текст, то указывайте как обрезать его, перенести на следующую строку или снижать размер шрифта. Это сократит время разработки.
У Flutter собственный рендеринг, поэтому поведение визуальных компонентов отличается от принятого на каждой из платформ. Это ускоряет разработку при условии, что прописан четкий UI Kit, и дизайнер следует ему.
Совет: делайте UI Kit, используйте его в работе.
Разработчики и дизайнеры, какие мысли? Есть, что добавить? Пишите, с радостью подискутируем!✏️
Hola, Amigos! На связи Flutter-разработчики Amiga: Саша Чаплыгин и Антон Мартышков.
Мы продолжаем делиться болями в работе с дизайнерами, которые создают макеты для Flutter. В первом посте мы рассказали об общем подходе в работе, сегодня пойдем по деталям.
Для Android и iOS иконки нужны в разных форматах и размерах. При нативной разработке привычнее подстраиваться под платформу, но c Flutter все не так. Плагин flutter_launcher_icons автоматически подгоняет иконку под нужный размер, но для этого нужен векторный формат.
Cовет: сразу делайте иконки в векторе.
С большим текстом разработчикам не всегда очевидно, как его отображать. На макете он смотрится органично, но при разработке вскрываются проблемы.
Совет: если текстовое поле подразумевает длинный текст, то указывайте как обрезать его, перенести на следующую строку или снижать размер шрифта. Это сократит время разработки.
У Flutter собственный рендеринг, поэтому поведение визуальных компонентов отличается от принятого на каждой из платформ. Это ускоряет разработку при условии, что прописан четкий UI Kit, и дизайнер следует ему.
Совет: делайте UI Kit, используйте его в работе.
Разработчики и дизайнеры, какие мысли? Есть, что добавить? Пишите, с радостью подискутируем!✏️
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Flutter. Много
Мнение разработчиков: лайфхаки для дизайнеров, ч1.🖥
Hola, Amigos! На связи Flutter-разработчики Amiga: Саша Чаплыгин и Антон Мартышков.
Мы поделимся «болями» из личного опыта при работе с дизайнерами. Обозначим общие ошибки и дадим рекомендации, как при…
Hola, Amigos! На связи Flutter-разработчики Amiga: Саша Чаплыгин и Антон Мартышков.
Мы поделимся «болями» из личного опыта при работе с дизайнерами. Обозначим общие ошибки и дадим рекомендации, как при…
🔥10👍2
Кейс: что делать с большим APK-файлом?⚙️
Hola, Amigos! На связи Антон Мартышков, Flutter-разработчик Amiga. Сегодня на реальном примере проекта расскажу, как сократить вес APK-файла за 10 минут работы.
Одна из важных метрик Android-приложения наряду со скоростью запуска — вес установочного файла. Большой APK-файл долго скачивается на устройствах с небольшой объемом внутренней памяти, из-за этого могут быть проблемы с установкой. Это повлияет на конверсию и удовлетворенность пользователя
Пример из практики: когда я начал работать над проектом, установочный файл весил примерно 126 Мб. Проведя исследование, я заметил, что мы используем общую ML-библиотеку от Google «google_ml_kit», хотя большая часть функционала не была нужна. Увидев, что Google раздробил большую библиотеку на маленькие, я принялся их заменять. Убедился, что библиотека работает также, а функционал приложения не изменился, провел замеры. По итогу установочный файл уменьшился примерно на 46 Мб.
Очень здорово, подумал я, но все равно многовато. Продолжил поиски и наткнулся на большой gif-файл, 18,8Мб, длиной в 6 секунд. И тут же сжал его без потерь до 6Мб.
Показал небольшую оптимизацию тимлиду, получил одобрение на MR в релизную ветку.
Так 30 минут поиска проблем и 10 минут небольших изменений дали пользователям приятный вес установочного файла в 68 Мб.
Что делать с большим APK-файлом?
— Проведите исследование, действительно ли вы используете подходящую библиотеку.
— Тестируйте, не изменился ли функционал приложения после изменений.
— Все, что можно оптимизировать – оптимизируйте.
— Не забудьте про согласование с тимлидом, это важно.
Hola, Amigos! На связи Антон Мартышков, Flutter-разработчик Amiga. Сегодня на реальном примере проекта расскажу, как сократить вес APK-файла за 10 минут работы.
Одна из важных метрик Android-приложения наряду со скоростью запуска — вес установочного файла. Большой APK-файл долго скачивается на устройствах с небольшой объемом внутренней памяти, из-за этого могут быть проблемы с установкой. Это повлияет на конверсию и удовлетворенность пользователя
Пример из практики: когда я начал работать над проектом, установочный файл весил примерно 126 Мб. Проведя исследование, я заметил, что мы используем общую ML-библиотеку от Google «google_ml_kit», хотя большая часть функционала не была нужна. Увидев, что Google раздробил большую библиотеку на маленькие, я принялся их заменять. Убедился, что библиотека работает также, а функционал приложения не изменился, провел замеры. По итогу установочный файл уменьшился примерно на 46 Мб.
Очень здорово, подумал я, но все равно многовато. Продолжил поиски и наткнулся на большой gif-файл, 18,8Мб, длиной в 6 секунд. И тут же сжал его без потерь до 6Мб.
Показал небольшую оптимизацию тимлиду, получил одобрение на MR в релизную ветку.
Так 30 минут поиска проблем и 10 минут небольших изменений дали пользователям приятный вес установочного файла в 68 Мб.
Что делать с большим APK-файлом?
— Проведите исследование, действительно ли вы используете подходящую библиотеку.
— Тестируйте, не изменился ли функционал приложения после изменений.
— Все, что можно оптимизировать – оптимизируйте.
— Не забудьте про согласование с тимлидом, это важно.
🔥12👍3⚡1
Мнение разработчиков: послание для бэка, ч1.🔙
Hola, Amigos! С вами Саша Чаплыгин, Flutter-dev Amiga. Сегодня поделюсь примерами из практики в работе с back-end.
Зачастую, когда реализуешь какое-либо приложение, бэк может быть не готовым, или же он делается параллельно. В связи с этим возникают определенные проблемы с данными. В этом случае можно посоветовать только набраться терпения и верстать макеты с моковыми данными. Потом, когда бэк будет готов, нужно будет переделать модели данных,на которых построено МП, реализовать запросы этих данных и обрабатывать их так как это задумано в ТЗ.
Кейс из практики: пока не было API на проекте, успели реализовать приложение на моковых данных. Как итог заказчик увидел демо-версию приложения и был доволен тем, что получилось.
Когда же возникает проблема с уже готовым бэком, может быть 2 решения. Первый, самый логичный, попросить бэк починить тот или иной метод, дабы он отдавал нужные данные. Но бывает так, что пока бэк разберется с этой проблемой, пройдет месяц, а-то и больше (такое бывает в крупных проектах). Отсюда возникает второе решение – попытаться обработать или преобразовать имеющиеся данные в нужные. Это ускорит релиз и заказчик будет доволен.
Кейс из практики: бэк заказчика отдавал разные форматы даты и времени – timestamp и ISO 8601. В итоге сделали обработку и того и другого формата сразу.
Послание бэкендщикам от мобильщиков:
1. Делайте поля объекта такими, какими они должны быть. К примеру, из того что я встречал:
• Присылали булево значение строкой. “false” вместо false;
• Если значение поля всегда число – делайте это поле числом, а не строкой.
2. Тестируйте API самостоятельно или же подключите автотестирование. Мобильщики не должны проверять его.
Кейс из практики: подключение нескольких новых методов в МП привело к тому, что почти все методы не работали должным образом. В итоге потрачено время на проверку API, но никак не на подключение новых методов.
3. Всегда нужно чтобы API придерживалось схеме «ключ» – «значение».
Пример:
Плохая реализация поля fullName
{
“id”: “124314dfsdffd”,
“fullName” : [“John”, “Jameson”]
}
Правильная реализация
{
“id”: “124314dfsdffd”,
“fullName” : {“name”: “John”, “surname” : “Jameson”}
Hola, Amigos! С вами Саша Чаплыгин, Flutter-dev Amiga. Сегодня поделюсь примерами из практики в работе с back-end.
Зачастую, когда реализуешь какое-либо приложение, бэк может быть не готовым, или же он делается параллельно. В связи с этим возникают определенные проблемы с данными. В этом случае можно посоветовать только набраться терпения и верстать макеты с моковыми данными. Потом, когда бэк будет готов, нужно будет переделать модели данных,на которых построено МП, реализовать запросы этих данных и обрабатывать их так как это задумано в ТЗ.
Кейс из практики: пока не было API на проекте, успели реализовать приложение на моковых данных. Как итог заказчик увидел демо-версию приложения и был доволен тем, что получилось.
Когда же возникает проблема с уже готовым бэком, может быть 2 решения. Первый, самый логичный, попросить бэк починить тот или иной метод, дабы он отдавал нужные данные. Но бывает так, что пока бэк разберется с этой проблемой, пройдет месяц, а-то и больше (такое бывает в крупных проектах). Отсюда возникает второе решение – попытаться обработать или преобразовать имеющиеся данные в нужные. Это ускорит релиз и заказчик будет доволен.
Кейс из практики: бэк заказчика отдавал разные форматы даты и времени – timestamp и ISO 8601. В итоге сделали обработку и того и другого формата сразу.
Послание бэкендщикам от мобильщиков:
1. Делайте поля объекта такими, какими они должны быть. К примеру, из того что я встречал:
• Присылали булево значение строкой. “false” вместо false;
• Если значение поля всегда число – делайте это поле числом, а не строкой.
2. Тестируйте API самостоятельно или же подключите автотестирование. Мобильщики не должны проверять его.
Кейс из практики: подключение нескольких новых методов в МП привело к тому, что почти все методы не работали должным образом. В итоге потрачено время на проверку API, но никак не на подключение новых методов.
3. Всегда нужно чтобы API придерживалось схеме «ключ» – «значение».
Пример:
Плохая реализация поля fullName
{
“id”: “124314dfsdffd”,
“fullName” : [“John”, “Jameson”]
}
Правильная реализация
{
“id”: “124314dfsdffd”,
“fullName” : {“name”: “John”, “surname” : “Jameson”}
👍8🔥6🏆1
Hola, Amigos!
Как начать разрабатывать на Flutter и найти работу? Как быстро повышать скиллы и расти разработке? Саша Чаплыгин, Flutter-dev Amiga, рассказал о том, как стать разработчиком на Flutter.
В этой статье Саша поделился:
— своим опытом поиска работы;
— материалами для изучения Flutter;
— личным опытом взлетов и факапов;
— чек-листом по устранению ошибок новичков.
Почитать статью можно тут. Если есть вопросы — пишите, Саша обязательно на все ответит.
Как начать разрабатывать на Flutter и найти работу? Как быстро повышать скиллы и расти разработке? Саша Чаплыгин, Flutter-dev Amiga, рассказал о том, как стать разработчиком на Flutter.
В этой статье Саша поделился:
— своим опытом поиска работы;
— материалами для изучения Flutter;
— личным опытом взлетов и факапов;
— чек-листом по устранению ошибок новичков.
Почитать статью можно тут. Если есть вопросы — пишите, Саша обязательно на все ответит.
🔥8👏3🏆3
Мнение разработчиков: послание для бэка, ч.2.🔙
Hola, Amigos! На связи Антон Мартышков, Flutter-dev Amiga. Здесь Саша рассказал свой опыт в совместной работе с Backend-разработчиками. Сегодня я продолжу эту тему и дам несколько рекомендаций для бэка.
1. Документируйте свое API. Невозможно качественно подключить клиентскую часть, когда не знаешь, что нужно передать серверу, и что он вернет. Эту документацию нужно поддерживать в актуальном состоянии чаще, чем любую другую. Ведь от актуальности API зависит качество разработки продукта.
2. Изучайте дизайн и ТЗ. Не нужно слать лишние данные, а при изучении дизайна, поймете какие данные нам нужны для отображения пользователю.
3. Не переносите функционал, который должен делать back на front-часть.
Пример из практики: был у меня случай, когда backend-разработчик не хотел делать оплату по карте на своей стороне. Он всячески убеждал руководство о необходимости делать это на Android и iOS. Но именно backend отвечает за этот функционал.
4. Следите за чистотой код и рефакторите его. Не нужно в разных запросах отправлять похожие сущности (img, image, img_url и тд).
5. Всегда делайте хорошую обработку ошибок, объясняйте причины ошибок или хотя бы код ошибки. Так мы сможем объяснить пользователю, что пошло не по плану.
Задавайте вопросы, если они есть, с радостью отвечу и подискутируем!
Hola, Amigos! На связи Антон Мартышков, Flutter-dev Amiga. Здесь Саша рассказал свой опыт в совместной работе с Backend-разработчиками. Сегодня я продолжу эту тему и дам несколько рекомендаций для бэка.
1. Документируйте свое API. Невозможно качественно подключить клиентскую часть, когда не знаешь, что нужно передать серверу, и что он вернет. Эту документацию нужно поддерживать в актуальном состоянии чаще, чем любую другую. Ведь от актуальности API зависит качество разработки продукта.
2. Изучайте дизайн и ТЗ. Не нужно слать лишние данные, а при изучении дизайна, поймете какие данные нам нужны для отображения пользователю.
3. Не переносите функционал, который должен делать back на front-часть.
Пример из практики: был у меня случай, когда backend-разработчик не хотел делать оплату по карте на своей стороне. Он всячески убеждал руководство о необходимости делать это на Android и iOS. Но именно backend отвечает за этот функционал.
4. Следите за чистотой код и рефакторите его. Не нужно в разных запросах отправлять похожие сущности (img, image, img_url и тд).
5. Всегда делайте хорошую обработку ошибок, объясняйте причины ошибок или хотя бы код ошибки. Так мы сможем объяснить пользователю, что пошло не по плану.
Задавайте вопросы, если они есть, с радостью отвечу и подискутируем!
🔥11👍1🤔1👌1
Обычно тут мы пишем про разработку на Flutter, но сегодня хочется поделиться, как мы в Amiga управляем удаленной командой разработки.
Наш тимлид Руслан Ревель собрал все самое важное по этому поводу.
Наш тимлид Руслан Ревель собрал все самое важное по этому поводу.
🔥9👍4👏2🏆2
Советы Junior-разработчикам🦾
Hola, Amigos! С вами Flutter-разрабы Amiga – Антон Мартышков и Саша Чаплыгин. Вас уже 200+, и это очень круто! Спасибо, что читаете и доверяете нам.
Большая часть подписчиков пришли после статьи Саши о том, как стать Flutter-разработчиком. Поэтому мы решили собрать 9 советов для джунов, которые помогут не совершать те же ошибки, что в свое время делали мы. Поехали!
1. Cмотрите widget of the week от команды Flutter. Возможно, там вы вспомните о необходимом виджете, который поможет решить задачу быстро и точно.
2. Изучайте, как Flutter работает «под капотом». То есть, углубляйтесь в то, как все работает во Flutter. Например, как работает сборщик мусора, как строится дерево виджетов, какие есть возможности в общении с нативом и т.д.
3. Изучайте Dart и его возможности. Читайте техническую документацию Flutter и Dart.
4. Погружайтесь в нативные платформы. Хоть мы и пишем кроссплатформенные приложения, но платформы, на которых это работает, нужно знать и настраивать для корректной работы.
5. Выбирая библиотеку, посмотрите, нет ли аналогов. Изучите и сравните, какой плагин в каком случае лучше использовать.
6. Следите за чистотой кода, учитесь писать чистый код. Изучайте паттерны и применяйте их на практике.
7. При использовании функций вместо виджетов теряется часть информации, фреймворк не может адекватно перестраивать интерфейс, оптимизируя нагрузку. На нагруженных экранах это может приводить к «залипанию» интерфейса.
8. Всегда аккуратно относитесь к null-safety. Проверяйте, пришла ли переменная null, или же подставляйте дефолтное значение с помощью "??"
9. Помните, что объем кода не показывает ваше знание и профпригодность. Очень часто 1 строка чистого и правильного кода может заменить 10-ки плохо написанных строк.
Hola, Amigos! С вами Flutter-разрабы Amiga – Антон Мартышков и Саша Чаплыгин. Вас уже 200+, и это очень круто! Спасибо, что читаете и доверяете нам.
Большая часть подписчиков пришли после статьи Саши о том, как стать Flutter-разработчиком. Поэтому мы решили собрать 9 советов для джунов, которые помогут не совершать те же ошибки, что в свое время делали мы. Поехали!
1. Cмотрите widget of the week от команды Flutter. Возможно, там вы вспомните о необходимом виджете, который поможет решить задачу быстро и точно.
2. Изучайте, как Flutter работает «под капотом». То есть, углубляйтесь в то, как все работает во Flutter. Например, как работает сборщик мусора, как строится дерево виджетов, какие есть возможности в общении с нативом и т.д.
3. Изучайте Dart и его возможности. Читайте техническую документацию Flutter и Dart.
4. Погружайтесь в нативные платформы. Хоть мы и пишем кроссплатформенные приложения, но платформы, на которых это работает, нужно знать и настраивать для корректной работы.
5. Выбирая библиотеку, посмотрите, нет ли аналогов. Изучите и сравните, какой плагин в каком случае лучше использовать.
6. Следите за чистотой кода, учитесь писать чистый код. Изучайте паттерны и применяйте их на практике.
7. При использовании функций вместо виджетов теряется часть информации, фреймворк не может адекватно перестраивать интерфейс, оптимизируя нагрузку. На нагруженных экранах это может приводить к «залипанию» интерфейса.
8. Всегда аккуратно относитесь к null-safety. Проверяйте, пришла ли переменная null, или же подставляйте дефолтное значение с помощью "??"
9. Помните, что объем кода не показывает ваше знание и профпригодность. Очень часто 1 строка чистого и правильного кода может заменить 10-ки плохо написанных строк.
👍20❤8🔥2👌1
История кросплатформы, ч.1.⏳
Hola, Amigos!
С вами Flutter-разработчик Amiga Антон Мартышков. Нередко можем услышать разные мнения о Flutter или React Native. Но не многие знаю, что попытки создать успешный кроссплатформенный фреймворк начались незадолго до появления Android.
Проведу небольшой ликбез по истории создания кроссплатформенных фреймворков.
Первый кроссплатформенный фреймворк — это PWA (Progressive Web Application). Веб-технология, которая визуально и функционально трансформирует сайт в мобильное приложение. Технология PWA была создана корпорацией Microsoft в 2000 году. На текущий момент все еще используется, но не стала популярным решением.
Cordova — также решение из мира веб-разработки, но в отличии от PWA результат упаковывался в нативное приложение. UX отличается от нативного представления, а производительность невелика. И в итоге проект закрыли, сейчас его не найти.
Изначально разрабатывался как кроссплатформа для десктопа фреймворк QT. Его основной язык C++. Для Android и iOS это не чужой язык, поэтому создатели решили захватить еще и мобильные платформы. При этом пользователь ощущал «ненативность» приложения, а писать UI на C++ можно только представить, как увлекательно (нет). К тому же это платный фреймворк, у которого есть бесплатная версия, но на ней многого не напишешь + и скудная IDE. В итоге решение не умерло, но используется очень редко.
Еще одна попытка сделать кроссплатформу от Microsoft, в этот раз на C# — это Xamarin. Без проблем переносится бизнес-логика, но вот сложный UI может быть сопоставим с разработкой 2-3 нативных решений. В итоге Xamarin все еще живет, но масштабной популярности не обрел.
Во втором посте расскажу о React.Native и Flutter подробнее, ведь они следующие по разработке кроссплаторфменных фреймворков. Есть вопросы? Задавайте!
Hola, Amigos!
С вами Flutter-разработчик Amiga Антон Мартышков. Нередко можем услышать разные мнения о Flutter или React Native. Но не многие знаю, что попытки создать успешный кроссплатформенный фреймворк начались незадолго до появления Android.
Проведу небольшой ликбез по истории создания кроссплатформенных фреймворков.
Первый кроссплатформенный фреймворк — это PWA (Progressive Web Application). Веб-технология, которая визуально и функционально трансформирует сайт в мобильное приложение. Технология PWA была создана корпорацией Microsoft в 2000 году. На текущий момент все еще используется, но не стала популярным решением.
Cordova — также решение из мира веб-разработки, но в отличии от PWA результат упаковывался в нативное приложение. UX отличается от нативного представления, а производительность невелика. И в итоге проект закрыли, сейчас его не найти.
Изначально разрабатывался как кроссплатформа для десктопа фреймворк QT. Его основной язык C++. Для Android и iOS это не чужой язык, поэтому создатели решили захватить еще и мобильные платформы. При этом пользователь ощущал «ненативность» приложения, а писать UI на C++ можно только представить, как увлекательно (нет). К тому же это платный фреймворк, у которого есть бесплатная версия, но на ней многого не напишешь + и скудная IDE. В итоге решение не умерло, но используется очень редко.
Еще одна попытка сделать кроссплатформу от Microsoft, в этот раз на C# — это Xamarin. Без проблем переносится бизнес-логика, но вот сложный UI может быть сопоставим с разработкой 2-3 нативных решений. В итоге Xamarin все еще живет, но масштабной популярности не обрел.
Во втором посте расскажу о React.Native и Flutter подробнее, ведь они следующие по разработке кроссплаторфменных фреймворков. Есть вопросы? Задавайте!
🔥8👍6👌1
История кросплатформы, ч.2.⏳
Hola, Amigos!
С вами Flutter-разработчик Amiga Антон Мартышков. Недавно я рассказывал о том, как создавалась кроссплатформа. Я остановился на Xamarin. Следующий в очереди React Native.
React Native — это кроссплатформенный фреймворк с открытым исходным кодом для разработки нативных мобильных и настольных приложений на JavaScript и TypeScript. Этот фреймворк разработали в Facebook, ныне Meta*. Может показаться, что React Native похожим на Cordova, но нет. Идея заключалась в том, чтобы писать все на JS, а для UI использовать нативные элементы.
Очень сложно добиться нативного поведения и отображения. Некоторые компании, например, Airbnb, вовсе устали бороться с React Native и вернулись к нативной разработке. Тем не менее, решение заняло определенную нишу в мире IT.
Вот мы и дошли до Flutter. Это комплект средств разработки и фреймворк с открытым исходным кодом для создания мобильных приложений под Android и iOS, веб-приложений, а также настольных приложений под Windows, macOS и Linux с использованием языка программирования Dart, разработанный и развиваемый корпорацией Google.
Flutter сам рисует на любой поддерживаемой платформе UI, не обращается к нативным элементам, но имитирует стандартные UI-элементы Android и iOS. Вся бизнес-логика шарится между платформами. На текущий момент одно из лучших решений для кросплатформы, активно развивается и поддерживается Google. На Flutter разработаны приложения Яндекс.GO, Google Ads, Ebay и многие другие.
Еще есть KMM — kotlin multi-platform mobile. Это решение, при котором можно шарить только бизнес-логику на языке kotlin; UI и платформозависимые вещи придётся писать и там, и там. Пока рано что либо говорить, так как проект недавно перешел в бету.
Стоит добавить, что, идеального решения не существует. Есть хорошие решения и они успешны, и есть те, кто не получают значительного распространения и становятся историей.
*Запрещенная в России организация
Hola, Amigos!
С вами Flutter-разработчик Amiga Антон Мартышков. Недавно я рассказывал о том, как создавалась кроссплатформа. Я остановился на Xamarin. Следующий в очереди React Native.
React Native — это кроссплатформенный фреймворк с открытым исходным кодом для разработки нативных мобильных и настольных приложений на JavaScript и TypeScript. Этот фреймворк разработали в Facebook, ныне Meta*. Может показаться, что React Native похожим на Cordova, но нет. Идея заключалась в том, чтобы писать все на JS, а для UI использовать нативные элементы.
Очень сложно добиться нативного поведения и отображения. Некоторые компании, например, Airbnb, вовсе устали бороться с React Native и вернулись к нативной разработке. Тем не менее, решение заняло определенную нишу в мире IT.
Вот мы и дошли до Flutter. Это комплект средств разработки и фреймворк с открытым исходным кодом для создания мобильных приложений под Android и iOS, веб-приложений, а также настольных приложений под Windows, macOS и Linux с использованием языка программирования Dart, разработанный и развиваемый корпорацией Google.
Flutter сам рисует на любой поддерживаемой платформе UI, не обращается к нативным элементам, но имитирует стандартные UI-элементы Android и iOS. Вся бизнес-логика шарится между платформами. На текущий момент одно из лучших решений для кросплатформы, активно развивается и поддерживается Google. На Flutter разработаны приложения Яндекс.GO, Google Ads, Ebay и многие другие.
Еще есть KMM — kotlin multi-platform mobile. Это решение, при котором можно шарить только бизнес-логику на языке kotlin; UI и платформозависимые вещи придётся писать и там, и там. Пока рано что либо говорить, так как проект недавно перешел в бету.
Стоит добавить, что, идеального решения не существует. Есть хорошие решения и они успешны, и есть те, кто не получают значительного распространения и становятся историей.
*Запрещенная в России организация
reactnative.dev
React Native · Learn once, write anywhere
A framework for building native apps using React
🔥9👀3👍2⚡1
Flutter vs React Native, ч.1.🧮
Hola, Amigos! На связи Антон Мартышков, Flutter-dev Amiga. Недавно рассказывал историю создания кроссплатформы и затронул Flutter и React Native. Теперь хочу рассказать о разнице двух этих популярных решениях в разработке. Сравню их по разным параметрам, а что подойдет в разработке лучше — решать вам!
1. Производительность
Flutter работает быстро, также быстро отрисовывает UI благодаря собственному языку Dart и движку отрисовки Skia. Многие вещи по скорости приближены к нативному, а иногда могут быть и быстрее. Приложения на Flutter стабильно выдают 60 кадров в секунду на подавляющем большинстве гаджетов, а на устройствах, которые поддерживают SDK, вовсе до 120 кадров.
React Native использует родные виджеты платформы, Native Views, и передает события через JavaScript. Это влияет на производительность уровня представления, поэтому производительность будет зависит от версии ОС и самого устройства. 60 кадров в секунду в целом все еще достижимы, но нужно попотеть.
Есть интересная, пусть и чуть устаревшая статья, где сравнивалась производительность готовых приложений на реальных устройствах iPhone 6 и Xiaomi Redmi Note 5.
2. Типизирование языка программирования
На Dart, язык написания Flutter, можно писать более структурный код, то есть более сложные приложения и структуры. Фанаты Java Script и React Native могут возразить, ведь у них типизированный TypeScript. Но это больше удобность для программиста, чем реальная типизированность и производительность. Под капотом TypeScript транскомпилируется в JS.
3. UI
Как я писал выше, на Flutter UI отрисовывается на собственном движке Skia. Поэтому можно быть уверенным, что он будет выглядеть одинаково на каждой поддерживаемой платформе.
React Native основан на нативных компонентах для устройств Android и iOS. Поэтому могут потребоваться доработки, на которые необходимо заложить дополнительное время разработки.
В следующем посте сравню Flutter React Native по еще 3 параметрам.
Hola, Amigos! На связи Антон Мартышков, Flutter-dev Amiga. Недавно рассказывал историю создания кроссплатформы и затронул Flutter и React Native. Теперь хочу рассказать о разнице двух этих популярных решениях в разработке. Сравню их по разным параметрам, а что подойдет в разработке лучше — решать вам!
1. Производительность
Flutter работает быстро, также быстро отрисовывает UI благодаря собственному языку Dart и движку отрисовки Skia. Многие вещи по скорости приближены к нативному, а иногда могут быть и быстрее. Приложения на Flutter стабильно выдают 60 кадров в секунду на подавляющем большинстве гаджетов, а на устройствах, которые поддерживают SDK, вовсе до 120 кадров.
React Native использует родные виджеты платформы, Native Views, и передает события через JavaScript. Это влияет на производительность уровня представления, поэтому производительность будет зависит от версии ОС и самого устройства. 60 кадров в секунду в целом все еще достижимы, но нужно попотеть.
Есть интересная, пусть и чуть устаревшая статья, где сравнивалась производительность готовых приложений на реальных устройствах iPhone 6 и Xiaomi Redmi Note 5.
2. Типизирование языка программирования
На Dart, язык написания Flutter, можно писать более структурный код, то есть более сложные приложения и структуры. Фанаты Java Script и React Native могут возразить, ведь у них типизированный TypeScript. Но это больше удобность для программиста, чем реальная типизированность и производительность. Под капотом TypeScript транскомпилируется в JS.
3. UI
Как я писал выше, на Flutter UI отрисовывается на собственном движке Skia. Поэтому можно быть уверенным, что он будет выглядеть одинаково на каждой поддерживаемой платформе.
React Native основан на нативных компонентах для устройств Android и iOS. Поэтому могут потребоваться доработки, на которые необходимо заложить дополнительное время разработки.
В следующем посте сравню Flutter React Native по еще 3 параметрам.
👍18🔥4🏆2👨💻1