MultiCalc Wiki - Glitter-Gnomen/MultiCalc GitHub Wiki

Description

A bit about the process, experiences and issues related to the development of our MultiCalc application.

MultiCalc is an object oriented programming student project. The application is made in the course object oriented software engineering at Aalborg University Copenhagen. The application is developed with c# in Xamarin making use of Gtk.

Sales pitch: The MultiCalc Application offers a great variety of handy on-the-go calculators, such as:

  • Inverse Polish Notation style calculator.
  • Body Mass Index Calculator.
  • Calculator of interests.
  • Measurement Converter.

UML

Versions

Early console version, more code-comprehensive than the final version. For work flow and distribution look here for Github project with history: https://github.com/Glitter-Gnomen/MTR Release: https://github.com/Glitter-Gnomen/MultiCalc/releases/tag/v1.0

Final version build in Xamarin. The Graphical User Interface has been created with the use of Gtk# The Gtk# version turned out to take much less coding, but is also more error-prone, the console version contains more guiding. Github project with history: https://github.com/Glitter-Gnomen/MultiCalc Release: https://github.com/Glitter-Gnomen/MultiCalc/releases/tag/v1.1

Xcode and UIViewController

From before programming was initiated it had been decided that we were to use Xcode with uiviewcontroller. Seemingly, this solution was easy to administer and a nimble way to build a simple and appealing Graphical User Interface (GUI). Early tests done by one of the collaborators of the project had first proved this to be an excellent solution but in the midst of the endeavor reality proved those early tests inaccurate. The first complications emerged in sharing the work on Github: As we accomplished to build and display the GUI on the first computer successfully with no errors or the like, we tried to clone it to others. Neither of the other computers was able to run the same build successfully. Furthermore, these computers started to auto generate a great deal of code in file-documents apparently invisible in both Xamarin, Xcode and the viewcontroller. It was decided that the single PC running on Windows should be excluded from the GUI-production and the collaborator due to some PC-Mac issues, and instead do his work on the interface from one of the Macs later in the process. It was guessed at that the problem surfaced due to the combination of so many different Integrated Development Environments (IDEs). As work continued more complications appeared. When more screens were added to the GUI, strange errors appeared in code that was pre-commented as functions not to be edited by low-level programmers. This caused us to start a new project more than once; sometimes the same unfamiliar errors occurred, sometimes in other foreign classes or functions. In the end it was decided that working with viewcontroller was a hopeless effort – the IDE proved too complicated for our skills and too time consuming to go on with. As a somewhat desperate decision it was decided that we would build the application in Gtk#, making it possible for the PC-user to again work on same terms as the other collaborators.

Xamarin and GTK#

We started out working in Xamarin using empty console classes. The idea was to have the code done and then implement it with a graphical user interface. This approach turned out to be sort of double work. Gtk has a lot of high level pre-defined functions which greatly reduces the number of lines of code. Now we know that the right approach would be to start programming right away in the intended frame work. GitHub: GitHub seems like a powerful tool when working together in groups on the same project. However the software is in no way error proof. If that is due to our limited experience with the software is not yet known. It seems like there are strict rules on who is working on what, and what the different contributors are allowed to edit has to be agree upon before initiating the project. If two members work on the same class (such as the Main) at the same time, error is likely going to occur in form of conflicts. In the group we have experienced a number of conflicts, some easier to solve than others. At one point a high number of conflicts appeared and it was decided to redo the changes one of the members was trying to commit by having the other member make an copy of the project and then sending it to the other member who then could redo the changes. If these kind of conflicts can be avoided the software seems like a nice tool for object oriented programming.