My 100 Days of Code Challenge

 My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #19 : Adding Support for Android In this episode, we'll add Android to our list of supported platforms for the Ava program, its library, libava, and its test program, testava. I'm using Android Studio Chipmunk 2021.2.1 Patch 1, built on May 18, 2022. I'll test and debug using a physical device, a Samsung Galaxy S9, connected to my development laptop using a USB-C cable. Since all supported platforms reference the same code, I'll update the CMakeLists.txt file that Android Studio generates to reference Ava source modules in their current location within the repository. Folder and File Hierarchy Updates For Window and iOS, we created folders at the top level of the repository to hold platform-specific project files. We'll follow the same example here. We'll create and android folder in the repository and create the Android Studio project there. Update to .gitignore It is not necessary to includ...

  My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #18 : Adding a Test Program To now, we've used the Ava program itself for testing. Now, though, we'll be starting to add a lot of code that performs specific algorithms related to message encryption, creation of digital signatures, compression, etc. So it's very helpful to have a dedicated program that will test the implementation of these algorithms before we have the Ava program use them. We'll start on Windows and create a new Visual Studio project (.vcxproj, .vcxproj.filter, .vcxproj.user) that includes a single C++ source file, testava.cpp. For today, the test program will simply log a couple of startup messages and a completion message. Under the hood, though, I've made some other changes to enable calling the Log class methods from either the Ava or TestAva programs. This required making the "EXPORT" definition accessible independently from the "idriver.h" header where...

My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #17 : Adding a Configuration File Today we'll add the final component of our configuration design, support for reading a configuration file. There are various standards for configuration file. Which might be another way of saying there is no real standard for configuration files. Here, I've adopted a simple "<name> = <value>" structure. The configuration file settings are given higher precedence than Registry or Environment settings. But they are lower in priority than program arguments. So after we apply system-wide settings values from the Registry (on Windows only) and then apply current Environment (user) settings, then we can apply settings from a configuration file that can be specific to the location where the program is run, so that multiple copies of the program can run concurrently, in different paths, and have distinct settings. Finally, any setting can be overridden with prog...

My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #16 : Applying Windows Registry Settings Today we continue to expand on our application configuration logic. We'll read the Windows registry to apply system-wide setting values. Registry values are applied first. Then, settings are tailored, first from the environment, or user, level and then from program arguments are specific to the execution of the program. Here we've added a general routine to read a setting value from the Registry. Next, we've added the routine that reads all defined Registry settings and applies them to our application class instance. We'll call the new GetRegistryVars method as part of our overall configuration routine. To test, we first add a value in our application's registry space, which was created when we installed Ava as a service. If you don't want to install Ava as a service, you can use the Registry editor to manually create the registry path. We've create...

My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #15 : Adding Settings from Environment Variables So far, we've shown how program arguments can be read and applied to configure Ava settings. Now we'll look at applying setting from Environment variables. This really just makes use of the getenv function in the C library. We'll define setting names and identifiers in our namespace enumerations and const strings. Environment variable settings will be applied before program arguments so that program arguments, which are specific to each execution of the program, can override Environment variables, which are specific to the operating context or user. Here are the environment variable names added in the "driver" namespace. Since the Environment is not specific to the program, we prefix the settings with the program name. Here is a new method in Driver, called GetEnvVars. It simply reads each variable and calls the appropriate method on the singleton...