Вы использовали хаб Flutter чтобы люди которые подписаны на хаб узнали об:
В этой статье я расскажу, как мы решили проблему так называемого «белого экрана», вызванного «не определенным» методом в старых версиях webView (размонтирование всего дерева React) в SPA приложении на React, внутри мобильного приложения написанного на Flutter.
Простите но это единственная инфа во всей статье об Flutter...
При всем уважении, использовать Flutter на сервере это очень сомнительная идея.
А никто не говорить про Flutter на сервере ;) Там первая библиотека которая работает с api написана на чистом dart'е, а dart можно спокойно поднять на сервере.
Хотя должен быть 'Complete3DSMethodV2'
Хм, похоже поменяли, спасибо передам чтобы проверили.
Да, не описан, но не зря мы его делили на два пакета. И да такой сценарий рабочий, это по сути фасад над api.
CollectData нужен для проверки клиента при проверки 3DSv2 (если карта поддерживается) через мета данные. Если клиент подтверждается, то клиенту нет необходимости в прохождении полного флоу проверки (ввода кода из смс). Если клиент не подтверждён, то он проходит полный флоу проверки, т.е. по 3DSv1.
Почему работает без него?
Надо спросить у Тинькофф, но предположу что это не обязательное условие для проверки.
Почему в самой реализации вашего клиента указан неверный роут конфирмации?
А какой правильный? И вы точно проверяли работу клиента на Flutter?
Как разработчик реализации клиента на Flutter могу сказать пару вещей:
Все ключи не хранятся прямо в нем, хотя такая возможность есть, как и возможность passwordless режима (в этом режиме не все запросы доступны) или подпись запроса со стороны. Реализация писалась так, чтобы её можно было использовать как для мобилок, так и для сервера.
Документация у них и вправду плохая, хотя раньше была pdf версия (сейчас не смог найти) которая была полная по сравнению с тем что есть на сайте.
Возможность компилироваться в jit и aot. hot-reload/hot-restart. Isolate. Future и Stream api. Вообще то что вы хотите под "инновационность" это больше похоже на сахар, который уже можно потрогать в dart 3.
Работа над ошибками
Автор, а вам не кажется что вы хотите "здесь, все и сразу"? Как раз Google умеет в планирование и они это делают в нужной момент времени, с пониманием куда язык растёт и какие он потребности закрывает. По поводу ваших примеров кода, вас не смущает что вы сравниваете getter?
Кодогенерация
Вы сравнили кодоген из C# и dart, но похоже явно не понимаете в чем между ними разница и как они работают, для вас важен лишь результат (скорость). Я видел проекты когда MSBuild собирался по 15 мин, вот это я понимаю скорость... По поводу макросов, их уже делают, можно потрогать в dart 3.
Грабли
Из этой части я все больше стал приходить к тому, что Автор не любит Google и в этом основная проблема.
Сравнение с современниками
А вот это вообще глупо, каждый язык разрабатывается под конкретную задачу. Сравнивать их в лоб по количеству сахара, как-то тупо...
Java в Intellij Idea, C# в Rider или JS/TS в WebStorm
Вот тут ситуация интересная, все что вы перечислили конкретные реализации ide под нужды конкретного языка, когда в свою очередь поддержка Dart в Intellij Idea создаётся через плагин и командой гугла. Странно что вы не указали GoLand ;)
Кастомизация
По моим наблюдениям стандартные компоненты и не нужны. В плане написания своих виджетов есть полная свобода, и нечего вам в этом не мешает. Также я бы сказал что это рай для дизайнера, спросите как дизайнер делает ui/ux для нативных приложений :)
Заключение: я бы мог опровергнуть каждое ваше предложение, но мне банально лень. Так же, можно сделать подобные статьи на любой ЯП, и по содержанию они будут примерно такими же, но это не значит что тот или иной ЯП плохой или имеют недостатки.
@override
Future<void> set<T>(String key, T value) async {
if (value is bool) {
return _prefs.setBool(key, value);
}
...
throw Exception('Wrong type for saving to database');
}
Метод get тоже не безопасный, из-за каста через as. Понятно что там есть try, но все же, раз вы сделали сохранение безопасным, то почему бы не сделать и получение безопасным?
В примере с get/set похоже ошибка и должно быть так:
class A {
int x = 10;
}
class B extends A {
@override
int get x => 20;
}
void main() {
final b = B();
b.x = 30; // здесь не будет ошибки компиляции и присвоения тоже не будет
print(b.x);
}
Использовать late в этом случае нельзя
Спорный момент, а что если сделать так?
class Cat {
Cat() {
print('I\'m constructed');
}
late final int age = (){
print('I\'m born');
return 0;
}();
}
void main() {
final cat = Cat();
print(cat.age);
print(cat.age);
}
Основную проблему которою MVVM решает это полное разделение View и Model посредством ViewModel. В вашем примере мы из View можем добраться до Model напрямую и изменить её, например:
В MVVM из мира WPF есть интересная проверка правильности работы связки MVVM: берётся ViewModel и полностью стирается (остаётся пустой класс), проект собирается и спокойно работает (просто нет реакции от биндингов). Не думаю что ваша реализация пройдёт эту проверку...
Второй момент, в MVVM есть биндинги (у вас даже на схеме они показаны), они имеют режим привязки (OneWay, TwoWay и тд.), у вас в примере я их не наблюдаю.
Также не будем забывать что в MVVM есть ещё команды, без которых не было бы реакции со стороны View, где они у вас?
Зачем такой крюк делать, если в dart/flutter есть dart define. Который можно можно использовать как в dart коде, так и отловить при сборке приложения в Gradle/Pre-action script?
Из своего опыта, рекомендую разделить ваш монолитный пакет на платформенные пакеты (пример). Это будет удобнее для разработки и даст возможность подключить web часть вашей платформы.
Реально что бесит, это best.aliexpress.com. Если перейти по любой скрашенной ссылки на сайт, то эта хрень пропишется у тебя в куках и будет автоматом открываться перенаправляя с нормального aliexpress.com. А там и поиск другой и контент не релевантный…
А зачем создали свою реализацию? Почему не использовали что-то готовое?
https://pub.dev/packages/tinkoff_acquiring
Вы использовали хаб Flutter чтобы люди которые подписаны на хаб узнали об:
Простите но это единственная инфа во всей статье об Flutter...
А никто не говорить про Flutter на сервере ;) Там первая библиотека которая работает с api написана на чистом dart'е, а dart можно спокойно поднять на сервере.
Хм, похоже поменяли, спасибо передам чтобы проверили.
Будет, passwordless режим на это не влияет.
Да, не описан, но не зря мы его делили на два пакета. И да такой сценарий рабочий, это по сути фасад над api.
CollectData нужен для проверки клиента при проверки 3DSv2 (если карта поддерживается) через мета данные. Если клиент подтверждается, то клиенту нет необходимости в прохождении полного флоу проверки (ввода кода из смс). Если клиент не подтверждён, то он проходит полный флоу проверки, т.е. по 3DSv1.
Надо спросить у Тинькофф, но предположу что это не обязательное условие для проверки.
А какой правильный? И вы точно проверяли работу клиента на Flutter?
Как разработчик реализации клиента на Flutter могу сказать пару вещей:
Все ключи не хранятся прямо в нем, хотя такая возможность есть, как и возможность passwordless режима (в этом режиме не все запросы доступны) или подпись запроса со стороны. Реализация писалась так, чтобы её можно было использовать как для мобилок, так и для сервера.
Документация у них и вправду плохая, хотя раньше была pdf версия (сейчас не смог найти) которая была полная по сравнению с тем что есть на сайте.
CollectData нужен, так как 3DSv2 имеет два пути проверки. https://habr.com/ru/articles/445394/
Извините, возможно я что-то пропустил, но для чего вы впихнули Flutter в теги и хаб?
В статье нет абсолютно ничего по теме Flutter...
Возможность компилироваться в jit и aot. hot-reload/hot-restart. Isolate. Future и Stream api.
Вообще то что вы хотите под "инновационность" это больше похоже на сахар, который уже можно потрогать в dart 3.
Автор, а вам не кажется что вы хотите "здесь, все и сразу"? Как раз Google умеет в планирование и они это делают в нужной момент времени, с пониманием куда язык растёт и какие он потребности закрывает.
По поводу ваших примеров кода, вас не смущает что вы сравниваете getter?
Вы сравнили кодоген из C# и dart, но похоже явно не понимаете в чем между ними разница и как они работают, для вас важен лишь результат (скорость). Я видел проекты когда MSBuild собирался по 15 мин, вот это я понимаю скорость...
По поводу макросов, их уже делают, можно потрогать в dart 3.
Из этой части я все больше стал приходить к тому, что Автор не любит Google и в этом основная проблема.
А вот это вообще глупо, каждый язык разрабатывается под конкретную задачу. Сравнивать их в лоб по количеству сахара, как-то тупо...
Вот тут ситуация интересная, все что вы перечислили конкретные реализации ide под нужды конкретного языка, когда в свою очередь поддержка Dart в Intellij Idea создаётся через плагин и командой гугла. Странно что вы не указали GoLand ;)
По моим наблюдениям стандартные компоненты и не нужны. В плане написания своих виджетов есть полная свобода, и нечего вам в этом не мешает. Также я бы сказал что это рай для дизайнера, спросите как дизайнер делает ui/ux для нативных приложений :)
Заключение: я бы мог опровергнуть каждое ваше предложение, но мне банально лень. Так же, можно сделать подобные статьи на любой ЯП, и по содержанию они будут примерно такими же, но это не значит что тот или иной ЯП плохой или имеют недостатки.
Почему бы не сделать нормальную проверку?
Метод
getтоже не безопасный, из-за каста черезas. Понятно что там естьtry, но все же, раз вы сделали сохранение безопасным, то почему бы не сделать и получение безопасным?Тоже недавно интересовался данным вопросом. Помимо того что есть в стате, нашёл эти проекты:
https://github.com/ory
https://github.com/authorizerdev/authorizer
https://github.com/logto-io/logto
Я бы добавил Остановись и гори
Еще мне понравилось упоминание в названии/теге/хабе Flutter, радо одного Flutter плагина. Хороший пиар...
Да, конечно
В примере с get/set похоже ошибка и должно быть так:
Спорный момент, а что если сделать так?
Основную проблему которою MVVM решает это полное разделение View и Model посредством ViewModel. В вашем примере мы из View можем добраться до Model напрямую и изменить её, например:
onPressed: () {_viewModel.state.items.add(ToDoItem(...));
_viewModel.notifyListeners();
}
Да, согласен реализация простая, настолько, что это нельзя назвать MVVM.
И ещё вопрос на подумать: как связанно "управление состоянием" с архитектурным паттерном? И почему у вас смешалось ui логика с бизнес логикой?
В MVVM из мира WPF есть интересная проверка правильности работы связки MVVM: берётся ViewModel и полностью стирается (остаётся пустой класс), проект собирается и спокойно работает (просто нет реакции от биндингов). Не думаю что ваша реализация пройдёт эту проверку...
Второй момент, в MVVM есть биндинги (у вас даже на схеме они показаны), они имеют режим привязки (OneWay, TwoWay и тд.), у вас в примере я их не наблюдаю.
Также не будем забывать что в MVVM есть ещё команды, без которых не было бы реакции со стороны View, где они у вас?
Как по мне, в вашем примере и близко нет MVVM.
Зачем такой крюк делать, если в dart/flutter есть dart define. Который можно можно использовать как в dart коде, так и отловить при сборке приложения в Gradle/Pre-action script?
Из своего опыта, рекомендую разделить ваш монолитный пакет на платформенные пакеты (пример). Это будет удобнее для разработки и даст возможность подключить web часть вашей платформы.