Вот чем мне нравится Хабр, так это тем, что в комментах я узнаю такие нюансы теории, о которых никогда не задумалась бы самостоятельно. DI и Service Locator — разные паттерны. Есть даже отдельный пост на хабре, в котором разбираются отличия.
На странице библиотеки GetIt автор ссылается на статью Martin Fowler martinfowler.com/articles/injection.html, в которой говорится об обоих паттернах: service locator и dependency injection. И упоминается, что они могут дополнять друг друга.
Dependency injection and a service locator aren't necessarily mutually exclusive concepts.
Если посмотреть на другие библиотеки, например, Injector, который на своей странице явно говорит, что относится к dependency injection, и посмотреть примеры его использования, код будет практически такой же как в моем примере.
Вообще, пока писала этот коммент, я пролистала около 10 постов известных и не очень программистов про Dependency Injection и Service locator. В результате я могу сказать только одно с абсолютной уверенностью: речь идет об инверсии зависимостей (сокращается также DI) :)
GetIt совместим с DartSDK, так что да, действительно можно было бы применить его и в других ситуациях вне Flutter. InheritedWidget будет специфичен для Flutter, потому что виджеты.
Я не ставила задачу сравнить разные библиотеки для DI, а пример все-таки написан на Flutter, так что не соглашусь, написать «в Dart» можно, но пример бы уже к заголовку не подходил.
Предлагаете продолжить еще парой-тройкой вариаций на тему: «Dependency Injection во Flutter с помощью InheritedWidget», «Dependency Injection во Flutter с помощью Injector» и т.д. по мере поступления новых библиотек и подходов?
Я про это и говорю. Если бы проект включал в себя Bloc и внутри bloc-класса потребовалось бы обращаться к SharedPreferences, InheritedWidget был бы плохой идеей, больше подошел бы GetIt или что-то подобное.
В случае с моим примером, дополнительные библиотеки для управления состояниями не используются, так что применять InheritedWidget можно, но на мой взгляд в данном случае какую библиотеку применить — дело вкуса, мне захотелось показать GetIt, и я редко работаю без Bloc или MobX в проекте, так что можно сказать, что уже привычка
Для использования InheritedWidget потребуется context, а опять-таки если начать использование Bloc, MobX или чего-то еще для управления состояниями, то этот контекст туда пробрасывать — очень так себе идея.
Конкретно в рамках примера в статье можно было бы и обойтись InheritedWidget
Вы правы. Изначально в коде использовались Constructor Injection (кстати не везде, было и создание переменных прямо в классе). Тем не менее, в структуре виджетов специфичной для Flutter, такой подход нарушает принцип DIP (высокоуровневые модули не должны зависеть от низкоуровневых) и заставляет импортировать общие классы чуть ли не в каждый класс независимо от того, нужны они там или нет.
В результате отредактировала название поста: он про то, как пользоваться библиотеками, облегчающими использование DI.
Если упомянутые проблемы можно решить стандартными методами либы, зачем изобретать велосипед и писать свою математику? Об этом уже было сказано: «можно серьезно заняться математикой, рассчитать необходимые точки по удаленности от пользователя, затем вычислить масштаб, чтобы задать его через установку CameraPosition на CameraUpdate.newLatLngZoom(point, zoom), а можно воспользоваться функцией CameraUpdate.newLatLngBounds(bounds, areaPadding), для использования которой единственное, что нужно сделать, — определить видимый прямоугольник».
Код в репозитории показывает, как сделать так, чтобы нужно было только задать точки, которые надо отобразить, и выбрать, сколько точек отображать. И все заработает благодаря готовым методам описанного класса и MobX.
В Европе для этого есть сертификация продуктов с маркировкой eco, которые стоят дороже и продаются в специальных магазинах. У нас сама идея проверки, как обычно, провалится во взяточничество, то есть практически невозможна. Так что даже если бы проверка была, верить ей в России — так себе идея. А вот отзывы пользователей, которые купили продукт, — уже намного более надежный источник. Пестициды не покажет, но хотя бы вкусно будет. А отзывы на платформе есть и пока что не накрученные искуственно, как часто бывает на яндекс-картах например
Когда я говорила об уровне чувств, я имела в виду, что когда человек осваивает то или иное действие, оно доходит до автоматизма. Если его надо выполнить ещё раз, им занимается подсознание. Чтобы усовершенствовать свои навыки, подняться на новый уровень понимания концепта, надо заново делать это действие сознательно. Просто переписать (отрефакторить) свой код полугодовой, например, давности не поможет. Ради интереса посмотрела код из своего репозитория, который не обновлялся год. Нормальный код, ничего такого особенного. Нечего мне там рефакторить. Можно сделать красивее с применением других паттернов, можно новый функционал добавить, но вот в рамках того же mvvm делать нечего. Поэтому, чтобы что — то поменять в восприятии, нужен другой человек. С кем можно поговорить о самой сути концепта, например интервьюер.
Спасибо за дополнительные разъяснения по hot reload. Пожалуй ни разу не видела достаточно полного описания этого вопроса. Мне кажется, здесь ещё стоит упомянуть, а чего собственно ради аж целых два метода ускоренного обновления приложения на устройстве появились. На 8ядерном Mac pro разница при построении приложения для Андроид и Hot reload вместе с hot restart 5-15 секунд (конечно есть первый запуск, который дольше), iOS строится в целом дольше. На Mac book air разница будет уже намного более ощутимой. Я бы предположила: 30-60 секунд, и для первого построения iOS билда можно пойти пить чай. Если у вас мощное железо и вам не хочется вникать, есть в новой библиотеке платформенный код или нет, останутся ли после перезапуска какие — нибудь артефакты от предыдущего состояния приложения или нет, то почему бы не перезапустить приложение полностью? А вот когда разница во времени перезапуска действительно будет существенной, имеет смысл уделять внимание способу обновления. То есть вопрос на самом деле сводится к экономии времени разработчика, которое при обычном перезапуске достаточно ощутимо тратится в никуда
Запустить на эмуляторе айфона например можно на основе инструкции по установке Флаттера тут . Просто это первые шаги по установке, про них потом никто не пишет.
Подразумевается, что вы это в самом начале сделали, потом в андроид студии проект создали, поредактировали, выбрали в списке (куда запустить) айфон и оно работает. Там даже запускать потом XCode не надо
Вы именно редактировать проект в XCode хотели? Не думаю, что это комфортно… Все-таки вроде как для этого Андроид студия с плагинами для флаттер и дарт нужна. Хотя по большому счету она тоже не нужна, достаточно текстового редактора.
Что-то общее сейчас наверное есть у всех технологий. Разница в том, насколько легко технологию использовать, что потребуется на стороне пользователя и будет ли практика использования похожа на привычную. Насколько я помню, Flash можно было превратить в приложение для телефона, но в нативный код он-таки не компилировался
Поддержки facebook sdk и twitter sdk напрямую нет. Можно легко использовать facebook login и twitter login (как отдельную фичу или в составе firebase login. Вопрос немного некорректен. HTTP-запросы никто не отменял, делайте на здоровье и используйте facebook как вам нравится, но простой обертки для этой функциональности пока нет. Можно написать свою библиотеку. Тем более Гугл набирает Flutter-разработчиков. Напишете, а потом сразу резюме в Гугл и на работу :)
Мне кажется тут скорее вопрос насколько продвинутым захочет быть дизайнер. Если анимация будет восприниматься как конкурентное преимущество приложения (которое действительно создаст разницу между двумя функционально похожими приложениями), то будет спрос на дизайнеров, которые умеют Flare. Или на программистов, которые умеют делать анимации из psd ;-)
Когда я продумываю новое приложение для себя, я часто смотрю готовые работы и конкурсы UI/UX типа uplabs.com, там много красивого, в том числе и анимации. Я думаю сейчас я смогу реализовать оттуда немного больше, чем было для меня возможно на нативной платформе
Вы говорите "выглядит костыльно", а приложения (реальные приложения на флаттер) вы устанавливали? Разработчики не говорили, что будет выглядеть все 100% как если бы вы вставили тот же переключатель из стандартного пакета виджетов андроид без добавления стиля. У них фишка в лёгкости стилизации. Сейчас чаще всего заказчик сначала просит дизайнера нарисовать UI/UX, а потом разработчик думает, как же эту картинку натянуть на вот эти вот стандартные элементы. Собственный рендер нужен был как раз чтобы от костылей при создании приложения уйти и чтобы добиться 60 fps при отрисовке
Вот чем мне нравится Хабр, так это тем, что в комментах я узнаю такие нюансы теории, о которых никогда не задумалась бы самостоятельно. DI и Service Locator — разные паттерны. Есть даже отдельный пост на хабре, в котором разбираются отличия.
На странице библиотеки GetIt автор ссылается на статью Martin Fowler martinfowler.com/articles/injection.html, в которой говорится об обоих паттернах: service locator и dependency injection. И упоминается, что они могут дополнять друг друга.
Если посмотреть на другие библиотеки, например, Injector, который на своей странице явно говорит, что относится к dependency injection, и посмотреть примеры его использования, код будет практически такой же как в моем примере.
Вообще, пока писала этот коммент, я пролистала около 10 постов известных и не очень программистов про Dependency Injection и Service locator. В результате я могу сказать только одно с абсолютной уверенностью: речь идет об инверсии зависимостей (сокращается также DI) :)
Я не ставила задачу сравнить разные библиотеки для DI, а пример все-таки написан на Flutter, так что не соглашусь, написать «в Dart» можно, но пример бы уже к заголовку не подходил.
В случае с моим примером, дополнительные библиотеки для управления состояниями не используются, так что применять InheritedWidget можно, но на мой взгляд в данном случае какую библиотеку применить — дело вкуса, мне захотелось показать GetIt, и я редко работаю без Bloc или MobX в проекте, так что можно сказать, что уже привычка
Конкретно в рамках примера в статье можно было бы и обойтись InheritedWidget
В результате отредактировала название поста: он про то, как пользоваться библиотеками, облегчающими использование DI.
Код в репозитории показывает, как сделать так, чтобы нужно было только задать точки, которые надо отобразить, и выбрать, сколько точек отображать. И все заработает благодаря готовым методам описанного класса и MobX.
Когда я говорила об уровне чувств, я имела в виду, что когда человек осваивает то или иное действие, оно доходит до автоматизма. Если его надо выполнить ещё раз, им занимается подсознание. Чтобы усовершенствовать свои навыки, подняться на новый уровень понимания концепта, надо заново делать это действие сознательно. Просто переписать (отрефакторить) свой код полугодовой, например, давности не поможет. Ради интереса посмотрела код из своего репозитория, который не обновлялся год. Нормальный код, ничего такого особенного. Нечего мне там рефакторить. Можно сделать красивее с применением других паттернов, можно новый функционал добавить, но вот в рамках того же mvvm делать нечего. Поэтому, чтобы что — то поменять в восприятии, нужен другой человек. С кем можно поговорить о самой сути концепта, например интервьюер.
Спасибо за дополнительные разъяснения по hot reload. Пожалуй ни разу не видела достаточно полного описания этого вопроса. Мне кажется, здесь ещё стоит упомянуть, а чего собственно ради аж целых два метода ускоренного обновления приложения на устройстве появились. На 8ядерном Mac pro разница при построении приложения для Андроид и Hot reload вместе с hot restart 5-15 секунд (конечно есть первый запуск, который дольше), iOS строится в целом дольше. На Mac book air разница будет уже намного более ощутимой. Я бы предположила: 30-60 секунд, и для первого построения iOS билда можно пойти пить чай. Если у вас мощное железо и вам не хочется вникать, есть в новой библиотеке платформенный код или нет, останутся ли после перезапуска какие — нибудь артефакты от предыдущего состояния приложения или нет, то почему бы не перезапустить приложение полностью? А вот когда разница во времени перезапуска действительно будет существенной, имеет смысл уделять внимание способу обновления. То есть вопрос на самом деле сводится к экономии времени разработчика, которое при обычном перезапуске достаточно ощутимо тратится в никуда
Подразумевается, что вы это в самом начале сделали, потом в андроид студии проект создали, поредактировали, выбрали в списке (куда запустить) айфон и оно работает. Там даже запускать потом XCode не надо
Вы именно редактировать проект в XCode хотели? Не думаю, что это комфортно… Все-таки вроде как для этого Андроид студия с плагинами для флаттер и дарт нужна. Хотя по большому счету она тоже не нужна, достаточно текстового редактора.
Мне кажется тут скорее вопрос насколько продвинутым захочет быть дизайнер. Если анимация будет восприниматься как конкурентное преимущество приложения (которое действительно создаст разницу между двумя функционально похожими приложениями), то будет спрос на дизайнеров, которые умеют Flare. Или на программистов, которые умеют делать анимации из psd ;-)
Когда я продумываю новое приложение для себя, я часто смотрю готовые работы и конкурсы UI/UX типа uplabs.com, там много красивого, в том числе и анимации. Я думаю сейчас я смогу реализовать оттуда немного больше, чем было для меня возможно на нативной платформе
Вы говорите "выглядит костыльно", а приложения (реальные приложения на флаттер) вы устанавливали? Разработчики не говорили, что будет выглядеть все 100% как если бы вы вставили тот же переключатель из стандартного пакета виджетов андроид без добавления стиля. У них фишка в лёгкости стилизации. Сейчас чаще всего заказчик сначала просит дизайнера нарисовать UI/UX, а потом разработчик думает, как же эту картинку натянуть на вот эти вот стандартные элементы. Собственный рендер нужен был как раз чтобы от костылей при создании приложения уйти и чтобы добиться 60 fps при отрисовке