Jump to: navigation, search

Changes


Internal:UBIK Android Customizing

4 bytes removed, 13:37, 25 June 2015
Plugins can be defined by creating an ''Android library project'' containing a class implementing the ''IPlugin'' interface (''com.augmensys.ubik.common.plugin.IPlugin'').
Then, a ''meta-data tag'' has to be added to the library's ''!AndroidManifest.xml'', specifying the plugin class:
{{Code|<pre>
<meta-data
android:name="UBIK.Android.Plugin.DummyPlugin"
android:value="com.augmensys.ubik.plugin.test.DummyPlugin" />
}}</pre>
The name has to start with "''UBIK.Android.Plugin.''" and the value must contain the fully qualified class path.
Modules can be defined by just adding a class to a Plugin using the following pattern:
{{Code|<pre>
public class MyPlugin extends Plugin {
}
}
}}</pre>
Also, by adding a ''@Module'' Annotation to the module class, you can specify dependencies and other options.
{{Code|<pre>
@Module(
dependencies ={
...
...
}}</pre>
Take a look at the !PluginManagementTest project in order to see examples.
====== App Life Cycle Timing Tasks ======
A module can react to ''App Life Cycle Timings'' like the app being started or stopped and a session being started or stopped.
This can be done by marking a method with the ''@!LifeCycleTask'' annotation, specifying the respective timing as a parameter.
{{Code|<pre>
@LifeCycleTask(AppLifeCycleTiming.SESSION_START)
public void initializeOnLogin() {
...
}
}}</pre>
Every method marked by this annotation must not require any arguments and must return void. Else, it won't work.
By the way, any annotations are inherited (yes, also the method annotations - the !ModuleManager takes care of that). This means, overriding such a module or method but not re-specifying the annotation won't let that information get lost.
====== Replacing Modules ======
Modules can be replaced by providing a different implementation for the same Slot ID, if the new class is assignable to the old one.
This is done by adding your implementation to your plugin, but using an existing ''Module Slot ID'' (namely the one you want to replace).
E.g., let's say I want to replace the ''!MetaioConfiguration'' module for my customized project:
{{Code|<pre>
public class CustomPlugin extends Plugin {
}
}
}}</pre>
By the way, even an interface without implementation can be a module. With this, you can insist on a module having to implement this interface when it is using this slot.[[B]
Then, the library containing the implementation does not have to be referenced by the code using the respective module.
===== The Plugins couldn't be initialized! =====
[[B]
First of all, read the logcat output carefully. Most likely, there is some more precise information to be found.
Also, a common error is that the Android Project you are using doesn't directly refer to an Android library that contains the required metadata, but instead uses another one that in turn contains the library in question. In this case, please add the "indirectly referred" library directly to the parent project. This is especially true, when the logcat output says that the !MetaData are null.
Other common problems are incompatible plugins or modules. This should be described precisely in the logcat output and must be solved by assembling the project's plugins correctly (valid inheritance hierarchies are required!).
It can be solved by overriding incompatible plugins.
1,765
edits