Sie sind auf Seite 1von 4

YSC3232 Object-Oriented Programming: Final Project Report

Group Members: Geoffrey, Swarnima, and Taha. Available on Github.

Group Name: GST Project Name: WorkLah!

INTRODUCTION

Outline:

We succeeded in creating a simple cross-platform client-server chat application that real-time multiple
client messaging. As mentioned in our project proposal, the primary way in which we sought to
improve existing chat applications was by introducing easy, efficient task management functionality.
On one hand, this—along with the implementation of the chat app itself—was successfully done. On
the other, we note that we experienced various large issues. These can be summarised in the following
broad categories:

1. Ambitious Proof of Concept (Features & Timeline)


2. Code Integration
3. Group Availability

These have been detailed in this report.

CHALLENGES FACED

1. a. Ambitious Proof of Concept: Features

At the time of the submission of the proposal, the group members had at least some idea of how
WorkLah would work, be implemented, as well as what it would look like. These ideas crystallized as
the group worked on the prototype for the second segment of the project: the presentation. During the
presentation, the following key features were highlighted:

1. User Chat Interface(with Group Chat capabilities)


2. Task Management
3. File Transfer
4. Emoji Support
5. Sassy Chatbot
6. Language Translation

User Chat Interface: The group began the work on the networks backend according to the timeline.1
While working on network functionality, once the basic GUI was completed, the group realised that
the original code could be made more efficient by moving most of its information to the server side.

This resulted in a significant restructuring of the backend fairly late in the course of the assignment. In
its final implementation, the server has access to an array of users on the server side, while the client-
side threads act as middlemen for the data streams. Owing to our lack of knowledge regarding
databases, the group was also uncertain about how we would go about setting attributes to messages
and users. Ultimately, we settled on the class Message.java which provided us with a useful, quick

1
The idea for the networks backend was based on the Sockets functionality already practiced in class,
including synchronisation and multithreading.
way of instantiating metadata on a user. This was the first example of a number of implementation
issues that we only found out about, and subsequently resolved, while we were writing the
application.

We originally planned to use Swing for our user interface, but had to quickly pivot to JavaFX once we
realised that Swing did not support rich text and images, both of which were essential for the design
aesthetic we were striving to achieve. This wasted the time of some of our group members, and
delayed the ability of the people working on network functionality to integrate their work with, and
subsequently test their work on the GUI.

Despite extensive debugging, some bugs still exist in the application. For example, the program is
unable to send files multiple times, and sometimes users remain on the “active users” list even after
they are logged out. Perhaps having a fresh pair of eyes to look over our own code would likely have
been helpful, but at the time, the rationale for focusing on our own branches was that, naturally, we
would know them the best. An example of a bug that only came up in the final six hours before the
submission deadline is an unusual side effect of the append function in ChatController.java. Initially,
we had two chat boxes to display messages: one for the sent messages and the others for the received
messages. The rationale behind that was to be able to align sent messages to the right and received
messages to the left. However, we soon discovered that due to a bug, the chat messages did not align
vertically even though the threads that are sending the message (using the method send() ) are
synchronized.

Task Management: This was completely successfully executed by utilizing the Message.java class,
exactly as in the prototype.

File Transfer: This was successfully executed. Files can be sent over through the server and saved in
the directory. There were some bugs that prevented downloading a few times that rarely showed up
though.

Stickers: This was executed with little success. Though we had sourced some sticker API libraries
during our research for the project proposal, upon implementing them, we realized that they were
incredibly slow. We also had code for a GIPHY API implementation, but had to scrap that as it caused
Work Lah to hang and/or crash. Coming to these decisions was hard, and ultimately, as a group, we
had to settle on our current solution, which sends a single emoji as output, from a very limited
selection.

Sassy Chatbot: This was completely successfully executed by utilizing the sassibot package, exactly
as presented in the classroom.

Language Translation: As mentioned during the presentation, we could have not successfully
implement this. As the Google Cloud Translate API is a paid service. We, therefore could not
integrate it into the program.

1. b. Ambitious Proof of Concept: Timeline

We definitely drastically underestimated the amount of time it would take to combine the parts of the
application, and how much time we would need once we realized just how much of the application
needed to be added, updated, or edited. As a result, the group the group had to completely discard its
original timeline.

2. Code Integration
One of the biggest issues we faced was in integrating our code. We discussed the way we were going
to implement our chat app in a detailed manner well in advance, but this ironically caused problems
because although the group members started on their work early, we did so disparately. This meant
that once we all came together, we first had to figure out how all our code fit around each others.

All three members of the group have immensely varied coding styles, and two of the group members
were also completely new to Git. As a result of this, there was a general distrust of Git at first as it did
not seem to be the most efficient way of sharing our code with, or explaining it to, each other. This
resulted in our first mistake. Taha worked on the GUI while Swarnima worked on the network
backend, and then Geoffrey worked on integrating these two very different implementations, which
was both time consuming and frustrating - especially as it could have been easily avoided. We worked
to resolve this by moving to Git as soon as we could.

Unfortunately, this introduced more problems. As mentioned earlier, there was a lack of familiarity
with the platform. As a result, there were some push-pull inconsistencies that took time to figure out
and rectify. These were caused by people directly committing to the master branch, rather than
making commits to alternative branches, and then merging those secondary branches with the master
branch. However, after sitting with each other and working together, we eventually settled on a
system of continuous integration that worked well for all of us.

Once we agreed on how the backend would work, Swarnima and Geoffrey were able to work on an
agreed upon system. Ultimately, everyone worked on a little bit of everything. Swarnima primarily
worked on networks and features, Geoffrey on networks, and assumed the bulk of integrating network
functionality with the GUI, while Taha focused on the GUI and features.

In the last four hours before submitting the assignment, in their haste, people directly committed to the
master branch. This potential improvement to task functionality had the unintended, awful
consequence of reverting changes we wanted, with only an old backup as the working file that we had
no choice, and needed to work on.

Ultimately, we realised that the one of the best ways in which we should have worked together was to
actually employ the plethora of features that GitHub offered in terms of workflow management. In
hindsight, flagging and resolving issues using the Issues tab, as well as using the Wiki tab would have
served us well.

3. Group Availability

To be efficient, and to be considerate of everyone’s time, we split up the work: Taha would primarily
be in charge of the GUI, and Geoffrey and Swarnima would be responsible for the network and
feature implementation.

Due to a number of logistical issues, one of us was bedridden and anaemic over Reading Week,
another’s laptop needed to be repaired, we could only start work in full force slightly less than a week
before the submission deadline on 27th November. This had the unfortunate consequence of the
implementation of networks happening almost completely out of sync with that of the GUI.

Furthermore, Taha, who was responsible for the GUI, was both without a laptop and also fell
extremely ill in the three intense days before the submission deadline. This brought some of the work
to a standstill, as we needed a well-functioning GUI to test and implement our other methods. So,
while code for both the networks and the GUI had already been written, they could not be integrated.
At the time, Taha’s version of the GUI implemented his own version of a simple network. Swarnima’s
implementation was far more complex, and the number of its moving parts made it difficult to relate
to Taha’s GUI. We resolved this by working together to comment out the code properly until we had a
well-functioning GUI.

Geoffrey, even though he had to juggle other assignments, came through for us and devoted his time
to integrating the GUI with the networks - modifying both to suit each other better, especially when
Taha was unwell. Ultimately, it was a combination of sleepless nights, clear communication, and
efficiently dividing up the work that enabled us to work together. At any time since Friday, 26th
November, at least two people were working on the assignment round the clock.

Group members constantly checked in with each other on the status of their code, via Facebook
Messenger and in Git commits.

CONCLUSION

Unfortunately, as a whole, the group believes that the project could have turned out significantly
better. Clearly, the group has a lot to learn in terms of how to manage our workflows, as well as
regarding how to keep each other updated on the requirements of the different parts of the application.
Too often, something would be successfully implemented, but once pushed, we would discover an
error in something that previously had had no errors.

As a final, crucial, overall note, this has underscored the necessity of good, clear comments. All the
group members barely commented out their code - until it was absolutely necessary, and there were
some inconsistencies in basic Java style formatting. This made it incredibly difficult to read each one
another’s code. Not only did this significantly slow down the process because we could not continue
someone else’s work, it also meant that it was extremely difficult to debug the code. In the future,
striking a balance between coding independence and keeping track of the larger picture will be
essential.