Спасибо, ценная статья. Использовал в проекте родную интернализацию, но, по мере роста проекта, пришлось самому писать скрипты для получения данных из систем перевода и синхронизации с сайтом. Смотрел в сторону easy_localization, но предложенный вами вариант нравится больше.
Это в настройках доступа к ключу в самом Google Cloud решается. Например - ваше приложение при публикации подписывается цифровой подписью. https://docs.flutter.dev/deployment/android#signing-the-app Вы можете создать правило, что доступ к API умеют только android приложения с таким-то Certificate fingerprint (SHA-1).
Через 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
Спасибо, ценная статья.
Использовал в проекте родную интернализацию, но, по мере роста проекта, пришлось самому писать скрипты для получения данных из систем перевода и синхронизации с сайтом.
Смотрел в сторону
easy_localization, но предложенный вами вариант нравится больше.Это в настройках доступа к ключу в самом Google Cloud решается.
Например - ваше приложение при публикации подписывается цифровой подписью.
https://docs.flutter.dev/deployment/android#signing-the-app
Вы можете создать правило, что доступ к API умеют только android приложения с таким-то Certificate fingerprint (SHA-1).
Спасибо, интересно.
— регистрируемся по индивидуальной трудовой деятельностиВыше привели ссылку для регистрации в налоговой. То есть можно зарегистрироваться не находясь в стране?
Через 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