GFlashy Cards‎ > ‎

GFlashy Cards - Documentation

This document represents the documentation for the GFlashy Cards documentation. This documentation will change continuously since it serves also as documentation for the developer.

Overview: Architecture / Structure

Plugin-Architecture: have core + plugins which are as much as possible detached from the main application.
Each plugin has well defined responsibilities (encapsulates them).

Project structure with responsibilites

  • CustomUIFramework
    Encapsulates the whole UI related stuff such as dynamically loading plugins, parsing their according configuration files and creating the ContributionItems with the according Actions.

  • Common
    • search/loading/initialization of available plugins
    • contains the core domain objects
    • (sharing common services with all plugins)

  • GFlashyCards
    • responsible for applicaton startup
    • defines the main UI layout and structure

  • Plugins (compiled as dll's and loaded into the project dynamically)
    • each plugin encapsulates a well defined responsibility
    • doesn't interact with the main GFlashyCards UI interface
    • uses classes in Common to access Persistency layer (or go over Business Layer <-- Verify) etc...


(Eclipse Action like style)
  • different components:
    • ContributionItem: UI related stuff (rendering of button etc...)
    • Action: non-UI related stuff (Command pattern)
    • ActionContributionItem: combining both components
  • Global / local action items
    • global action items:
      loaded initially and always displayed on the main application UI toolbar. Load on toolbar at startup when instantiating the plugin configurations
    • local action items:
      dependent on the currently displayed view. Load them on the toolbar dynamically when the view gets displayed (create a new toolbar?)

Application Start-up Scenario

  1. GFlashyCards WPF app
  2. PluginLoader retrieves all deployed plugins (dlls) in the application's "Plugin" directory.
    • builds the registered actions from the plugin configuration file (plugin.xml)
  3. For each plugin a main button is added, which (when executed) delegates to a call to the Activator class of the corresponding plugin
    • the Activator loads the set of actions for the corresponding plugin
    • returns a reference to the main view for being displayed on the main application window

Candidates for Plugins

  • Import plugin
    For loading the dataset into the application from external sources (GDocs, CSV,...)
  • Quizzer

UI Stuff

Very simple:
On top a list of buttons which change dynamically depending on the context the user is currently in. Some buttons remain static on all contexts
In the middle a list with the created/imported flash cards (title + snippet of description smaller below)

UML Diagrams

Sequence Diagrams

Application Startup and Plugin loading

(still to be added)


Problems to be handled

  • Dynamic loading of plugin dependencies
    The problem is that a plugin may depend on one or more external (3rd-party) plugins. In that case also these plugins have to be loaded at run-time. The idea could be to separately define these dependencies in the plugin.xml --> however overhead (2x definition). If possible dependencies should be detected and resolved automatically.

Development Links