Немного слов про платежные системы android и ios (In-app-purchases)

Проблема: плагин in_app_purchase работает странно. Разработчики flutter уже давно забили на этот пакет и, видимо не поддерживают его должным образом. Я реализовал это еще до того, как узнал, что плагин нормально не поддерживается. Не смотря на это, он периодически обновляются, но обновляются версии dart и описание. У них также на github висит тикет с проблемой на ios, с которой я и столкнулся. Если на ios произвести покупку подписки, то ее нельзя будет завершить, вызвав completePurchase и эта подписка попадает в бесконечный цикл, завершить ее нет возможности, причем если вы до этого тестировали и не завершали, вас просто закидает в стриме этими подписками. Тикет висит уже 2 года кажется.

Решение: использовать плагин purchases_flutter, основанный на revenuecat. Он имеет содержательную документацию и если вам не нужна логика на беке, использующая данные о покупках, то можно обойтись вообще без реализации на беке. Однако если необходимость есть, то там у них есть удобный rest api для проверки состояния подписки. Рекомендую, пользуйтесь.

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

Мораль: нельзя никому верить! Даже мне.

Я начал мейнтейнить библиотеку yandex_mapkit_community

Зачем?
Дело в том, что официальной поддержки яндекс карт для flutter нет. Однако, какой-то энтузиаст сделал частичную реализацию библиотеки (yandex_mapkit), которой мы могли бы пользоваться, если бы не одно но.
Проблема заключается в том, что автор этой библиотеки не поддерживал ее на протяжении 8 месяцев. Библиотека довольно сырая и имеет много детских болячек.
У меня появился проект, в котором заказчику очень хочется, чтобы мы использовали яндекс карты, однако в процессе реализации все проблемы этой библиотеки раскрылись во всей красе. Я сделал свой форк этой библиотеки.

Как просто репозиторий превратился в библиотеку на pub.dev?
Сидел я значит как-то в чатике флаттеристов и речь зашла за гугл и яндекс карты. Челу начали советовать забить на гугл карты (у него что-то не получалось с ними) и взять яндекс карты. В этот момент мне хотелось высказать всю боль, что я испытал и какой путь проделал, чтобы встроить эти карты к себе в приложение и мне подали идею опубликовать свои доработки на pub.dev.

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

Какие планы на библиотеку?
Я люблю флаттер и хочу, чтобы комьюнити продолжало свое развитие. Есть идея-фикс, что можно было бы реализовывать библиотеки используя ffi и не делать пробросы через method channel'ы. Было бы круто для начала сделать просто пробросы в основную библиотеку, а после пытаться частично интегрировать в библиотеку вызовы c++ кода вместо вызовов к платформе. Ну а сейчас, хотелось бы видеть цельную, продуманную библиотеку, за которую не было бы стыдно.

А теперь прЕкол
Спусть 15 часов после публикации моей библиотеки вдруг проснулся автор старой (yandex_mapkit) и судорожно начал публиковать изменения и сливать pull request'ы. Он сделал обновление основной публикации, поправил линтер.
Несмотря на то, что автор очнулся, я считаю, что забросил пакет один раз, он забросит его снова. Поэтому тут скорее игра в долгую.

Ссылка на мою библиотеку: https://pub.dev/packages/yandex_mapkit_community

Спасибо, всех люблю ❤️

В чатике флаттеристов прислали интересную статью про setState. Если вы задавались вопросом, зачем нужен callback внутри этой функции, то вам сюда)

Интересно, что разработчики флаттер реально проводили исследования, как используют их api. Неужели разработчики тоже люди, а не андроиды?

https://habr.com/ru/articles/745726/

Сейчас читаю DDD, там упоминается паттерн “спецификация”, переписал пример из книги. Подразумевается, что у химикатов (бочек с ними) есть требование к перевозке (specification). И оно регламентируется с помощью отдельного класса, с которым потом взаимодействует контейнер при проверке безопасности упаковки химикатов.

Что думаете?
👍 - интересный паттерн, стоит попробовать применить
👎 - нижнеспособная хрень
🤡 - я бы еще примеры посмотрел

"... моя лень проявляется в том, что я не запоминаю деталей кода, который пишу. Более того, опасаясь перегрузить свою голову, я умышленно не запоминаю многие детали. И поэтому я стараюсь записывать в коде всё, что иначе мне пришлось бы держать в моей бедной голове. Это позволяет мне не беспокоиться о воздействии пары бокалов пива после работы на клетки моего головного мозга" — Мартин Фаулер

😁

Что выведет этот код?

Flutter схлестнулся с Нативом в чемпионате DigitalSkills в Казани

8 участников
7 - натив андроид,
1 - Флюттер

Итог такой:
1. Андроид
2. Флюттер
3. Андроид
…
8. Андроид

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

Хоть это и совсем нерепрезентативно

Утренняя разминка!

Почему НЕ надо использовать Bang operator

А вот и лайтовая разминочка для утречка пятницы подъехала

Реализация паттерна “Спецификация” на dart

Нашел примение этого паттерна в скоринге кредитных заявок: к клиенту предъявляются требования, как сумме и продолжительности кредита тоже.

Читается это необычно, будто бы читаю СпЕцИфИкАцИю к тому, кому выдавать кредит

Исходный код

Постпятничная задачка на утро)

Early return pattern упростит вашу жизнь

Суть паттерна в том, чтобы досрочно завершать функцию, вместо того, чтобы писать else.

В примере приведен реальный код из dart’а

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

Мысль у меня такая: если у вас появилась необходимость вложить if в if или дописать else в вашей функции, значит вы что-то делаете не так. Вернитесь на шаг назад и переосмыслите, может быть надо вынести метод? Или дело в концепции?

Затестил новый импеллер в Flutter 3.16, разочаровало.