/*! \page howdoesitwork How Does the Launcher Work?
\section Introduction
In a nutshell, applauncherd is a daemon that forks \c booster processes, which in turn are transformed into real applications when user launches a boosted application.
Booster processes do application-type specific initializations. For instance, the MeeGo Touch booster instantiates MApplication and MApplicationWindow objects and stores them to MComponentCache. Then the booster process waits for a connection from the \c invoker.
An application is always launched by using the \c invoker program. The invoker sends the name and location of the application binary and
data on its running environment to the desired booster process. This makes the booster process to load the binary, initialize its environment, and finally call the \c main() function in the binary.
/*! \mainpage Applauncherd usage UNDER CONSTRUCTION!
/*! \mainpage Applauncherd Usage UNDER CONSTRUCTION!
\section intro Introduction
Invoker (front-end binary) and applauncherd (daemon) are tools that helps applications launch faster and save memory via shared resources. This is achieved by preloading a set of dynamically linked libraries and caching stuff
(MComponentCache, MDeclarativeCache). There's a also a possibility to configure an application-specific splash screen, which is shown before the application is started. Also a single-instance support is provided to allow only one instance of an application at a time.
This documentation describes the idea behind this functionality and how to utilize it. It also explains some of the \subpage technical "Technical details" of the implementation.
This documentation describes the idea behind this functionality and how to utilize it.
\section contents Contents
- \subpage howdoesitwork "How does it work?"
- \ref howdoesitwork "How does it work?"
- How to enable boosted startup for different types of applications:
- \subpage qmlboost "QML"
- \subpage qtboost "Qt"
- \subpage libmeegotouchboost "MeeGo Touch"
- \ref qmlboost "QML"
- \ref qtboost "Qt"
- \ref libmeegotouchboost "MeeGo Touch"
- \ref eboost "Generic booster for all applications"
- \subpage splash "How to enable splash screen for the application"
- \ref splash "How to enable splash screen for the application"
- \subpage singleinstance "How to enable single instance support for the application"
- \ref singleinstance "How to enable single instance support for the application"
- \subpage tipsandtricks "Tips and tricks"
- \ref debug "How to debug boosted applications"
- \subpage technical "Technical overview"
- \ref dbus "How to use applauncherd with D-Bus"
- \subpage ownboosterplugin "Write your own booster for other application types"
- \ref aegis "Aegis platform security and applauncherd"
\section howdoesitwork How does it work?
- \ref limitations "Limitations and known issues"
In a nutshell, applauncherd is a daemon that forks \c booster processes, which in turn are transformed into real applications when user launches a boosted application.
- \ref invokerparameters "Advanced invoker command line parameters"
Booster processes do application-type specific initializations. For instance, the MeeGo Touch booster instantiates MApplication and MApplicationWindow objects and stores them to MComponentCache. Then the booster process waits for a connection from the \c invoker.
- \ref customboosters "How to write custom boosters"
An application is always launched by using the \c invoker program. The invoker sends the name and location of the application binary and
data on its running environment to the desired booster process. This makes the booster process to load the binary, initialize its environment, and finally call the \c main() function in the binary.
The cache class works both with the booster and without it. In the
non-boosted case there are no pre-created instances, so the cache
class simply creates the instances on the fly.
The ownership of the instances is transferred from the cache to the
application code. The instances need to be deleted in the correct
order, deleting the \c QApplication instance before the \c
QDeclarativeView instance is known to cause crashes.
\section qmlboostinvoker 3. Launching the application
Now everything should be in place for launching the application. The
linker flags create a Position Independent Binary (PIE), so the
application can still be invoked from the command line. In order to
verify that the modifications done to the application and the build
scripts have not broken anything, it is a good idea at this point to
check that the application still starts and functions normally from
the command line:
\code
$ ./myApp
\endcode
The next step is to use the \c invoker to launch the application. In
order for this to work, you need to have \c applauncherd and \c
booster-d (the QML booster process) running. To check that this is the
case, you can do:
\code
$ ps ax | grep booster-d
\endcode
If you don't see the booster process, you need to start \c
applauncherd manually. In Harmattan and MeeGo, \c applauncherd should
be running as part of the UI session.
Once you have verified that the booster process is running, you can
use the following command line to ask the booster process to turn into
your application:
\code
/usr/bin/invoker --type=d ./myApp
\endcode
Your application should start exactly as if it had been invoked from
the command line, just a little bit faster. You can now proceed to
change the \c .desktop file or \c .service file that launches the
application to use the invoker command.
\section qmlboostsplas 4. Adding a splash screen
The invoker can also provide a splash screen for you application as follows. For more details on splash screen, see \subpage splash "the splash screen documentation."
The cache class works both with the booster and without it. In the
non-boosted case there are no pre-created instances, so the cache
class simply creates the instances on the fly.
The ownership of the instances is transferred from the cache to the
application code. The instances need to be deleted in the correct
order, deleting the \c QApplication instance before the \c
QDeclarativeView instance is known to cause crashes.
\section qmlboostinvoker 3. Launching the application
Now everything should be in place for launching the application. The
linker flags create a Position Independent Binary (PIE), so the
application can still be invoked from the command line. In order to
verify that the modifications done to the application and the build
scripts have not broken anything, it is a good idea at this point to
check that the application still starts and functions normally from
the command line:
\code
$ ./myApp
\endcode
The next step is to use the \c invoker to launch the application. In
order for this to work, you need to have \c applauncherd and \c
booster-d (the QML booster process) running. To check that this is the
case, you can do:
\code
$ ps ax | grep booster-d
\endcode
If you don't see the booster process, you need to start \c
applauncherd manually. In Harmattan and MeeGo, \c applauncherd should
be running as part of the UI session.
Once you have verified that the booster process is running, you can
use the following command line to ask the booster process to turn into
your application:
\code
/usr/bin/invoker --type=d ./myApp
\endcode
Your application should start exactly as if it had been invoked from
the command line, just a little bit faster. You can now proceed to
change the \c .desktop file or \c .service file that launches the
application to use the invoker command.
\section qmlboostsplas 4. Adding a splash screen
The invoker can also provide a splash screen for you application as follows. For more details on splash screen, see \subpage splash "the splash screen documentation."
Jussi Lind
15 years ago