Возможно я как то не правильно выразился но 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 можно конкретнее? =)
Если работать в ней, то все работает как часы, если пытаться лезть в БД, то будут сложности =)
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Вот блин )) утром еще не было ))) ща появилось, ок потестим, спасибо
Функция не доступна на iPhone… второй анонс, но нигде не слова что фичу зарелизили канарейкой .. не на всех пользователей …
Вы уж либо делайте анонс когда будет полный релиз, либо указывайте что оно не работает у части пользователей…
Грустно :-(
А если реализация от интерфейса разделена слоями? Как быть?)Все вопрос отпал
лаконично и понятно в целом.
Жаль о стримах ни слова, жду 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 можно конкретнее? =)
Если работать в ней, то все работает как часы, если пытаться лезть в БД, то будут сложности =)