MApplication
and MApplicationWindow
waiting in the cache.
invoker
command instead of executing the executable fileapplauncherd
, compile it with -fPIC
option to produce position independent code. It is recommended to link them either as shared libraries, or, preferably, as position-independent executables, which can be executed both traditionally and with the launcher. The -pie
and -rdynamic
linker flags accomplish this.
To improve linking and loading times of shared object libraries, it is recommended that you hide any unnecessary symbols from the resulting binary by using -fvisibility=hidden
and -fvisibility-inlines-hidden
flags as well. However, applauncherd
needs to find the entry point for your application, so the symbol main
needs to be explicitly made visible. This can be done as follows:
#include <MExport> M_EXPORT int main(int argc, char **argv) { ... }
If your application loads a plug-in that needs to access some symbols in the main application, the symbols also need to be exported. In addition, you must use the --global-syms
invoker parameter, as described in Advanced invoker command line parameters.
Normally you do not need to worry about the compiler and linker flags, as the libmeegotouch-dev
package provides configuration options for qmake
, CMake
, and pkg-config
. If you are building a Debian package, make your package build-depend on libmeegotouch-dev
and your application binary package depend on applauncherd
.
For details on how to get the compiler and linker flags, see Using qmake, Using CMake, or Using pkg-config.
MApplication
and MApplicationWindow
is a relatively expensive operation. The MeeGo Touch booster helps reduce application startup latency by creating instances of the classes in 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 follows:
MApplication application(argc, argv); MApplicationWindow window;
Modify the code as follows:
MApplication* application = MComponentCache::mApplication(argc, argv); MApplicationWindow* window = MComponentCache::mApplicationWindow();
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 MApplication
instance before the MApplicationWindow
instance is known to cause crashes.
exit()
, change these to use _exit()
instead. The brief explanation is that this prevents cleanup actions related to shared libraries to be performed multiple times. For more details, see Limitations and known issues.
$ ./myApp
The next step is to use the invoker
to launch the application. In order for this to work, you need to have applauncherd
and booster-m
(the MeeGo Touch booster process) running. To check that this is the case, you can do:
$ ps ax | grep booster-m
If you do not see the booster process, you need to start applauncherd
manually. In MeeGo 1.2 Harmattan, 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:
invoker --type=m /usr/bin/myApp
/usr/bin/invoker --single-instance --splash=/usr/share/myApp/splash.jpg --type=m /usr/bin/myApp