Use of matlab.apps.AppBase outside of AppDesigner

I started a project using AppDesigner, but migrated to a programmatically created app, using the code in AppDesigner as a guide (.m files only, no .mlapp files)

My code works, but uses the following features that I'm struggling to find in the documentation (in MATLAB Help Center)

- matlab.apps.AppBase

- matlab.apps.createCallbackFcn()

- registerApp()

- runStartupFcn()

All these come from the code exported from AppDesigner.

What little information I've found keeps referring to them interacting with AppDesigner, which I'm no longer using, so this information seems not relevant to my use. Or I don't understand the use of the term 'AppDesigner' in this context.

So, should I be migrating away from these constructs? if yes, how do I do that? If no, how do I find the documentation for them (which will be needed for my code review)?

Answer 1

[Matt J]

It's not clear why you would need to migrate away from them if they do what you want. If you need a deeper understanding of what they do, you could examine their code. They are all implemented as editable mfiles.

>> edit matlab.apps.createCallbackFcn

>> edit matlab.apps.AppBase

>> edit registerApp

>> edit runStartupFcn

>> edit appdesigner.internal.service.AppManagementService

[Steve]

It feels wrong to use anything that is undocumented in my code (it will be a red flag flag in the code review). So, why should I not migrate away from their use?

I did look a edit matlab.apps.createCallbackFcn but that calls executeCallback() which is also undocumented and appdesigner.internal.service.AppManagementService.instance() which is also undocumented. Similarly with the other items I just see more that is undocumented.

And, I don't believe Mathworks expect us to reverse engineer the code base in place of documentation, do they?

[Matt J]

It's stil not entirely clear to me who is doing this "code review" and what it's requirements are.

Even setting aside App Designer, Matlab is replete with end-user tools which are documented, but which may call MathWorks internal mfunctions that do not have public-facing documentation (because end-users are not expected to repurpose them). Are you saying you are prevented from using a Matlab command in your projects unless every dependent function from the top to bottom of its dependency tree is documented? That seems impossible.

Or is the rule that only top level, entry point functions are to be limited to documented functions? If so, an easy way to circumvent the problem is to wrap your app in your own "appLauncher.m" file, so that the app code is no longer top level.

[Steve]

Code review are part of our quality system - I will assume you understand what a code review is and why they are useful. In our company they are carried out by an independent team who will inspect the code and question aspects that look dubious or needing further explanation. I do code reviews for other teams and these elements are what I would question in code review given that the code does not use App Designer and all explanations of what they do seem to say they are there to support App Designer.

Being top-level is not the problem, I'd have the same issue wherever they are used. It's that the only explanation I have for their use seems to only refer to supporting App Designer. So, if I'm not using App Designer why am I using them?

What else do they do other than support App Designer. I don't want to remove them if there is a good reason to keep them. However, if they are there just to support the use of App Designer then It would be far easier for me to migrate away from their use than to try to justify their use in a formal code review.

And, regardless of formal design review, I have problems justifying their use if they're just there to support App Designer.

[Matt J]

Well, the bottom line answer to your question, I believe, is no, there is no public facing documentation for internal Matlab functions like the ones you've listed. You can try to migrate away from them, but you will have to reverse engineer them from their Mcode if you want to know precisely what they do.

But even if you do deduce precisely what they do, I wonder what you think you could migrate to that would avoid the same problem. I think just about every documented Matlab command (that ships as MCode) calls some kind of internal function. There is no refuge from this issue just by not using App Designer.

I'm not a software engineer by trade but I do seem to recall hearing from software engineer colleagues that there was some accepted way of integrating blackbox 3rd party code. Could you not fall back on that?