Через 10+15 лет эти девочки-инстаблонгеры обрастут жиром и морщинами и внезапно никому будет больше не нужны, останутся у разбитого корыта
Не все так линейно и просто. Это такая же, быть может в будущем, даже более востребованная чем программирование, профессия. У нас мозг уже не сможет решать сложные задачи и осваивать условное квантовое программирование. А девочки с морщинами будут вести аккаунты как оставаться молодыми, как развлекаться в старости, как ... и т.п.
Похоже и я вас теперь понял :)
Будем ждать новых статей. Было бы круто приложить простейшее приложение-пример, убирает кучу вопросов сразу и предмет обсуждения появляется.
Я тоже все не могу выделить время, написать как раз про push'ы — пример как показать уведомление с данными, перекинуть куда надо и т.п.
Можно написать два приложения на 2 примерах (я на getx), если интересно, то меня бы это мотивировало для статьи.
Я не соглашусь, но наверное я непонятно пишу вопрос.
Моя точка зрения в том, что BLoC, Redux, Mobx, Getx — это инструменты (подходы, паттерны) для управления состоянием приложения.
Например в случае с пушем — пришел пуш, в нем есть данные, нам надо:
1. отобразить пуш с картинкой
2. потом юзер нажал
— надо получать данные, менять состояние интерфейса.
Соответственно это всё живет в бизнес логике. А как это разруливать — есть типовые варианты.
Мы в проектах пробовали BLoC и Getx. Не скрещивали, а в разных проектах разные паттерны.
Сугубо личное мнение — Getx позволяет убрать кучу бойлеплейта, делает код более понятным и читаемым.
И еще раз спасибо — не хватает таких статей, где суммирован реальный опыт.
А вот тут, displayError у вас где живет? Вы в него передаете context чтобы отобразить всплывающее сообщение, правильно?
Интересно как вы отделяете код сообшений, я в свое время не смог его разумно выделить в контроллеры без контекста.
То есть реального decoupling с UI у меня не получилось. Поэтому любопытно :)
А, понял, все таки приходится туда-сюда context передавать. Мне как-то очень криво показалось все время так делать.
Из-за этого в наших проектах мы перешли с BLoC на Getx — до сих пор глядя на код блоков радуюсь переходу, код на Getx получается элегантнее.
Это личное мнение, просто хотел поделиться, вдруг зайдет вам тоже.
А мы уже год на Hive (я автор той статьи) и очень довольны.
Для случаев небольшого кеша — идеально.
Плюс удобная кодогенерация, которая хорошо скрещивается с json_serializable.
Экономит огромное количество времени.
Хотя, конечно, для сложных баз лучше использовать другие варианты. Но sqflite как то совсем не зашел.
Как там объяснил Filip Hracek:
Когда Dart определяет, что переменная non-nullable, то эта переменная считается всегда non-nullable. В случае non-sound null safety это не так и надо делать дополнительные проверки во время выполнения кода. Поэтому в варианте sound null safety код выполняется быстрее.
Быть может не по теме вопрос — а почему вы на pub.dev не выкладываете SurfGear?
Просто там все заточено под работу с пакетами, сразу проверка есть + это навсегда, не надо волноваться, что репозиторий может исчезнуть.
Спасибо за статью, интересно было почитать.
У меня в проекте тоже плотно используется keyboard_visibility. Почему то работает :)
Flutter doctor
[✓] Flutter (Channel stable, 1.22.4, on macOS 11.0.1 20B29 darwin-x64, locale en-RU)
• Flutter version 1.22.4 at /Users/macbook/development/flutter
• Framework revision 1aafb3a8b9 (7 days ago), 2020-11-13 09:59:28 -0800
• Engine revision 2c956a31c0
• Dart version 2.10.4
[!] Android toolchain — develop for Android devices (Android SDK version 30.0.2)
• Android SDK at /Users/macbook/Library/Android/sdk
• Platform android-30, build-tools 30.0.2
• Java binary at: /Applications/Android Studio 4.2 Preview.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
✗ Android license status unknown.
Run `flutter doctor --android-licenses` to accept the SDK licenses.
See flutter.dev/docs/get-started/install/macos#android-setup for more details.
[✓] Xcode — develop for iOS and macOS (Xcode 12.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 12.1, Build version 12A7403
• CocoaPods version 1.9.3
Спасибо за статью.
В реальных проектах я обычно использую pub.dev/packages/json_annotation
который сделан как раз при помощи built_value
Если посмотреть обучалки по Flutter, то команда рекомендует использовать его, так как для json он удобнее.
Удобнее добавлять вложенные классы (которые автоматически на любой уровень вложенности десериализуются), Enums, поверх удобно оборачивать другими сериализаторами.
Вот тут подробно от команды Flutter flutter.dev/docs/development/data-and-backend/json
Execution flow with async and await
An async function runs synchronously until the first await keyword. This means that within an async function body, all synchronous code before the first await keyword executes immediately.
— регистрируемся по индивидуальной трудовой деятельностиВыше привели ссылку для регистрации в налоговой. То есть можно зарегистрироваться не находясь в стране?
Через 10+15 лет эти девочки-инстаблонгеры обрастут жиром и морщинами и внезапно никому будет больше не нужны, останутся у разбитого корыта
Не все так линейно и просто.
Это такая же, быть может в будущем, даже более востребованная чем программирование, профессия.
У нас мозг уже не сможет решать сложные задачи и осваивать условное квантовое программирование.
А девочки с морщинами будут вести аккаунты как оставаться молодыми, как развлекаться в старости, как ... и т.п.
medium.com/flutter/whats-new-in-flutter-2-0-fe8e95ecc65
Будем ждать новых статей. Было бы круто приложить простейшее приложение-пример, убирает кучу вопросов сразу и предмет обсуждения появляется.
Я тоже все не могу выделить время, написать как раз про push'ы — пример как показать уведомление с данными, перекинуть куда надо и т.п.
Можно написать два приложения на 2 примерах (я на getx), если интересно, то меня бы это мотивировало для статьи.
Я не соглашусь, но наверное я непонятно пишу вопрос.
Моя точка зрения в том, что BLoC, Redux, Mobx, Getx — это инструменты (подходы, паттерны) для управления состоянием приложения.
Например в случае с пушем — пришел пуш, в нем есть данные, нам надо:
1. отобразить пуш с картинкой
2. потом юзер нажал
— надо получать данные, менять состояние интерфейса.
Соответственно это всё живет в бизнес логике. А как это разруливать — есть типовые варианты.
Мы в проектах пробовали BLoC и Getx. Не скрещивали, а в разных проектах разные паттерны.
Сугубо личное мнение — Getx позволяет убрать кучу бойлеплейта, делает код более понятным и читаемым.
И еще раз спасибо — не хватает таких статей, где суммирован реальный опыт.
По логике пушей, при открытом приложении они не отображаются в панели телефона, их должно отобразить приложение.
Вот у нас висит listener, он получил пуш уведомление.
В случае когда мы используем Get, мы просто без контекста выводим сообщение, прямо из контроллера:
Get.snackbar('title', 'body');В случае с BLoC не получалось так просто и понятно делать. Приходилось передавать контекст и как-то сильно мудрить. Уже точно не помню все нюансы.
Интересно как вы отделяете код сообшений, я в свое время не смог его разумно выделить в контроллеры без контекста.
То есть реального decoupling с UI у меня не получилось. Поэтому любопытно :)
return BlocConsumer<MessagesBloc, MessagesState>(listener: (context, state) {
state.threadsUpdatingState.maybeWhen(error: (e) => displayError(context, e), orElse: ignore);
},
Из-за этого в наших проектах мы перешли с BLoC на Getx — до сих пор глядя на код блоков радуюсь переходу, код на Getx получается элегантнее.
Это личное мнение, просто хотел поделиться, вдруг зайдет вам тоже.
А как вы работаете с BLoC и контекстом когда нужно вызвать какие-либо всплывающие элементы, например snackbar?
Для случаев небольшого кеша — идеально.
Плюс удобная кодогенерация, которая хорошо скрещивается с json_serializable.
Экономит огромное количество времени.
Хотя, конечно, для сложных баз лучше использовать другие варианты. Но sqflite как то совсем не зашел.
Как там объяснил Filip Hracek:
Когда Dart определяет, что переменная non-nullable, то эта переменная считается всегда non-nullable. В случае non-sound null safety это не так и надо делать дополнительные проверки во время выполнения кода. Поэтому в варианте sound null safety код выполняется быстрее.
Просто там все заточено под работу с пакетами, сразу проверка есть + это навсегда, не надо волноваться, что репозиторий может исчезнуть.
У меня в проекте тоже плотно используется keyboard_visibility. Почему то работает :)
• Flutter version 1.22.4 at /Users/macbook/development/flutter
• Framework revision 1aafb3a8b9 (7 days ago), 2020-11-13 09:59:28 -0800
• Engine revision 2c956a31c0
• Dart version 2.10.4
[!] Android toolchain — develop for Android devices (Android SDK version 30.0.2)
• Android SDK at /Users/macbook/Library/Android/sdk
• Platform android-30, build-tools 30.0.2
• Java binary at: /Applications/Android Studio 4.2 Preview.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
✗ Android license status unknown.
Run `flutter doctor --android-licenses` to accept the SDK licenses.
See flutter.dev/docs/get-started/install/macos#android-setup for more details.
[✓] Xcode — develop for iOS and macOS (Xcode 12.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 12.1, Build version 12A7403
• CocoaPods version 1.9.3
В реальных проектах я обычно использую pub.dev/packages/json_annotation
который сделан как раз при помощи built_value
Если посмотреть обучалки по Flutter, то команда рекомендует использовать его, так как для json он удобнее.
Удобнее добавлять вложенные классы (которые автоматически на любой уровень вложенности десериализуются), Enums, поверх удобно оборачивать другими сериализаторами.
Вот тут подробно от команды Flutter
flutter.dev/docs/development/data-and-backend/json