14. Да живи ты хоть три тысячи лет, хоть тридцать тысяч, только помни, что человек никакой другой жизни не теряет, кроме той, которой жив; и живет лишь той, которую теряет. Вот и выходит одно на одно длиннейшее и кратчайшее. Ведь настоящее у всех равно, хотя и не равно то, что утрачивается; так оказывается каким-то мгновением то, что мы теряем, а прошлое и будущее терять нельзя, потому что нельзя ни у кого отнять то, чего у него нет. Поэтому помни две вещи. Первое, что все от века единообразно и вращается по кругу, и безразлично, наблюдать ли одно и то же сто лет, двести или бесконечно долго. А другое, что и долговечнейший и тот, кому рано умирать, теряет ровно столько же. Ибо настоящее — единственное, чего они могут лишиться, раз это и только это, имеют, а чего не имеешь, то нельзя потерять.
Далее Марка Аврелия логично почитать наверное, лично мне он проще воспринимался.
Gemini API. Мощный инструмент для детального контроля над анимацией виджетов. Он не только открывает новые возможности для творчества, но и повышает качество взаимодействия с пользователем в приложениях Flutter.
Спасибо, ценная статья. Использовал в проекте родную интернализацию, но, по мере роста проекта, пришлось самому писать скрипты для получения данных из систем перевода и синхронизации с сайтом. Смотрел в сторону 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 как то совсем не зашел.
Далее Марка Аврелия логично почитать наверное, лично мне он проще воспринимался.
хм )
В растительном масле 0% трансжиров. Даже в маргарине старого типа столько нет (новые делают без трансжиров тоже)
запутался с интерфейсом ;)
Спасибо, интересно.
Вот тут опечатка
английского слова «serf», правильно surf.Интересно, а по общему размеру есть ограничения? Например если отправить 900 000 сообщений по 4 гига?
Спасибо, ценная статья.
Использовал в проекте родную интернализацию, но, по мере роста проекта, пришлось самому писать скрипты для получения данных из систем перевода и синхронизации с сайтом.
Смотрел в сторону
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 как то совсем не зашел.