Skip to content
This repository has been archived by the owner on Dec 22, 2021. It is now read-only.

Developer Documentation

Joshua Lamusga edited this page Oct 13, 2017 · 15 revisions

Overview

Crystal Keeper is intended to store mineral data for cataloging and printing purposes. It uses a templating system that allows the user to define what kind of data to store and its visual layout. There are default templates for minerals, localities, and notes.

Data hierarchy

  • Templates are not in the hierarchy, but are used by collections to define the data fields and layout format. Each template stores any number of template columns, which in turn store template fields.
  • At the top of the hierarchy is the database. There can only be one per project. It stores project preferences and any number of collections.
  • Each collection requires a template so the data and layout is known. Entries are associated directly with collections in the project data, but exposed in the GUI only through entry references in groupings. Collections store any number of groupings.
  • Groupings are used to group entries visually, though entry references are used in the project data. This allows multiple references to the same entry, enabling the user to place the same entry in multiple groupings in the collection. This means that groupings store the entries.
  • Entries have a field representing each field in the parent collection's template, and store that many entry fields.
  • Each entry field represents a specific template field, storing the real data for it.

Saving and Loading

Saving and loading is a straightforward binary writing / reading process, with the exception of entry fields:

  • All fields are saved as binary. Image fields are saved with a string representing metadata first, followed by the data from the urls listed in the metadata, each of which is an image or movie.

  • Text fields are in the XamlPackage format and loaded as binary. Each image or movie in image fields is saved to a file in the AppData/CrystalKeeper folder, then the metadata string is refreshed to point to the new urls. All other fields are converted from binary to their appropriate object types.

Changelog

Version 1.0: First release.

Roadmap

  • Option to encrypt the file and decrypt it using a password. The encrypted contents will be prefixed with a legible version number and bool indicating it's encrypted.
  • Consider export functionality for exporting a collection.
  • Database, Grouping, and Collection pages don't show the first treeview child's dataitem as centered.
  • Can't scroll when hovered over images in entry view/edit.
  • Scrollbars are printed.

Code Refactoring

  • Verify all naming patterns between files is maintained, e.g. "project" not "proj", "gui" not "_gui". Spacing should be consistent and comments should be meaningful / relevant.
  • Hover mouse over every function and make sure that all exceptions are handled with correct verbage for each one. Log all exceptions in full. Visit existing exceptions to ensure they are logged correctly.
  • Add methods to the project to set the data for a given dataitem of the proper type.
  • Move all lambda code into applicable function calls.
  • Include lazy loading, perhaps by adding functions to start/stop drawing.
  • Abstract the data formats for each field into its own struct so you can get/set the values and the data type to be stored in the project. Include a .Empty() method.
  • Have error handling whenever casting from GetData(""). Use Console.Log for it.