-
Notifications
You must be signed in to change notification settings - Fork 1
Folder structure
What's the deal with all of these folders, and what is contained therein? For starters, the project uses the MVVM design pattern, which is common amongst Windows Presentation Foundation (WPF) projects. That will help you get an idea of the models, views, and view models. But let's quickly go over each folder.
From the root project folder
This folder contains a few custom UI behaviors I had to create to override some default WPF event handlers. Ex: TapBehavior redefines a completed event as being a touch down and a touch up on a UI element. Previously, WPF defined it solely as a touch up.
This folder also contains the "secret sauce" multi-touch events that I had to create to allow the table to work better with many users at once. Take a look at the UIElementDragBehavior and UIElementDropBehavior behaviors. They contain some of the magic that allows users to reliably drag galaxies onto their workspace without another user's touch event canceling the action.
This folder contains some code that performs custom logic to determine a value; often times a styling element. For example, the ProgressWidthConverter is used in the answer summary screen to determine how much of a percentage each answer is out of all answers. For example, if 7 users out of 21 said the galaxy was a spiral, this converter would spit out 33%.
Not too complicated here. Just the fonts for the touch table. I'd also note that each FontFamily is called like so and each font must be imported into the GalaxyZooTouchTable.csproj folder like so.
Static images in the touch table. Assets are imported like fonts above. Don't forget to import the image into the project folder and also reference it in an image source.
There's a lot going on here, and it could probably be reorganized a bit. Think of this like a "helpers" folder as in some of our JS repos, although this contains other code too. The folder contains the Log class responsible for logging whenever the app opens and closes. There are also enums, some are titled as such (ex: CardinalDirectionEnum); however, others are not (ex: WorkspacePositions and RingNotifierStatus). This also contains the Messenger, which is an important class that helps view models communicate with one another.
This is the "M" in "MVVM." These models contains just the properties of several items in the code. While each Model should have a corresponding View and ViewModel, I started some of this work while learning about MVVM, so the code doesn't always reflect that. Any model you see here with an "I" (ex: IClassificationPanelViewModelFactory) is an interface that is likely defined as such to help in testing.
Most of these files were created with the first commit. However, the app.manifest was created when the .NET client was incorporated to the project. It's not likely these files will be touched too often.
This is an important folder that handles all communication with other services such as Caesar (GraphQL), third-party satellite/cutout services (Sloan and DECALS surveys), Panoptes, and the local database. Again, all of the I prefixes denote interfaces and are helpful when setting up testing.
I'll note here that the CutoutService does some work to optimize the call.
Check out the GetSpaceCutout function.
- First we prioritize getting the cutout (background space image) from the DECaLS survey since that is also where many of our subject images come from. If's important to note that these cutouts are returned as squares, so we must stitch them together and use three images for the background. However, if that is down, we switch to...
- Secondly, we try Sloan (SDSS), which also has a sky survey we can fetch images from. Sloan's api is a bit more flexible and can return a rectangle image which fits nicely into our background.
LocalDBService also contains all the queries for fetching subjects based on their RA/DEC positions in space.
This isn't a huge folder, but it contains styles for buttons commonly used throughout the app as well of color constantly that are referenced numerous times. Many of the view styles are contained within the view itself. Eg: Notice how the CloseConfirmation.xaml have it's own resources section that contains styling for that element. Elements can be styled this way within the element itself, or it can reference a common element like so.
This is probably the most important folder that contains a lot of the app logic. This is where you'll find some of the functionality for the classifiers, users, and galaxies. Every view model here inherits from the ViewModel base class. Also, it's important to note that view models must have the ability to update their properties in a way that can be reflected in the UI. This is why view model properties sometimes have the following definition:
public bool ClassifierOpen
{
get => _classifierOpen;
set => SetProperty(ref _classifierOpen, value);
}
The SetProperty definition above is available from the ViewModelBase and allows the UI to get the update. Without this definition, the UI would not register any property changes.
As it says, the contains all the views for the app, which are all written in XAML. This can be a difficult structure to wrap your mind around, especially since each XAML also has an accompanying .cs file. For the most part, that .cs file will not be used; however, some files do make changes to the file to attach a Data Context (view model) or attach event subscriptions.
It's also important to note that a lot of styling and "triggers," which should determine styling based on a property. For example, the visibility of this UI element is determined by the IsVisible property on the StillThereViewModel.