[Erlang study notes] Understanding of Application in erlang

The Erlang Getting Started Manual describes it like this --->>
1.Erlang/OTP provides many components, each component implements some specific functions. Components are called "applications"in Erlang/OTP terminology.
2. Applying this concept corresponds to both program structure (process) and directory structure (module).
3. A simplest application does not contain any process, but it contains a series of functional modules.
In this way, you will have the most preliminary understanding of the application: an application is a component that can complete a specific set of functions and is reusable.
At this time, what is the specific use of the application and how to use it:
Through application, a functional module can be packaged into an application, so that the module can be started or stopped independently and can be referenced in other modules.
use. like mnesia. Implementation steps:
1. First complete the function module to be packaged, and remember to define it as application ---> file header plus -behaviour(application).
2. Add the .app application resource file for this module, the format is as follows:

{application, Application, [Opt1,...,OptN]}.

Note: Application is an atom that represents the name of the application. The file must be named Application.app . Each Otp is a tuple {Key, Value} that defines some property to apply. All keys are optional. Ignored keys will use default values.

These properties are to let the erlang compiler know which way to start the application.
The ch_app.app file is as follows:

{application, ch_app,
[{description, "Channel allocator"},
{vsn, "1"},
{modules, [ch_app, ch_sup, ch3]},
{registered, [ch3]},
{applications, [kernel, stdlib, sasl]},
{mod, {ch_app,[]}}
]}.

description
Short description, string. The default is"".
vsn
version number, string. The default is"".
modules
All modules imported by this application. systools will use this list when generating startup scripts and tar files. A module must be defined in and only

in an application. The default is[]

registered The names of all registered processes in the application. systools uses this list to detect name conflicts between applications. The default is []. applications All applications that must be started before this application. systools uses this list to generate the correct startup script. Defaults to [], but note that any application must at least depend on the kernel and stdlib





When a module is referenced to this application, it must be started, or an error will be reported.
The startup of the application loads the application through application:load(applicationName).%%
application:start(applicationName).%% start the application
To stop, stop the application through application:stop(applicationName).%%