You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
appmotor/doc/libmeegotouchboost.dox

150 lines
5.4 KiB
Plaintext

/*! \page libmeegotouchboost Using the MeeGo Touch Booster
This section describes how to use the MeeGo Touch booster. The
booster provides the application with the key libraries already
present in the process, and instances of \c MApplication and
\c MApplicationWindow waiting in the cache.
\section mtboostprereq Prerequisites
The launcher can start an application if the following pre-requisites are met:
\li MApplication and MApplicationWindow instances are taken into use from
MComponentCache
\li application is compiled and linked to a position independent binary
(executable or library)
\li application is started with the \c invoker command instead of executing the
executable file.
\section mtboostcompiling 1. Compiling and linking for launcher
Binaries intended to be run with \c applauncherd should be compiled
with \c -fPIC option to produce position independent code. They should
then be linked either as shared libraries, or better yet as position
independent executables, which can be executed both traditionally and
with the launcher. The \c -pie and \c -rdynamic linker flags
accomplish this.
To improve linking and loading times of shared object libraries it is
encouraged to hide any unnecessary symbols from the resulting binary
by using \c -fvisibility=hidden and \c -fvisibility-inlines-hidden
flags as well. However, \c applauncherd needs to find the entry point
for your application, so the symbol \c main needs to be explicitly made
visible. This can be done as follows:
\code
#include <MExport>
M_EXPORT int main(int argc, char **argv)
{
...
}
\endcode
If your application loads a plugin that needs to access some symbols
in the main application, the symbols also need to be exported. In
addition, the \c --global-syms invoker parameter needs to use, as
described in \ref invokerparameters "Advanced Invoker Command Line Parameters".
Normally you should not need to worry about the compiler and linker
flags, as the \c libmeegotouch-dev package provides configuration
options for \c QMake, \c cmake, and \c pkg-config. If you are building
a Debian package, make your package build-depend on \c
libmeegotouch-dev and your application binary package depend on
\c applauncherd.
For details on how to get the compiler and linker flags, see
\ref usingqmake "Using QMake", \ref usingcmake "Using CMake", or
\ref usingpkgconfig "Using pkg-config".
\section mtboostcache 2. Utilizing the booster cache'
Instantiating \c MApplication and \c MApplicationWindow is a relatively
expensive operation. The MeeGo Touch booster helps reduce application startup
latency by creating instances of the classes in \c MComponentCache.
MApplication instance must be taken from the MComponentCache. It is
recommended to take MApplicationWindow from the cache as well. Thus,
if the classes are instantiated in the application as
\code
MApplication application(argc, argv);
MApplicationWindow window;
\endcode
the code needs to be modified to:
\code
MApplication* application = MComponentCache::mApplication(argc, argv);
MApplicationWindow* window = MComponentCache::mApplicationWindow();
\endcode
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 MApplication instance before the \c
MApplicationWindow instance is known to cause crashes.
\section mtboostexit 3. Adapting application source code
Making use of the cache is typically the only modification needed to
the application. However, if the application has explicit calls to \c
exit(), these should be changed to use \c _exit() instead. The brief
explanation is that this prevents cleanup actions related to shared
libraries to be performed multiple times. For more details see
\ref limitations "Limitations and known issues".
\section mtboostinvoker 4. 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-m (the MeeGo Touch booster process) running. To check that this is the
case, you can do:
\code
$ ps ax | grep booster-m
\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
invoker --type=m /usr/bin/myApp
\endcode
\section mtboostfinishingtouch 5. Finishing touches.
The invoker can also provide single instance behavior and a splash
screen for you application as follows. For more details, see
\ref singleinstance "the single instance documentation" and
\ref splash "the splash screen documentation."
\code
/usr/bin/invoker --single-instance --splash=/usr/share/myApp/splash.jpg --type=m /usr/bin/myApp
\endcode
*/