Ciclo de vida del widget y conexión superpuesta delegada

Los artículos escritos en este blog fueron creados con el objetivo de enseñar. Además, la información del artículo puede ser incorrecta, así que tenga cuidado.

UUserWidget::NativeConstruct()Es fácil pensar que se llama sólo una vez, cuando se crea un objeto por primera vez. Sin embargo, si el widget se elimina de la pantalla y se agrega nuevamente, es posible que se vuelva a llamar a Construct.

El delegado puede estar conectado de forma redundante

void UDailyProblemWidget::NativeConstruct()
{
    Super::NativeConstruct();

    SubmitButton->OnClicked.AddDynamic(
        this,
        &UDailyProblemWidget::HandleSubmit
    );
}

Si se llama a Construct dos veces, la función se puede ejecutar dos veces al hacer clic en el mismo botón. En el caso de lógicas como el almacenamiento, la deducción de bienes y la creación de nodos, los datos reales se procesan de forma redundante.

En ProjectDT, se organizó para eliminar al mismo delegado antes de conectarse.

if (SubmitButton)
{
    SubmitButton->OnClicked.RemoveDynamic(
        this,
        &UDailyProblemWidget::HandleSubmit
    );

    SubmitButton->OnClicked.AddDynamic(
        this,
        &UDailyProblemWidget::HandleSubmit
    );
}

NativeOnInitialized y NativeConstruct

Una tarea que sólo hay que preparar una vezNativeOnInitialized()puede ser más adecuado. El valor que debe actualizarse cada vez que vuelve la pantalla esNativeConstruct()Lo proceso en una función de configuración separada.

NativeOnInitialized: una vez durante la vida útil del objeto
NativeConstruct: se puede volver a llamar cuando se adjunta a una vista
NativeDestruct: llamado al salir de la vista

En una estructura de agrupación o reutilización de widgets, la creación de objetos y la visualización en pantalla no deben verse como el mismo evento. Es importante distinguir en qué punto se debe realizar cada conexión de botón, inicialización de datos y actualización de pantalla.