https://www.mathworks.com/matlabcentral/answers/279042-app-designer-s-editor-is-slow-and-gets-stuck-alot

Question for anyone who has studied the internals– have you also experienced problems in AppDesigner, and then gained any insights whatsoever via your sleuthing? Do you have any clues or hypotheses about what could be going wrong for so many users?

Surely, after all these years of hard work, the AppDesigner team should have worked out most of the minor bugs..?

By the way, these are the relevant MATLAB files if someone wants so keep reverse engineering this thing

• C:\Program Files\MATLAB\R2018b\toolbox\matlab\appdesigner\appdesigner\+appdesigner\+internal\+model\AppModel.m
• C:\Program Files\MATLAB\R2018b\toolbox\matlab\appdesigner\appdesigner\+appdesigner\+internal\+codegeneration\+model\CodeModel.m
• C:\Program Files\MATLAB\R2018b\toolbox\matlab\appdesigner\appdesigner\+appdesigner\+internal\+serialization\MLAPPSerializer.m
• C:\Program Files\MATLAB\R2018b\toolbox\matlab\appdesigner\appdesigner\+appdesigner\+internal\+serialization\FileWriter.m

My conclusion is that, as far as I have been able to reach without basically fully reverse engineering AppDesigner’s inner workings, there is no way to use the methods available in appdesigner.internal such as FileWriter() to generate MLAPP files from the class definition in text format in an M file.

Here’s what I found.

• In newer versions of MATLAB the MLAPP file is organized in pretty much the same way but the appdesigner/appModel.mat file has a different organization. Now the AppData field is deprecated but kept for compatibility, and the data it contained is replace by two new fields ‘code’ and ‘components’. The ‘code’ struct stores the code from the app in separated sections (EditableSectionCode which is the part that contains the methods and properties, Callbacks, StartupCallback, etc), and components stores the UIFigure and the group hierarchy (I have no idea what this is, is generated by the AppModel method getGroupHierarchy() and is way to deep for me too understand already). The groups hierarchy was previusly stored inside appData.metadata.

• AppModel: probably the parent for all apps created in AppDesigner is the class appdesigner.internal.model.AppModel . The AppModel contains the save() method, and has the properties Metadata and CodeModel among others. CodeModel is generated from the class appdesigner.internal.codegeneration.model.CodeModel, and contains the different sections of the code.

• FileWriter(): as Oleg’s pointed correctly, appdesigner.internal.serialization.FileWriter() is a class that can generate and write to MLAPP files. It has 4 methods (writeMATLABCodeText, writeAppDesignerData, writeAppMetadata, writeAppScreenshot) that have to be called to succesfully contruct an MLAPP file, and can be called from the command line, which would allow using them to generate MLAPP files from its components. The problem is, this components can only be accessed by AppDesigner itself, which renders this methods useless.

• Hypothesis for MLAPP file saving: my hypothesis is that when an app is saved, the save() method in the AppModel class is called, which in turn calls the AppModel method writeAppToFile(), which creates an appdesigner.internal.serialization.MLAPPSerializer instance. The AppModel’s method setDataOnSerializer() copies all the required information to MLAPPSerializer, including the code sections, the metadata, group hierarchy, etc. Then, MLAPPSerializer creates a fileWriter instance, divides the different objects received from AppModel and passes them to the relevant fileWriter methods to generate the MLAPP file.

I’m afraid there is literally no way to correctly generate the data scructures that are necessary to reconstruct an MLAPP file from the plain code without putting a ton of hours into untangling all the logic behind AppDesigner. Maybe someone can use this information to take on that task in the future.

lf      = appdesigner.internal.serialization.AppLoadingFactory.instance();

appData = lf.getAppData('C:\Users\ok1011\Documents\github\carv-realtime-matlab\src\utilities\+carv\+plot\turn.mlapp')

  AppData with properties:

                   UIFigure: [1×1 Figure]
                   CodeData: [1×1 appdesigner.internal.codegeneration.model.CodeData]
                   Metadata: [1×1 appdesigner.internal.serialization.app.AppMetadata]
                 ToolboxVer: '2016b'
                FullVersion: '9.1.0.441655 (R2016b)'
    MinimumSupportedVersion: 'R2016b'

Or using the file reader, which allows to read Matlab code directly:

fid     = appdesigner.internal.serialization.FileReader('C:\Users\ok1011\Documents\github\carv-realtime-matlab\src\utilities\+carv\+plot\turn.mlapp');
appData = fid.readAppDesignerData();
mcode   = fid.readMATLABCodeText();

The appdesigner.internal.serialization.FileWriter() class allows to write code to the .mlapp file.

For example if I have a working appGUI.mlapp I can create

classdef myAppGUI < appGUI
   properties
      NewButton matlab.ui.control.Button
   end
   methods
      function A = myAppGUI
         % A = A@appGUI; <-- usually not necessary
         A.NewButton = uibutton(A.UIFigure);
         A.NewButton.Position = [20 20 100 22];
      end
   end
end

To assist you in recalling component names, etc, while programming the derived class you can have an instance of the base class (if it is not Abstract) in the workspace

>> Base = appGUI;

to interrogate its methods and properties. This is almost as good as having the appGUI code.

Of course, this approach should not become obsolete, unless the MathWorks does something dumb like making mlapp classes Sealed.

Thanks for this – I believe that a guest post about your experience with customizing uifigures using CSS would be highly appreciated by readers. Care to give it a shot? Send me an email to discuss the technical details