Managing Shared State in MATLAB App Designer Applications
In MATLAB App Designer, properties serve as the primary mechanism for exchanging information across callbacks and methods. Since every UI element automatically registers as a property, you can read or modify interface controls directly from any script block using the app.ControlName.PropertyName convention. For instance, retrieving and assigning a numeric slider value looks like this:
currentValue = app.InputSlider.Value;
app.InputSlider.Value = 75;
When multiple callbacks require access to transient calculations or persistent configuration states, explicitly defined properties become necessary. These custom properties support two visibility modes: public, allowing external scripts to interact with the app, and private, restricting access to internal app logic only.
Creating Custom Properties
Developers can introduce new properties through the visual layout editor or by editing the underlying class file. The properties declaration block requires an access specifier and supports inline type constraints and default values. A typical definition appears as follows:
properties (Access = private)
TempBuffer = []; % Stores temporary computational results
ThresholdValue double = 0.8 % Accepts only floating-point numbers
end
Default assignments can also be moved into the startupFcn method if dynamic initialization based on environment variables or previous sessions is required.
Reading and Modifying State
Once declared, these fields behave identically to built-in UI handles. Any function within the application scope can reference them using the dot notation attached to the app object:
% Fetch current buffer length
bufSize = length(app.TempBuffer);
% Append new measurement data
app.TempBuffer = cat(1, app.TempBuffer, newMeasurement);
Practical Implementation Scenario Consider a visualization tool that dynamically updates charts based on user input. A private property holds the final rendered dataset, bridging a configuration field and a plotting action.
When a developer adjusts a numeric edit field, the associated callback processes raw inputs and caches the outcome:
function SampleSizeValueChanged(app, event)
newSize = str2double(event.Value);
% Simulate processing pipeline
app.ProcessedResults = randn(newSize, 3);
end
Subsequently, triggering a refresh command pulls both the cached matrix and a categorical selector to apply the correct rendering scheme:
function RefreshButtonPushed(app, event)
if ~isempty(app.ProcessedResults)
targetFigure = findobj('Tag', 'MainPlot');
surf(targetFigure.Children, app.ProcessedResults, ...
app.StyleDropdown.SelectedObject.Text);
else
warning('No data available for rendering.');
end
end
This architecture prevents redundant computation, centralizes data management, and ensures consistent state synchronization throughout the application lifecycle.