Возможно я как то не правильно выразился но state это не модель, это состояние виджета в котором мы храним список, модель это бизнес логика реализацию которой я в данном примере опустил, это может быть что угодно, от хранения в бд, до внешнего сервиса, по сути тут реализованы view и viewModel
И объявлен класс модели ToDoItem
Предполагается что мы будем в момент инициализации виджета дёргать во вьюмодел нужный нам репозиторий и получать данные для отображения, а при выполнении команд сохранять изменения.
Provider тут очень удобен, в целом не только ради проброса зависимости в View, но и юзать модель верхнего уровня ниже по дереву.
Кстати спасибо за идею, думаю осветить в следующей статье, как раз работу с бд, имеется определенный опыт, вот думаю что новичкам он может оказаться полезен, набрался из разных статей. А вот идея с подзадачами, как раз сюда ложится.
В данном примере, я и не пытался реализовать WPF на Flutter, а лишь концепцию MVVM подручными средствами.
Да нет всех элементов полноценной MVVM, но есть основные. Команды есть это методы вызываемые из view, которые находятся во viewModel : добавление, удаление, переключение.
Реализация простая, можно сказать упрощенная - для новичков, которая позволяет сделать более удобное управление состоянием виджетов
Ну я и не утверждаю, что это серебряная пуля. И ни в коем случае не собираюсь оспаривать мнение Феликса:-) Это просто реализация паттерна, которая помогла мне его понять и на ее основе реализовать одно из наших решений :-)
вырвусь из стереотипов =) спасибо за информацию, оказалась полезной, особенно когда работаешь с разных компов, удобно когда все личные команды на сборку генерацию со своими параметрами и настройками находятся прямо в проекте =)
как и сказал автор в одном из комментариев не многие знают все возможности инструментов с которыми работают
теперь к преднастройкам среды для проекта (extensions.json, launch.json, settings.json) добавились и таски =)
вопрос, зачем используете разные main? много логики завязанной на стенды? мы раньше так-же делали сейчас вышли из положения использовав директиву --dart-define для указания конфига, на каждый стенд
flutter build apk --flavor googlePlay --dart-define=config=prod эта к примеру собирает прод апк
От себя же хочу добавить, что о Kivy узнал только что, а флаттер на слуху, возможно дело в том что kivy разрабатывает сообщество, а flutter это openSource разработанный, продвигаемый и поддерживаемый Google. Так что да Вы правы продвинуть его получилось однозначно лучше.
У webView есть определенные проблемы с производительностью графики
С xamarin работал только давно, и он имел тогда кучу ограничений, формс не давал необходимой гибкости кастомизации а нативный ui убивал кроссплатформенность
на самом деле 3/4 это с учетом погружения в технологию, первый опыт первого приложения
по факту экономия порядка 30% по мнению более опытных команд, достигается за счет того что тестировать и выкатывать то все равно надо 2 приложения а разрабатывать по сути одно приложение одной командой =)
если увеличить количество платформ, то все равно добавится тестирование и выкладка на них, но не будет затрат на разработку, это да
«Недоделанность» присутствует это факт, ибо есть вещи, которые в Core и в Framework, работают по разному. По началу было сложно с Ef, но потом втянулся:-) и ещё остаются вещи которые ещё не переписаны к сожалению, но уже есть так-же механизмы которые есть только в Core. И все новое что появляется в Framework идёт из Core.
Тут это для упрощения, естественно mvc это архитектурный паттерн =), но у MS есть и технология — ASP.Net MVC, в рамках которой и идет разработка на SF.
Насчет ORM можно конкретнее? =)
Если работать в ней, то все работает как часы, если пытаться лезть в БД, то будут сложности =)
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
лаконично и понятно в целом.
Жаль о стримах ни слова, жду 2-ю часть
Возможно я как то не правильно выразился но state это не модель, это состояние виджета в котором мы храним список, модель это бизнес логика реализацию которой я в данном примере опустил, это может быть что угодно, от хранения в бд, до внешнего сервиса, по сути тут реализованы view и viewModel
И объявлен класс модели ToDoItem
Предполагается что мы будем в момент инициализации виджета дёргать во вьюмодел нужный нам репозиторий и получать данные для отображения, а при выполнении команд сохранять изменения.
Provider тут очень удобен, в целом не только ради проброса зависимости в View, но и юзать модель верхнего уровня ниже по дереву.
Кстати спасибо за идею, думаю осветить в следующей статье, как раз работу с бд, имеется определенный опыт, вот думаю что новичкам он может оказаться полезен, набрался из разных статей. А вот идея с подзадачами, как раз сюда ложится.
В данном примере, я и не пытался реализовать WPF на Flutter, а лишь концепцию MVVM подручными средствами.
Да нет всех элементов полноценной MVVM, но есть основные. Команды есть это методы вызываемые из view, которые находятся во viewModel : добавление, удаление, переключение.
Реализация простая, можно сказать упрощенная - для новичков, которая позволяет сделать более удобное управление состоянием виджетов
Ну я и не утверждаю, что это серебряная пуля. И ни в коем случае не собираюсь оспаривать мнение Феликса:-) Это просто реализация паттерна, которая помогла мне его понять и на ее основе реализовать одно из наших решений :-)
Для небольшой команды, вполне жизнеспособно :-)
вырвусь из стереотипов =) спасибо за информацию, оказалась полезной, особенно когда работаешь с разных компов, удобно когда все личные команды на сборку генерацию со своими параметрами и настройками находятся прямо в проекте =)
как и сказал автор в одном из комментариев не многие знают все возможности инструментов с которыми работают
теперь к преднастройкам среды для проекта (extensions.json, launch.json, settings.json) добавились и таски =)
вопрос, зачем используете разные main? много логики завязанной на стенды? мы раньше так-же делали сейчас вышли из положения использовав директиву --dart-define для указания конфига, на каждый стенд
flutter build apk --flavor googlePlay --dart-define=config=prod эта к примеру собирает прод апк
Согласен с Вашим мнением
слушай, а стало интересно, а можно определить на вебе мобила на ios или на android?
было бы классно менять интерфейс в зависимости от целевой платформы, даже через веб, но по идее конечно это лишнее
=)
Ооо, я эти платформы ещё не юзал, спасибо за информацию
Да спасибо, это и имел ввиду
Не хочу разжигать войн, но один из разработчиков kivyMD в статье на хабре указал что flutter быстрее чем kivy для мобильных платформ.
https://habr.com/ru/post/546684/
От себя же хочу добавить, что о Kivy узнал только что, а флаттер на слуху, возможно дело в том что kivy разрабатывает сообщество, а flutter это openSource разработанный, продвигаемый и поддерживаемый Google. Так что да Вы правы продвинуть его получилось однозначно лучше.
У webView есть определенные проблемы с производительностью графики
С xamarin работал только давно, и он имел тогда кучу ограничений, формс не давал необходимой гибкости кастомизации а нативный ui убивал кроссплатформенность
ну ionic и другие Web-фреймворки рендерят пользовательский интерфейс на WebView,
тут скорее про другое, никто не мешает для IOS делать ui на Cupertino widgets, а для Android на Material
просто у приложений будет общий UI слой, так-же это полезно когда стиль приложения не привязан к гайдлайну IOS/Android
зато благодаря движку flutter может гарантировать одинаковую работу приложения на всех версиях OS устройств
на самом деле 3/4 это с учетом погружения в технологию, первый опыт первого приложения
по факту экономия порядка 30% по мнению более опытных команд, достигается за счет того что тестировать и выкатывать то все равно надо 2 приложения а разрабатывать по сути одно приложение одной командой =)
если увеличить количество платформ, то все равно добавится тестирование и выкладка на них, но не будет затрат на разработку, это да
«Недоделанность» присутствует это факт, ибо есть вещи, которые в Core и в Framework, работают по разному. По началу было сложно с Ef, но потом втянулся:-) и ещё остаются вещи которые ещё не переписаны к сожалению, но уже есть так-же механизмы которые есть только в Core. И все новое что появляется в Framework идёт из Core.
Насчет ORM можно конкретнее? =)
Если работать в ней, то все работает как часы, если пытаться лезть в БД, то будут сложности =)