jAppletCalculator
This project was an exercise in building an architected and maintainable code project in Java. At the moment, the calculator has all of the features of a simple calculator including a negation button and nested square root operations. Past calculations are displayed in a historical text area that is appended each time a new operand or operation is registered or calculated.
This project seems trivial, however, it was very interesting for me to see how much complexity and architecture could go into something that we probably think is the most simple application on our computers: the calculator. I would like to continue working on this project in the near future; adding scientific capabilities, the ability to click on the historical display in order to use those calculations, adding this to a Spring or Spring boot application instead of being an applet and more, because it would be a great learning endeavour. At the moment, I am going to focus on other half-finished projects I have, and present this version.
Deployment
This applet is actually being hosted on Github Pages at the moment, however, due to security issues with Java Applets, the only modern browser that supports them still is IE. Even then it is not able to run the applet because the applet is not signed by a trusted authority (sorry I will not pay for one) and a self-signed certificate for you to trust is not enough. You can look through and try to make sense of the bare code, but I think that really going through and using the Applet alongside the source code is the only way to appreciate the project.
There are 2 options for deploying and testing this project:
- The easiest way is to download the source code from this Git and add it as a project to your Java IDE. The master branch is a Java application with the main method in CalculatorApp.java, while the gh-pages and applet branch are applets that can be run as applets with the same class.
- You can download the gh-pages or applet branch > add the index.html file to your Java exceptions and open the html in Internet Explorer (see here for adding the page as an exception for IE: https://stackoverflow.com/questions/16376087/run-local-java-applet-in-browser-chrome-firefox-your-security-settings-have-b)
Challenges
I actually found this project to be much more challenging than expected (more enjoyable in that regard), this may have just been the hubris of thinking that the calculator application is the simplest one in my OS. Managing the square root function was especially hard, because it can be a nested function (run many times in a row) and it can also be nested in the second operand of a function.
The development of this project followed a path from naive implementation where I more or less banged my head against a wall adding if-else and case statements to work out the logic. This was never meant to be the final product but I needed something to work with. After I got to the point where bugs that were too annoying and I knew it wasn't worth continuing with the design, I decided to architect the design.
I wanted to implement the listener pattern in a couple of places: when a button is pressed, and when the current and historical displays are changed, but implementation was going to be overkill. The components had been split into the CalcnManager (for current input and calculations), the HistoricalCalculations (for the historical calculations), and the the DisplayManager (to manage the output from both of those classes). In the architecture I created there was really only room for 1 to 1 APIs and, therefore, no need to register multiple listeners. What I mean is that each button press only needed to be registered in the CalcManager the CalcManager would then process and communicate what to do next with the HistoricalCalculations and the DisplayManager. Instead of the displayManager listening for each change, the CalcManager just calls updateDisplays() after it is done doing it's thing and the DisplayManager gets the text from the other 2 components without the need to listen for every change. With the CalcManager in the middle, there was no need to overdesign and even if I add a thousand buttons I don't think there would be a need to change the design because you only press 1 button at a time and, logically, the CalcManager decides what happens when that button is pressed.
The Future
Moving forward with this project will be making this into a Scientifc Calculator. In that case, I think I will need to do something with how I handle operation codes. Right now I am simply doing 0-5 (plus, minus, divide, multiply, sqrt, equals, respectively), but with more operations it may be necessary to do something else such as a List pointing to the operator or a function. There are also many catches I will run into and I will probably discover patterns between different operations and be able to group the together into their own functions. For example, log and sqrt operations can be nested and be part of other operations, I think that I would split operations like that out into a different group, while the arithmetic operators (+,-,/,*) are similar to something like the squareroot of y to the x power function, in that they all take 2 operands with the operator in the middle.
The design also isn't that great but I am using JApplet and I don't think it is worth the effort learning how to pretty that up when I can learn other things like real frontend frameworks.