Builder против GlobalKey
Проведя несколько часов сегодня, пробовав каждое решение, я все еще не смог пройти эту точную ошибку. Я использовал gmail много раз таким образом, поэтому я знал, что это что-то немое, но я ничего не исправил. Я, наконец, наткнулся на решение в моем случае, поэтому подумал, что буду делиться.
Во-первых, большинство ответов выше также требуется, но в моем случае это было простое упорядочение кода при создании класс SmtpClient.
В этом первом фрагменте кода ниже обратите внимание, где находится строка «Credentials = creds». Эта реализация будет генерировать ошибку, на которую ссылается этот вопрос, даже если у вас есть все, что было настроено правильно.
System.Net.Mail.SmtpClient client = new System.Net.Mail.SmtpClient
{
Host = Emailer.Host,
Port = Emailer.Port,
Credentials = creds,
EnableSsl = Emailer.RequireSSL,
UseDefaultCredentials = false,
DeliveryMethod = System.Net.Mail.SmtpDeliveryMethod.Network
}
Однако, если вы переместите вызов установщика учетных данных в нижнюю часть, письмо будет отправлено без ошибок , Я не внес изменений в окружающий код ... то есть ... имя пользователя / пароль и т. Д. Очевидно, что либо EnableSSL, UseDefaultCredentials, либо метод DeliveryMethod зависят от установленных учетных данных ... Я не тестировал все, чтобы выяснить, какой из них был.
System.Net.Mail.SmtpClient client = new System.Net.Mail.SmtpClient
{
Host = Emailer.Host,
Port = Emailer.Port,
EnableSsl = Emailer.RequireSSL,
UseDefaultCredentials = false,
DeliveryMethod = System.Net.Mail.SmtpDeliveryMethod.Network,
Credentials = creds
}
Надеюсь, это поможет спасти кого-то еще некоторые головные боли в будущем.
2 ответа
Настоящая причина, по которой мы склонны избегать GlobalKey, заключается не в производительности. Это больше связано с тем, что он разбивает несколько шаблонов во флаттера.
Виджеты по определению не должны иметь доступ к конкретной информации других виджетов (например, их размеру или положению). И GlobalKey предоставляют возможность доступа к такой информации; позволяя людям делать анти-паттерны.
Подумайте о GlobalKey как о средстве извлечения реактивного слоя Flutter.
Несколько примеров того, что люди склонны делать с помощью GlobalKey:
- Имея общедоступный синглтон
GlobalKey. Используется как среднее, чтобы не поднял состояние вверх . Взаимодействие между виджетами трудно предсказать, так как отношения не являются односторонними (родительские -> дети становятся двусторонними отношениями) - Используя
GlobalKeyдля вычисления размера макета. Затем активируйте повторную визуализацию с помощью этой информации. Это вместо этого рольRenderObjectи не должно выполняться в виджетах. Это значительно усложняет компоновку
Builder, а с другой стороны не нарушают эти шаблоны. Поскольку, по определению Builder, ничего . Это просто опрятный способ использования другого BuildContext.
Это обычно означает, что если вы можете решить проблему с макетом, используя Builder вместо GlobalKey, вы на правильном пути к поддерживаемому макету.
Когда использовать GlobalKey, то?
Ну, если можно, никогда. Попробуйте вместо этого использовать такие вещи, как context.ancestorStateOfType или context.inheritWidgetOfExtactType. Вы также можете рассмотреть возможность создания пользовательского RenderObject для определенного макета. RenderObject в сочетании с parentData также может быть тем, что вы хотите, если вам нужна связь между родителями / детьми
. Однако это может быть сложнее. Он может потреблять больше времени, чем вы хотите. Или вы можете попасть в кромку, которую трудно реализовать с использованием текущего API.
В таких ситуациях можно использовать GlobalKey, пока вы знаете возможные последствия.
GlobalKey является дорогостоящим, скорее всего, связано с ситуациями, когда вам может понадобиться много ключей, например, для детей ListView.
Я сомневаюсь, что стоимость GlobalKey для SnackBar будет иметь значение. Вряд ли вы их создадите.
GlobalKey, а когда это не так :) – Derek Lakin 30 July 2018 в 08:22