Changes
==== Plugins ====
Plugins in UBIK.Android are special Android libraries defining and containing modules.[[B]They allow the programmer to add, remove or replace functionality of an app without refactoring the code.[[B]
===== Plugin Definition =====
Plugins can be defined by creating an ''Android library project'' containing a class implementing the ''IPlugin'' interface (''com.augmensys.ubik.common.plugin.IPlugin'').[[B]Then, a ''meta-data tag'' has to be added to the library's ''!AndroidManifest.xml'', specifying the plugin class:[[B]
{{Code|
<meta-data
android:value="com.augmensys.ubik.plugin.test.DummyPlugin" />
}}
==== Modules ====
Modules are singletons provided by plugins. [[B]They are identified by a ''Module Slot ID'' as well as an individual ''name'' and ''implementation''.[[B]
===== Module Definition =====
====== Adding a Class as Module to a Plugin ======
Modules can be defined by just adding a class to a Plugin using the following pattern:
{{Code|
public class MyPlugin extends Plugin {
====== Specifying further Module Options ======
Also, by adding a ''@Module'' Annotation to the module class, you can specify dependencies and other options.[[B]
{{Code|
@Module(
...
}}
Take a look at the !PluginManagementTest project in order to see examples.[[B]
====== 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.[[B]This can be done by marking a method with the ''@!LifeCycleTask'' annotation, specifying the respective timing as a parameter.[[B]
{{Code|
@LifeCycleTask(AppLifeCycleTiming.SESSION_START)
}
}}
Every method marked by this annotation must not require any arguments and must return void. Else, it won't work.[[B]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.[[B]
====== 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.[[B]This is done by adding your implementation to your plugin, but using an existing ''Module Slot ID'' (namely the one you want to replace).[[B]E.g., let's say I want to replace the ''!MetaioConfiguration'' module for my customized project:[[B]
{{Code|
public class CustomPlugin extends Plugin {
}
}}
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.[[B][[B]Incompatible modules can be replaced by replacing the whole plugin or specifying that the replacing module overrides all conflicting modules no matter what (using an option in the ''@Module'' annotation).[[B]This can lead to unresolvable dependencies though, so the other plugins and modules used in the app should be accounted for.[[B][[B]
==== Errors and Solutions ====
===== 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. [[B]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.[[B]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!).[[B]
It can be solved by overriding incompatible plugins.
* AR Navigation (uses Kernel, UI and AR)
* Commissioning (uses Kernel and UI)
* Push (uses Kernel and optionally AR)
* Push.UI (uses Push and UI)
* RAG.lib (uses Kernel, UI and AR): Shared RAG Functionality - this is going to be refactored into Kernel, UI and AR
* Demo.lib (uses Kernel, UI, AR, AR Navigation and RAG.lib): Shared Demo Functionality - this is going to be partly refactored into other plugins
There are the following possibilities to customize a {{UBIK}} Android app by server configuration:
* Meta definitions (define content objects)
* Type
* Unit
* Name
* Displayed name
* Content
* Classified objects (see [[List_of_Classifications|List of Classifications]]), e.g.:
* Map layers
* POI groups
* AR configuration
* Map overlays
* Background images and app icon
* Client & account configuration
== Local Configuration ==
