Вот честно

 

Я не понимаю зачем тебе это

 

Загугли как делают file upload с апи и без сторонних сервисов (cloudinary например), и глянь в статье как они потом отдают это на фронт

 

мы видимо о разных вещах говорим))

 

мне нужен сервер с которого будет грузится клиентское приложение и в нем же будет апи

 

сложность не в апи

 

а в статических фалайх

 

[
{
"type": "link",
"text": "https://github.com/bunopus/sw-movies"
}
]

 

И в вебшторме мультипроджект настроить

 

Но статику лучше таки нжинксом

 

а где настраивается?

 

да, так и решил делать)

 

Ну например в докерфайле)

 

а я правильно понимаю, что retrofit2 еще не допилили для работы с dart?

 

как то парсить json вручную вообще не хочется(

 

Тут много вариантов, JsonSerializable один из них

 

а в чем проблема писать фронт и бек в одной папке?

 

при билде можно указать вывод куда

 

Всем бобра! Впал в думку над таким кодом в примере. Подскажите что это:
import 'ClassA.dart';

export 'ClassA.dart';

 

импортишь класс в данный файл и если этот файл где то импортится то он подтягивает класс А

 

это реально дичь у флатере, как бы и есть какие-то недогенераторы, но они тоже что-то не хотят вложенные структуры разбирать

 

ну не сказал бы что генераторы это плохо

 

С импортом понятно, экспорт как работает?

 

ну вот те нужен класс б и ты его импортишь, онзависит от а но при импорте б класс а не импортится и чт бы явно его импортировать вместе с а делаешь экспорт б а

 

я плох в обяснениях

 

это как include

 

Сорри бро, но понятнее не стало.

 

а чем именно она тебя смущает

 

о, а можно кусок кода продемонстрировать? Это на флаттере возможно к канвасу обращаться?!

 

вот пишешь ты пакет и в папке lib у тебя основной файл и папка src с частями пакета и что бы не импортить их по отдельности ссылаешся на них в основном файле через export

 

и где надо import 'package:пакет/пакет.dart'

 

и он уже включет все остальные файлы

 

есть еще вариант library пакет; part 'путь к части'; в основном и part of пакет; в частях

 

Т.е. типа фасад получается: в классе API собираем импорты+экспорты на все классы, которые понадобятся при использовании этого АРI и потом в потребителе используем их через единственный импорт класса API?

 

вот да

 

Вкурил топик! Два спасибля тебе добрый человек и килограмм барбарисок!

 

[
"сп, ",
{
"type": "link",
"text": "https://www.dartlang.org/guides/libraries/create-library-packages"
},
""
]

 

Кто собирает Flutter в CircleCI?

Или в любой другой CI-ке. Какой docker image используете?

 

Всем привет!
Подскажите, пожалуйста, как можно в флаттере вырезать часть изображения из image виджета?

 

использует кто-нибудь BLoC?

 

Конечно

 

По примерам создается впечатление, что этот подход более тродоемок, по сравнению с каким-нибудь mvc_pattern
Можете посоветовать какую-нибудь статью про BLoC, где расписывается, какие плюсы имеет этот подход? Или примеры кода эталонные на ваш взгляд

 

[
{
"type": "link",
"text": "https://pub.dartlang.org/packages/flutter_bloc"
}
]

 

[
"и ",
{
"type": "link",
"text": "https://pub.dartlang.org/packages/bloc"
},
""
]

 

Пробовал внедрить и плюнул. ScopedModel проще, понятнее, чего и вам рекомендую

 

в последнем график есть удобный

 

это же чья то левая библиотека?

 

спасибо!

 

А что это меняет?Работает стабильно.По сути это обертка над InheritedWidget как я понял

 

не люблю почему-то такие библиотеки. от автора сильно зависимость.

 

[
"лучше начинать вот отсюда ",
{
"type": "link",
"text": "https://www.dartlang.org/tutorials/language/streams"
},
""
]

 

Вообще не используешь никакие библиотеки не от флаттер тим?

 

Библиотека кстати крутая

 

flutter девелоперы в архитектурном плане пошли по пути реакта, в некотором смысле и аспекте с виджетами, отсюда и bloc паттерн, где чувствуется JS влияние

 

в реакте же есть маст хев

 

великий и нерушимый

 

маст хев?

 

редукс

 

использую конечно. когда времени мало или в проекте либа уже есть, или писать свой код сильно дольше.
просто пока хочу попробовать официальный от гугла паттерн. а там, либо библиотека загнется, либо покорит мир

 

Ну то уже по желанию, но библиотека очень простая и очень удобная. И кода для нее писать практически не надо

 

[
"по хранению состояния предлагаю ознакомиться со статьей\n",
{
"type": "link",
"text": "https://medium.com/flutter-community/let-me-help-you-to-understand-and-choose-a-state-management-solution-for-your-app-9ffeac834ee3"
},
""
]

 

был перевод на хабре вроде

 

я имел ввиду, что bloc как принцип "реактивного программирования", корый так популярен в JS.. а с реактом я сравнивал с Stateless и Statefull

 

Если читать такие статьи, то кода по менеджменту стейта получается больше чем бизнесс логики

 

Это не всегда удобно

 

редакс слишком переизбыточен

 

"Redux and BLoC, the perfect combo for me"
Автор статьи с тобой не согласен

 

Для него идеально - два самых затратных по коду стейт менеджера одновременно

 

ну у каждого есть своё мнение и своё решение

 

куда как удобнее, я по практике с редаксом из мира JS могу сказать, что почти все большие проекты на нём рано или поздно скатываются в болото

 

Тут же все должно исходить из приложения, если оно не требует мощных управлений стейтом, то я однозначно за ScopedModel. Если же приложение модульное и в планах только расширение, то да, надо смотреть на что-то мощней

 

а какая альтернатива для больших проектов тогда?

 

(особенно, когда это аутсорс проект, где забивают на архитектуру и её поддержику)

 

серебрянной пули нету, каждый пишет для себя своё пул и свои костыли, на базе ошибок и просчётов

 

Просто иногда людям кажется что у них супер пупер крутое приложение которому обязательно нужен крутой стейт менеджер, а по факту там хело ворлд

 

а на чем не скатываются?) Это вопрос организации и дисциплины и неважно, что внутри redux/mobx/unstated

 

Я пока BLoC выбрал как типа стандарт от гугла

 

всегда можно хранить все на сервере

 

просто с редаксом тоже нужно повозиться, и правильно его настраивать и использовать.. если будет >50 экшенов, >30 компонентов, туда сюда диспатчеры, сторы.. где-то забыли про имутабильность, где-то неправильно её используют, где-то тупо по ссылке меняют что-то, где-то колбэки костыляют, потому что архитектурно диспатчить экшен это перфоманс беда

 

и тп тд

 

согласен, поэтому я упомянул именно аутсорс проекты
где для бизнеса нету понятия тестов и "нужно вот тут оптимизировать и тут переписать, потому что ваш запрос меняет нашу архитектуру"

 

подскажите, flutter пока умеет только sqllite? есть поддержка других хранилищ?

 

в общем, переформулирую вопрос =)
Был ли у кого такой опыт - менеджил стейт простым способом (local state, scoped model, mobx, mvc_pattern), поимел проблем из-за этого -> перешел на BLoC и все стало хорошо? =)

 

Нет фронтенда на Dart. Не ищи решения всех задач в одном иструменте

 

а как же kotlin?)
и dart был некоторое время назад в хром
сейчас его зафорсят и вернут

 

вроде в этом году обещают web

 

Иди бизнесу расскажи это сейчас. Нафиг в вебе оно никому не уперлось сейчас. Потом может быть когда нибудь. А может и нет. Dart в хром не вернут - это тупизм. есть WASM - хотите компилируйте в wasm

 

чистый редакс не зашел, сделали где нужно доступ через Bloc

 

все стало хорошо

 

Какие хранилища тебя интересуют?

 

каким-то образом flutter испльзует iOS coredata?

 

в принципе что угодно можно подцепить, если в натив обращаться

 

из готовых плагинов только shared_preferences и sqflite

 

будет годно если из mongo mobile сделает кто-нибудь плагин

 

пока про realm room можно забыть?

 

Пока про все можно забыть чего нет и на иос и на андроиде в +- одном интерфейсе

 

ясно, тогда sqllite и остается

 

Подскажите, у меня drop down button на всю ширину экрана, как мне можно уменьшить его ширину ?

 

Запихивал в контейнер, не получается

 

Если пишете тока под иос и очень хочется, есть каналы, можно прокинуть нативные штуки во флаттер

 

нет, пишу и на iOS, но не очень хочется)
просто интересно как обстоят с этим дела во flutter

 

В первую очередь делают и будут делать универсальный код под обе платформы, что-то уникальное скорее всего только от сторонних разработчиков будет появляться

 

Что по сути логично )

 

ну это да

 

К разговору об архитектурах: BLoC не пробовал, остановился на MVU. Сейчас задумываюсь правильный ли это выбор. BLoC дает какие-то преимущества существенные, или нет смысла заморачиваться и думать о том чтобы переписывать на него?
Решают они по сути одну задачу

 

А тебя все устраивает?

 

Не очень, бойлерплейта много

 

Скорее Ангуляра... только до адекватного module providing/injectable ещё не доросли. А так - обычная реактивщина, так и под ванильный Android можно писать взяв Даггер и ObjectBox как провайдер стримов.

 

Чет мне кажется бойлерплейта будет везде много

 

google даже свою fuchsia делает на scopedmodel, и если учитывать, что врядли есть что-то более глобальное на flutter, то не думаю, что стоит заморачиваться с реактивными штуками

 

Ну и MVU это набор костылей вокруг dartea, а BLoC вроде как фреймворк в сборе с поддержкой

 

они сами писали, говорили про реакт)

 

Неважно кто исполняет роль Business Logic компонента
Блок просто название и стримы

 

там ведь помимо стримов еще компоненты с данными

 

[
"Не, редакс под Флаттер есть отдельно. Тоже, кстати хвалят. ",
{
"type": "link",
"text": "https://pub.dartlang.org/packages/flutter_redux"
},
""
]

 

Нельзя сказать что блок это тока стримы

 

Блок без стримов это scoped модел

 

вы используете чисто стримы, или rxDart юзаете?

 

[
"попробуй ",
{
"type": "link",
"text": "https://pub.dartlang.org/packages/mvc_pattern"
},
""
]

 

минимум шаблонного кода

 

Rx обертка вокруг нативных стримов

 

Кому как удобнее

 

Ну да BLoC это:
1. Неограниченное кол-во изолированных моделей стейтов
2. С изолированными событийными шинами
3. И выводом через стрим.
Больше никаких особенностей у него не видно (IMHO)

 

Получается 1 класс модели + стрим?

 

Это все?

 

Rx нужен для формирования проекций данных. Можно и без него, но:
1. Это мы так и данные будем в Map юзать как js-ники
2. А как джависту без Rx, на чем мозг в дебаге разминать если не на 500-строчных трейсах из него :)

 

Ну ещё желательно провайдер фасадом выставить. И да, здесь ключевое отличие в Redux и Flux что в них единый стор/модель для всего апп, для меня (Spring, Angular) это громоздко, негибко = неканонично!

 

для мобилы то что надо

 

Сарказм? А если в одном скрине не одну, а 2-3 http ручки дергать нужно? Провайдер становится здравым решением (IMHO)

 

хрень

 

если данные не сохраняются централизовано, это будет помойка рано или поздно

 

количество ручек http на нижних уровнях вообще не играет значения

 

для комфортной работы на flutter этой схемы требует расширения на Bloc перед уровнем Presentation

 

Таким образом ваша позиция из предиката "хрень" трансформируется в религиозное неприятие подключения к разным виджетам одного экрана разных (независимых) провайдеров данных вне зависимости от итоговой "толщины" единого стора. Хм Андроид не вы написали? Там тоже классы по 5к строк... В мою голову такие штуки целиком не помещаются :)

 

много чего писал. архитектура помогает разделять слои и не иметь файлов по 5к строк

 

при чем тут подключение “подключения к разным виджетам одного экрана разных и независимых ” я не понял

 

Привет! не подскажете, как сделать управление языками на сайте с использованием ангулардарта, какую-нибудь библиотеку или ссылку, просто не понимаю отчего отталкиваться? Спасибо

 

Единый Стор в разных слоях? Сарказм off. Реально интересно посмотреть. P.S. Ни разу Redux не юзал.

 

стор это single source of truth

 

кто его использует, в каких слоях и в каких целях никак не регламентировано

 

есть коннекторы к стейтам, есть подписка на actions и изменения

 

далее только от вас зависит как использовать

 

Мое видение архитектуры (как Ангулярщика и, скоро, Флаттерщика) такое - Реквизит:

 

это уровень представления

 

эти позиции могут быть отражены в данных совершенно по разному.
главное чтобы доступ к ним был удобный

 

Вот главная Яндекса. На ней два десятка независимых! сервисов данных, каждый из которых, имеет несколько http ручек, интерцепторов, гвардов путей, и, конечно, локальных хранилищ (если нужно). Верстальщик один, сервисы данных этого фронта напишут даже не команды разные - разные организации.

 

Никакого Главного Правдивого Стора мне не видно.

 

Реквизит

 

Какие самые лучшие уроки flutter по русски?

 

Если бы были самые лучшие, ты бы их нашел первым же запросом в гугле

 

Вопрос,

 

To introduce a MaterialLocalizations, either use a MaterialApp at the root of your application to
I/flutter (18756): include them automatically, or add a Localization widget with a MaterialLocalizations delegate.

 

Увы, но самых лучших нет по русски

 

при попытке вызова showDialog

 

ответ,

 

"use a MaterialApp at the root of your application"

 

localizationsDelegates: [
GlobalMaterialLocalizations.delegate,
GlobalWidgetsLocalizations.delegate
],supportedLocales: [Locale("en"), Locale("es"), Locale("pt")],

 

было добавлено

 

Ну тогда лучшне что есть :)

 

Лучше на англ прошерсти уроки с сайта флаттер, там не сложный англ, много примеров

 

Понял. На сколько быстрее сделать на flutter проект чем на Android natrive ? Дизайн material не сложный

 

[
"Прошел этот: ",
{
"type": "link",
"text": "https://www.udemy.com/learn-flutter-dart-to-build-ios-android-apps/"
},
""
]

 

[
"Прошел этот: ",
{
"type": "link",
"text": "https://www.udemy.com/learn-flutter-dart-to-build-ios-android-apps/"
},
" Из плюсов - хорошие субтитры, регулировка скорости, подробный. Минусы - быстрый нативный английский, архитектура апп на scoped_model (так себе но для начала - сойдет), есть косяки с версией Dart (старые mixin, например). Сложность в итоге - 7 из 10."
]

 

Я не работал с андроид натив, но мне кажется скорость сильно не будет различаться, а если ты натив знаешь то на флаттере медленней будет :)

 

Натив Java знаю средне

 

Флаттер проще думаю, но его выбирают не из-за супер быстрой скорости, а из-за того что один код пишется под две платформы сразу

 

Если тебе надо просто быстрей клепать приложения для андроида, то думаю натив тебе будет быстрей

 

Это да :) мне бы просто знать есть ли все что нужно там и нормально работает. Socket, потоки, как легко сделать верстку

 

Особенно учитывая что в андроиде есть превью скринов

 

Мне нужно и iOs что бы был :)

 

тогда у тебя выбора не много

 

По цене разработчика разница большая с Android разработчиком?

 

рынок пока не сформирован. Скорее всего андроид разраб будет получать больше за всю ту боль, что несет разработка с поддержкой версий от 4.4+

 

ты спрашиваешь про уроки по флаттеру не зная английского , но уже думаешь сколько будешь зарабатывать?

 

не дели шкуру не убитого медведя

 

Нет я просто думаю закать или самому научится

 

ну если время дорого заказывай конечно

 

Я только в этом месяце начал вообще тыкаться в мобайл: флаттер значительно проще и интуитивнее.
Изучение идет параллельно с разработкой и видимым эффектом, а не выучи 4к страниц доки и потом у тебя что-то получится)

 

хм, человек не прошедший круги ада в нативной разработке

 

речь ведь не идет о заучивании доки

 

Интуитивней чем андроид?

 

ознакомиться и попробовать надо

 

Я утрирую, но в андроиде minimal knowledge требуемый для разработки намного больше.

 

Интуитивность понятие субьективное. У меня все знакомые которые вообще не мобильщики писали под андроид на джаве, и норм, 4к доки не читали, учили по ходу нужд

 

Тем более что с человеком выше я общался, он уже знает андроид

 

У меня бэкграунд бэкенд и системная разработка

 

я подозреваю, что ты столкнешься с проблемами платформы той и другой

 

не имея опыта

 

Сложно всегда понять азы и принцип окружения, дальше все как по маслу обычно идет

 

азы во флаттере проще, это да

 

Но дальше одинаково

 

по крайней мере я с ними сталкиваюсь на android и быстро решаю, с ios сложнее

 

Дальше можно двигаться уже с видимым эффектом :)

 

Хз, посмотрим, пока не сталкивался. Это хобби, энивей.

 

не понимаю зачем лезть в flutter без понимания нативной разработки на платформах

 

Экономия времени и ресурсов

 

Очень много задач для которых не нужно знать натива

 

Куча простеньких приложений можно написать

 

Приложение простое и с нативными API не работает от слова совсем.

 

если побаловаться то норм. Для работы всеравно без натива никак. Начинать надо с любой нативной платформы, а потом уже можно трогать флаттер.

 

такого же мнения, ибо при серъезной разработке рано или поздно придется изучить натив

 

а я вот с фронтенда и с нативом не знаком