Bias consists of its core, which performs all general and low-level functionality, its utilities (both GUI and non-GUI) which contain methods to solve some common tasks and its extensible add-ons-driven subsystem. Of course we are most of all interested in latter point, which is actually the main subject of this article. But first let's see (briefly) what two former points are.

Bias core consists of BackEnd which performs all low-level operations like storing and loading data, encryption/decryption, import/export etc. and FrontEnd which interacts directly with user and represents general GUI-related behaviour like visual entries organization, handling of different user-dialogs and management screens, providing of service methods to retrieve visual entry descriptors etc. Note that FrontEnd manipulates Extension instances on abstract level without knowing anything about certain underlaying implementations. The same is true for Skin - it's based on interface and there's no hard-coding in the least. This way, core is separated into fully abstract layer, which main aim is to provide application extendability.

Bias Utilities provide easy interfaces to perform some general tasks: both GUI-related (like ImageFileChooser that is handy for opening image files and so on) and non-GUI (like data validation, file system I/O operations, properties manipulation, file associations handling etc.).

Now let's talk about the most interesting part - extensible add-ons-driven subsystem.

There're few common things that lie at the heart of Bias extensible architecture:

I won't bother you with details but for those who are interested in more details, here go some links:

General Bias application architecture is represented on the following diagram:

I believe it's much self-explanatory, but I'm going to comment on it briefly nonetheless ;)

First of all, as you see FrontEnd is an entry point of an application. This is a part that is used by application user directly, so nothing remarkable here. FrontEnd uses BackEnd as low-level-data-manipulation layer to perform such operations like data loading/import/export/saving - BackEnd is the only part of application that touches data and configuration files directly. FrontEnd also instantiates instances of classes extending abstract Extension class. As you see from diagram, there's one-to-many relation, hence there're can be many instances instantiated during one application session. Any Extension instance can use FrontEnd to perform some common actions related to GUI (like retrieving descriptors of all visible entries) as well as BackEnd to perform some common data related actions (like storing and retrieving data entry attachments). And one more thing FrontEnd does is instantiation of instance of class extending Skin, though note that in this case there's one-to-one relation, because only one Skin instance can be instantiated during one application session.

From the developer's point of view, it's quite easy to understand how Extensions and Skins are implemented - all you need to do is to extend appropriate abstract class (either Extension or Skin) and override/implement it's methods as needed.