Chris/Exams
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Final push before system formatting

Browse Source
This commit is contained in:
Chris Sanden
2026-05-31 14:05:22 +02:00
commit 5ece589fbe
178 changed files with 164198 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

192
AppDev/texFiles/architecuralDesign.tex Normal file
View File

@@ -0,0 +1,192 @@
\section{Architectural Design and Philosophy}
\subsection{Overview}
Study Sprint was designed around a clear hierarchical productivity model:
\begin{center}
\textbf{Subject $\rightarrow$ Assignment $\rightarrow$ Task}
\end{center}
\vspace{2mm}
This hierarchy became the foundation for how navigation and screen-level interaction was handled. The design aimed to make the application intuitive, reduce redundancy, and to make sure the interface reflected the actual the hierarchy in addition to the back-end database structure.
\vspace{2mm}
The goal for the design was to create an application that feels calm, minimal, and easy to understand. The architecture emphasizes context, structure, and progressive disclosure.
\subsection{Architectural Motivation}
The initial structure of the application that I was given treated several related entities as if they were independent. Subjects, assignments, and tasks were all exposed on the top-level I'm guessing this made basic CRUD operations easier to test while developing the back-end. In any case t his did not match the product model. This version of the code created several problems:
\begin{itemize}
\item tasks could appear without sufficient assignment or subject context,
\item assignments felt detached from their parent subjects,
\item the interface duplicated information across multiple screens,
\item the difference between assignments and tasks are nuanced
\end{itemize}
To fix this, the application was restructured so that the architecture of the interface matched the architecture of the data.
\subsection{Navigation Architecture}
The top-level navigation was simplified into three tabs, and in the final product, two tabs.
\begin{itemize}
\item \textbf{Dashboard}
\item \textbf{Subjects}
\item \textbf{Timer}, now directly integrated into the Task-level
\end{itemize}
This was a deliberate decision. The application in its initial state risked becoming too flat by exposing assignments and tasks as separate top-level tabs. However, assignments and tasks are not standalone concepts.
\vspace{2mm}
The new tab structure gives each destination a distinct role:
\begin{itemize}
\item \textbf{Dashboard} acts as an overview screen for cross-cutting information
\item \textbf{Subjects} acts as the primary entry point into the study hierarchy
\end{itemize}
\subsection{Hierarchy-Driven Screen Design}
The screen flow follows the actual logical structure of the application:
\begin{itemize}
\item the \textbf{Subjects} screen presents all subjects,
\item the \textbf{Subject Details} screen acts as the hub for a single subject and its assignments,
\item the \textbf{Assignment Details} screen acts as the hub for a single assignment and its tasks,
\item the \textbf{Task Details} screen focuses on one task while preserving its parent context.
\end{itemize}
This means that users move deeper into the structure through meaningful parent-child relationships rather than through disconnected CRUD pages.
\subsection{Hub-Based Detail Screens}
A major architectural choice was to turn detail pages into \emph{management hubs} instead of simple read-only detail views.
\subsubsection{Subject Details as a Hub}
The subject details screen was designed to serve as the central management hub for a subject. It contains:
\begin{itemize}
\item subject summary information,
\item status and metadata,
\item actions such as edit and delete,
\item action for creating assignments,
\item assignment sections organized by completion state.
\end{itemize}
This supports a structured flow where the users naturally move from a subject, into an assignment, and then into the tasks that make it actionable.
\subsection{Reduction of Redundancy}
One of the main architectural design principles was the removal of unnecessary duplication
\subsubsection{Removal of Top-Level Assignment and Task Navigation}
Assignments and tasks were removed from the tab bar because they did not function as top-level concepts in practice. Their meaning depends on the parent hierarchy. Keeping them as top-level tabs only worsens the contextual clarity and created repeated list views that duplicated information already available deeper in the hierarchy.
\subsubsection{Reduction of Inline Management Controls}
List screens were simplified so that entity cards primarily function as entry points rather than control panels. For example subject cards no longer contain too many management actions such as inline edit, delete, or progress-heavy UI. Those actions were moved into the corresponding hub screens.
\vspace{2mm}
This follows a simple principle: browsing screens should prioritize selection and orientation, while detail screes should prioritize management.
\subsection{Reusable Upsert-Based Form Design}
Another architectural decision was to reduce duplication in entity creation and editing workflows.
Originally, create and edit flows existed as separate screens even when they used close to identical fields, validation control, and layout. This increased maintenance overhead and produced repeated code.
\vspace{2mm}
To improve this, the application moved toward an \textbf{upsert-based form architecture}. In this pattern, a single screen handles both creation and editing:
\begin{itemize}
\item if no id is present, the form works in create mode,
\item if an id is present, the form loads existing data and works in edit mode
\end{itemize}
This was implemented for core entity forms such as subjects, assignments, and tasks. The benefit is that validation, styling, and layout remain consistent while avoiding unnecessary duplication of screen logic.
\subsection{Shared Utility Extraction}
As the design progressed, common patterns were extracted into globally shared utility modules.
\subsubsection{Date Formatting}
Date and timestamp rendering was centralized in a shared formatting utility. This replaced raw database timestamps with user-friendly display values and ensured consistency across subject, assignment, and task screens.
\subsubsection{Subject Color System}
A dedicated subject color utility was introduced to centralize:
\begin{itemize}
\item the available subject color palette,
\item the type definition for valid subject colors,
\item the mapping between a subject color key and its visual values,
\item helper logic for retrieving the correct visual accent set.
\end{itemize}
This avoided repeated color logic and ensured that subject styling remained consistent across the hierarchy.
\subsection{Design Philosophy}
The architectural design was strongly influenced by a clear philosophy. The UI was intentionally shaped by the following principles.
\subsubsection{Calm over visual noise}
The interface was designed to feel calm and discreet. The goal was not to make everything look awesome, but to make structure understandable and interaction obvious. This led to a restrained card-based UI, reduced redundancy, and fewer competing visual accents.
\subsubsection{Hierarchy over flatness}
The interface should communicate the real structure of the application. The design preserves parent-child relationships instead of flattening all the entities. This improves orientation and helps the user understand where they are in the study workflow.
\subsubsection{Context over abstraction}
The deeper the user moves into the hierarchy, the more important context becomes. For this reason assignment screens display subject context, and task screens display subject context, and task screens display both subject and assignment context. This prevents the user from losing track of where a specific item belongs.
\subsubsection{Consistency over novelty}
The design favors repeated, understandable patterns over excessive variation. Pills, card, spacing, and stable action buttons are reused deliberately so that the application feels predictable. Primary actions continue to use the app-level accent, while subject colors are used for contextual identity.
\subsubsection{Identity through controlled color}
Subjects were given user-selectable accent colors from a predefined palette. This creates a stronger sense of identity without overwhelming the interface. The subject color is inherited by related assignment and task screens, visually reinforcing the branch structure of the hierarchy.
\vspace{2mm}
This color is not used for everything. A key design rule was maintained:
\begin{itemize}
\item \textbf{app accent color} = primary actions,
\item \textbf{subject color} = contextual identity.
\end{itemize}
This distinction keeps the interaction language stable while still giving each subject a recognizable visual signature.
\subsection{Card-Based Interface Design}
The design used a consistent card-based layout. Cards were used to group related information and actions. This supports readability and imporoves structure.
Each card is designed to:
\begin{itemize}
\item present on conceptual unit,
\item reduce visual clutter,
\item support quick scanning,
\item separate context from action.
\end{itemize}
Subject cards emphasize browing and selection. Detail cards emphasize context and management. This distinction was important in making the UI feel more intentional.
\subsubsection{Progress Representation}
Progress indicators were intentionally limited to screens where they carry structural meaning. Rather than showing progress everywhere, progress was only shown on screens such as subject and assignment details.
Progress is represented using both:
\begin{itemize}
\item a visual progress bar,
\item a numeric completion ratio such as \texttt{x / y},
\item remaining assignments/tasks text.
\end{itemize}
This makes progress easier to interpret than a bar alone and avoids ambiguity.
\subsection{Outcome}
The final architecture now emphasizes:
\begin{itemize}
\item clear hierarchy,
\item reduced redundancy,
\item stronger contextual awareness,
\item reusable form patterns,
\item shared utility logic,
\item cleaner, calmer interaction design.
\end{itemize}
As a result, the interface now accurately reflects the study workflow and provides an overall better foundation for usability and maintainability.

1
AppDev/texFiles/conclusion.tex Normal file
View File

@@ -0,0 +1 @@
\section{Conclusion}

1
AppDev/texFiles/discussion.tex Normal file
View File

@@ -0,0 +1 @@
\section{Discussion}

57
AppDev/texFiles/groupDeclaration .tex Normal file
View File

@@ -0,0 +1,57 @@
\large{\bf{Mandatory group declaration}} \\
{\small \hbadness=10000
Each student is responsible for familiarizing themselves with what constitutes permitted aids, guidelines for the use of these, and rules regarding the use of sources. The declaration is intended to make students aware of their responsibility and of the consequences that cheating may entail. A missing declaration does not exempt students from their responsibility.
\begin{center}
\begin{tabular}{ |p{1cm}|p{11.5cm}|p{1cm}|}
\hline
1. & We hereby declare that our submission is our own work, and that we have not used other sources or received any other assistance than what is mentioned in the submission. & Yes \\
\hline
2. & \textbf{We further declare that this submission:}
\begin{itemize}
\item Has not been used for another examination at another department/university/university college in Norway or abroad.
\item Does not refer to the work of others without this being stated.
\item Does not refer to our own previous work without this being stated.
\item Has all references listed in the bibliography.
\item Is not a copy, duplicate, or transcript of another person's work or submission.
\end{itemize}& Yes \\
\hline
3. & We are aware that breaches of the above are to be regarded as cheating and may result in annulment of the examination and exclusion from universities and university colleges in Norway, cf. the Universities and Colleges Act §§4-7 and 4-8 and the Examination Regulations §§ 31.
& Yes \\
\hline
4. & We are aware that all submitted assignments may be checked for plagiarism.
& Yes \\
\hline
5. & We are aware that the University of Agder will handle all cases where there is suspicion of cheating according to the university college's guidelines for handling cases of cheating.
& Yes \\
\hline
6. & We have familiarized ourselves with the rules and guidelines for the use of sources and references on the library's webpages.
& Yes \\
\hline
7. & We have, by majority, agreed that the effort within the group is noticeably different and therefore wish to be assessed individually.
Ordinarily, all participants in the project are assessed collectively.
& No \\
\hline
\end{tabular}
\end{center}}
\bigskip
\large{\bf{Publication agreement}} \\
{\small \hbadness=10000 Authorization for electronic publication of the assignment
The author(s) hold the copyright to the assignment. This means, among other things, the exclusive right to make the work available to the public (Copyright Act. §2).
\\
Assignments that are exempt from public disclosure or are subject to a duty of confidentiality/confidential will not be published.
\begin{center}
\begin{tabular}{ |p{13cm}|p{1cm}|}
\hline
We hereby grant the University of Agder a royalty-free right to make the assignment available for electronic publication: & No \\
\hline
Is the assignment restricted (confidential)? & Yes \\
\hline
Is the assignment exempt from public disclosure? & Yes \\
\hline
\end{tabular}
\end{center}
}
\newpage

126
AppDev/texFiles/implementation.tex Normal file
View File

@@ -0,0 +1,126 @@
\section{Implementation}
The implementation of Study Sprint was carried out as a gradual refinement of both product structure and technical behaviour. Rather than building every feature as an isolated part, the work focused on making the different parts of the application support one coherent study flow. This meant that navigation, CRUD functionality, timer behaviour, persistence, progress tracking, notifications, and onboarding all had to be made to work together as parts of the same product.
\vspace{2mm}
The application was implemented using React Native with Expo on the frontend and Supabase as the main backend for authentication and persistent user data. In practice, this gave the project a relatively fast development workflow while still allowing the application to move beyond a purely local prototype. At the same time, some state was intentionally kept local on the device, especially when that state was closely tied to temporary interaction flow
rather than long-term user data.
\subsection{Core Data and CRUD Implementation}
A large early part of the implementation focused on establishing the application's core academic structure through subjects, assignments, and tasks. These three entities form the conceptual hierarchy of the product:
\begin{center}
\textbf{Subject $\rightarrow$ Assignment $\rightarrow$ Task}
\end{center}
\vspace{2mm}
This structure was implemented through full CRUD support for each level. Users can create, edit, view, and delete subjects, assignments, and tasks, and the entities are linked together through their parent-child relationships. Subjects act as the top-level organisational unit, assignments belong to subjects, and tasks belong to assignments.
\vspace{2mm}
An important implementation decision was to move away from separate create and edit screens wherever the form structure was nearly identical. Instead, the project used upsert-style screens for the main entities. In this pattern, the same screen handles both creation and editing, depending on whether an existing id is passed into the route. This reduced duplicated form logic and made it easier to keep validation, styling, and layout consistent across related flows.
\clearpage
\subsection{Navigation and Screen-Structure Implementation}
As the project developed, it became clear that the original screen structure did not reflect the intended product model strongly enough. Earlier versions exposed subjects, assignments, and tasks too much as parallel top-level concepts, even though they were not conceptually independent. This created duplicated views, weaker context, and a flatter structure than intended.
\vspace{2mm}
To address this, the implementation shifted toward a hierarchy-driven navigation model. Subjects became the main entry point into academic content, while assignments and tasks were accessed through their parent screens instead of being treated as separate top-level browsing areas. Subject details, assignment details, and task details were each implemented more as management hubs than as static detail pages. This made it easier to preserve context and reduced unnecessary navigation noise.
\vspace{2mm}
The dashboard remained a cross-cutting overview screen. As development progressed, the timer was eventually integrated into the task flow as originally intended, instead of functioning as a detached utility page. This was an important decision, as the product goal was not merely to provide a timer, but to connect focused work directly to actual study tasks.
\subsection{Timer, Session Flow, and Break Handling}
The timer implementation developed significantly over time. Earlier versions focused mainly on starting and cancelling sessions, but later iterations expanded the flow into a more complete model with linked tasks, persistent active-session recovery, break handling, and safer finalisation rules.
\vspace{2mm}
A major implementation step was to move the timer into the real task workflow. Instead of starting a generic timer in isolation, the user starts a sprint from a specific task. This makes the session part of the study structure rather than a separate feature beside it. The timer was therefore implemented to receive task context, display relevant task information, and preserve that context when moving between focus sessions and breaks.
\clearpage
The final timer flow supports focus sessions, short breaks, and long breaks. Shared session defaults were introduced so that common durations could be reused consistently across the app. This reduced hardcoded duplication and helped align task-start, dashboard-start, and timer-entry behaviour. At the same time, the implementation kept room for alternative durations when needed, so that the timer would not become too rigid in practice. A total time window of 1 - 60 minutes was chosen based on the research material suggesting that shorter sessions with frequent breaks were the most beneficial \cite{cirillo_pomodoro_2018, pomodoro_scoping_review}.
\vspace{2mm}
Another important refinement was the implementation of a small local study-cycle model for break logic. Rather than deciding long breaks based on total historical sessions, the application tracks the current study cycle more narrowly. This makes the break flow behave more like a real continuous work rhythm and avoids misleading long-break prompts based on unrelated earlier activity.
\subsection{Persistence and Session Reliability}
Persistence in the project was implemented through a combination of Supabase and local device storage. Supabase was used for durable user-specific data such as subjects, assignments, tasks, and recorded session information. Local storage was used for more temporary or interaction-sensitive state, such as active-session recovery, study-cycle continuity, and notification identifiers.
\vspace{2mm}
This split was a deliberate implementation decision. Not all state in the application serves the same purpose. Academic structure and recorded session history belong in persistent backend storage, while temporary control state related to the current device session is better handled locally for faster and simpler recovery.
\vspace{2mm}
As the timer flow became more central to the app, reliability problems in session handling became more important. Different screens could detect expired, cancelled, or replaced sessions, but earlier implementations risked treating those cases inconsistently. To reduce that risk, session-finalization logic was moved into a shared lifecycle helper. This ensured that active local session state and stored session records were handled more consistently when sessions ended, expired, or were replaced.
\vspace{2mm}
This part of the implementation was especially important because the usefulness of the app depends heavily on users being able to trust the timer and recorded study activity. If local UI state and stored session history drift apart, the core study flow becomes less dependable.
\subsection{Progress Tracking and Visual Feedback}
The application also required implementation work around progress tracking so that planning and studying would feel meaningfully connected. Task completion was used as the main source of truth, and this was then used to calculate assignment-level and subject-level progress.
\vspace{2mm}
To support this, related tasks were grouped and evaluated so that progress could be displayed in a more understandable way. This included both visual progress bars and simple completion ratios. The implementation intentionally limited these indicators to screens where they were structurally useful, such as subject and assignment detail screens, instead of placing them aggressively throughout the app.
\vspace{2mm}
This choice was partly technical and partly design-orientated. From a technical side, it required consistent progress calculation based on task state. From a product perspective, it reduced visual clutter and kept browsing views calmer while still making progress visible where it mattered most.
\subsection{Notifications and Reminder Logic}
Another practical implementation area was assignment reminders through local notifications. These were implemented using Expo Notifications and were tied directly to assignment deadlines. The reminder logic schedules notifications for valid upcoming deadlines and updates or cancels them when assignments are edited or deleted.
\vspace{2mm}
An important implementation detail here was that notification identifiers were stored locally on the device rather than in the backend. This made reminder clean-up and rescheduling easier while keeping the reminder system lightweight. The project, therefore, avoided a more complex push-notification architecture since that would have added scope without being necessary for the intended use case.
\vspace{2mm}
Because notification behaviour depends on native capabilities, this part of the project was tested through an Expo development build rather than relying only on Expo Go. That made the implementation more realistic and gave better confidence in behaviour on Android devices.
\subsection{Android Internal Testing and Delivery Preparation}
Toward the end of the project, the application was also prepared for internal testing through Google Play Console. This required uploading the Android app bundle, configuring an internal test track, adding at least one tester email address, and publishing the internal test so that testers could gain access to the application.
\vspace{2mm}
After the internal test was published, Google Play Console provided a direct link to the app listing in Google Play. At this stage, the listing used a temporary name and was not publicly searchable. Access was limited to users with the link and the configured tester access. This made it possible to test the distribution flow in a more realistic way without treating the application as a full public release.
\vspace{2mm}
This step was part of the practical delivery work rather than the product solution itself. It helped confirm that the application could be packaged, uploaded, and distributed through the expected Android testing channel, which was important for validating the project as more than a local development prototype.
\clearpage
\subsection{Onboarding and Low-Friction Flow Improvements}
Later implementation work focused more strongly on reducing friction for first-time users and making the main study flow easier to enter. This included guided setup behaviour, clearer help flows, faster sprint-start paths, and more direct routing from dashboard and task screens into the timer.
\vspace{2mm}
One specific refinement was to make the default sprint flow faster by presenting a sensible default focus duration immediately instead of forcing the user through a configuration step every time. A custom-duration path was still preserved, but it became an optional side path rather than the default interaction.
\vspace{2mm}
The onboarding flow was also adjusted so that incomplete users are routed into setup more consistently, and the first guided sprint was shortened to a small demo session rather than a full, normal-length focus block. This was done to support the product goal that the app should be understandable and usable quickly, without making the first interaction feel unnecessarily heavy.
\subsection{Implementation Outcome}
In implementation terms, the final application became much more than a basic CRUD prototype. The main technical result was a mobile application where planning structure, task ownership, timed study sessions, breaks, reminders, progress tracking, and persistence all support the same study workflow.
\vspace{2mm}
Several of the most important implementation choices were therefore not about adding more features, but about improving coherence between features that already existed. The shift toward hierarchy-driven navigation, task-linked timers, shared lifecycle handling, limited but meaningful progress feedback, and lower-friction session starts all helped move the application closer to its intended product identity.

96
AppDev/texFiles/introduction.tex Normal file
View File

@@ -0,0 +1,96 @@
\section{Introduction}
This report presents the development of \textit{Study Sprint}, a mobile productivity application designed to help students organise academic work and turn that structure into focused study sessions. The core idea behind the application is to reduce the gap between intending to study and actually starting. Instead of treating planning, timing and progress as separate concerns, Study Sprint connects subjects, assignments, tasks, timed focus sessions, breaks and visible progress into one lightweight workflow.
\vspace{2mm}
The motivation for the project came from a common frustration with existing study and productivity applications. Many such applications are either too broad, too feature-heavy or too abstract for students who simply want to organise what they need to study and begin working with as little friction as possible. In many cases, users are forced through unnecessary setup, presented with too many unrelated features, or given timer tools that are disconnected from the work they are supposed to support. Study Sprint was developed as a response to that problem.
\vspace{2mm}
The project therefore focused on a small but coherent feature set. The goal was not to create the most advanced productivity application, but to create one that is easy to understand, fast to use and reliable in practice. This meant prioritising a clear study hierarchy, low-friction navigation, task-linked study sessions, break handling and progress visibility over broader functionality that would have increased the complexity without adding equal value to the intended user.
\vspace{2mm}
The conceptual background for the app was also influenced by the Pomodoro technique, where focused work intervals are separated by short breaks. This was relevant because the project aimed to support concentration, reduce study friction, and make it easier for users to turn vague study intentions into concrete work sessions. Recent review literature also suggests that structured Pomodoro-style intervals can improve focus, reduce fatigue, and support sustained task performance in demanding learning contexts \cite{cirillo_pomodoro_2018, pomodoro_scoping_review}.
\vspace{2mm}
From a development perspective, the project followed an iterative approach. Early prototypes were used to explore structure, interaction and timer behaviour before the application was gradually refined through implementation, testing and revision. Several parts of the application, especially the timer flow and session handling, changed significantly over time as practical issues were discovered and resolved. This process helped move the product from a simple prototype toward a more complete and reliable study tool.
\clearpage
\subsection{Product Vision}
The complete project vision is included in Appendix~\ref{appendix:projectvision}. The following section summarises the most important parts of that vision and shows how they shaped the direction of the product.
\subsection{Target customer}
The primary target group for Study Sprint is students in higher education who want a simple and structured way to organise study work, start focused work sessions and keep track of their progress \cite{projectvision}.
\vspace{2mm}
A secondary target group includes other learners, such as upper secondary students, as well as users who rely on timed work sessions for productivity in non-academic contexts. Even so, the application is mainly designed around student needs, since that is the clearest and most relevant use case for the project.
\subsubsection{Customer needs}
Study Sprint is intended to address a small set of practical needs that repeatedly appear in student work:
\begin{itemize}
\item better focus during study sessions through timed work periods and breaks,
\item simple planning and organisation through subjects, assignments, and tasks,
\item motivation through visible progress and recorded study activity,
\item low friction, so users can understand the app quickly and begin studying without unnecessary setup.
\end{itemize}
These needs are closely related. A study timer becomes more useful when it is connected to real tasks, and planning becomes more meaningful when it leads directly into focused work.
\subsubsection{Critical Product Attributes}
The most important product attribute for Study Sprint is simplicity. The application should be intuitive enough that a user can understand the main study flow almost immediately. A user should be
able to move from creating structure to starting a study session without confusion or unnecessary decision-making.
\clearpage
Reliability is also critical. Since the application depends heavily on timed study sessions and progress tracking, it must handle active sessions, completion, cancellation, breaks, and saved
progress in a dependable way. If the timer flow feels unstable or if recorded study activity becomes inconsistent, the application quickly loses its usefulness.
\vspace{2mm}
A third important attribute is a clear and focused user interface. The design does not need to be visually complex, but it should feel complete, deliberate, and easy to navigate. Since the app is
intended to reduce procrastination rather than add friction, fast and understandable interaction is especially important.
\vspace{2mm}
Finally, scope control is an important product attribute in itself. A smaller and more polished application is more valuable for this project than a broader solution with too many unfinished or
weakly integrated features. A successful version of Study Sprint therefore includes structured planning, task-linked study sessions, break handling, progress visibility, and persistence, while
avoiding feature expansion that would dilute the product's main purpose.
\subsubsection{Unique Seeling Points}
Study Sprint enters a crowded space of Pomodoro apps, study planners, habit trackers, and general productivity tools such as Forest, Focus To-Do, and Todoist. These applications often provide useful
functionality, but many of them are either too broad, too feature-heavy, or too focused on premium features and generalized productivity workflows \cite{projectvision}.
\vspace{2mm}
Compared to these alternatives, Study Sprint aims to be more focused and more student-oriented. Rather than trying to include every possible productivity feature, it combines only the features most relevant to the intended workflow: subject structure, assignments, tasks, timed focus sessions, breaks, and visible progress.
\vspace{2mm}
The main unique selling point of Study Sprint is therefore not feature quantity, but feature connection. The application links planning and studying more directly than a simple timer app, while
remaining much lighter and more focused than broader productivity platforms. This makes it easier for a student to decide what to study, begin working quickly, and see meaningful progress afterward.
\clearpage
\subsubsection{Target Time-frame and Budget}
The target time-frame for Study Sprint was the duration of the project period, ending in early May. Because this work was carried out alongside other courses, assignments, and exams, the project had
to be planned with a strong focus on the effort-to-value ratio rather than feature ambition.
\clearpage
For that reason, the team aimed to establish a working prototype early and then use the remaining time on refinement, reliability, usability, and report work. A realistic development path was to
first define the product structure and screen flow, then implement the core planning hierarchy, timer functionality, session persistence, break flow, and progress tracking, before focusing on testing and polish \cite{projectvision}.
\vspace{2mm}
The financial budget for the project was expected to be minimal. The application was developed using free or low-cost tools and frameworks, with time being the main practical constraint. This made it especially important to avoid unnecessary complexity and to concentrate on the parts of the application that contributed most directly to the intended study experience.

73
AppDev/texFiles/method.tex Normal file
View File

@@ -0,0 +1,73 @@
\section{Method}
The development of Study Sprint followed a practical and iterative project method. Rather than treating the application as a fixed specification that could be implemented in one pass, the team worked from a product vision, built early versions of the core functionality, and then refined the solution as weaknesses became clearer through use, testing, and discussion.
\vspace{2mm}
This approach fit the nature of the project well. The main challenge was not only to implement isolated features, but to shape a small mobile product that felt coherent, reliable, and easy to use in practice. Because of that, the method had to support both technical implementation and repeated revision of structure, flow, and scope.
\subsection{Vision-Driven and Scope-Conscious Development}
The project vision functioned as the main strategic starting point for the work. It defined the target users, the most important customer needs, and the product attributes that mattered most for success. In particular, simplicity, reliability, low friction, and realistic scope were treated as guiding constraints throughout the project \cite{projectvision}.
\vspace{2mm}
This had a direct effect on development priorities. Features that supported the core study flow were given precedence, while ideas that would broaden the product without strengthening its main purpose were de-prioritised or excluded. That is also why the report separates requirements into must-have, should-have, could-have, and will-not-have categories. This prioritisation made it easier to protect the project from feature growth and to keep effort focused on the parts of the application that contributed most directly to the intended user experience.
\clearpage
\subsection{Iterative Prototyping and Refinement}
The practical development process was iterative. Early work focused on establishing the underlying structure of the app, including navigation, CRUD support for subjects, assignments, and tasks, and the first timer-related flows. These early versions were useful for confirming that the main ideas were technically possible, but they also revealed architectural and usability problems that were not obvious at the planning stage.
\vspace{2mm}
One clear example was the relationship between the app's conceptual data model and its screen structure. The intended hierarchy was always \textit{Subject $\rightarrow$ Assignment $\rightarrow$ Task}, but earlier versions exposed assignments and tasks too much as top-level concepts. As the app was used and reviewed, this was recognised as a source of redundancy, weak context, and unnecessary navigation complexity. The architecture was therefore revised so that the interface reflected the actual hierarchy more clearly.
\vspace{2mm}
The same pattern appeared in the timer and session logic. Initial timer behaviour was gradually replaced by a more complete session model with focus sessions, breaks, persistence, and safer finalisation rules. Several parts of the timer flow changed more than once as practical issues were discovered, especially around routing, active-session recovery, break handling, and reliability. In that sense, prototyping was not only used to create a first version, but also as a way to expose where the product model was still too weak or too rough.
\subsection{Incremental Delivery of Core Features}
The implementation was carried out in layers rather than as one large build phase. A basic feature foundation was established first, followed by increasingly product-specific refinement.
\vspace{2mm}
At an early stage, the work concentrated on basic entity management and data flow, such as creating, editing, viewing, and deleting subjects, assignments, and tasks. After that, the project moved further toward the product's intended identity by adding progress tracking, local reminders, more structured navigation, and task-linked study sessions. Later work focused more strongly on reducing friction in the main study flow, improving onboarding, and making the timer and break cycle more robust.
\vspace{2mm}
This incremental method helped reduce risk. A simple but working baseline could be established first, after which the team could decide which refinements actually improved the product and which ideas were unnecessary within the project's time constraints.
\subsection{Testing, Verification, and Revision}
Testing in this project was not treated as something that only happened at the end. Instead, verification and revision were interwoven with development. When new functionality was added, the result was checked, weaknesses were identified, and the implementation was adjusted before the project moved further.
\vspace{2mm}
The notes show two main forms of verification. The first was manual testing of the app's actual behaviour, especially in flows where user interaction and timing mattered. This was particularly important for the timer, break handling, onboarding flow, routing, and notification behaviour. The second was technical verification through static checks such as linting and TypeScript compilation, which helped detect invalid code, inconsistent types, and integration mistakes before further changes were added.
\vspace{2mm}
This combination was necessary because the project contains both logic-heavy and interaction-heavy features. Static checks can confirm that the codebase is structurally valid, but they cannot on their own confirm that a timed session flow feels correct or that screen transitions behave as intended. Manual testing was therefore especially important whenever reliability, usability, or flow clarity were central concerns. For native-dependent functionality such as notifications, a development build was also used instead of relying only on Expo Go, since that gave more realistic behaviour during testing.
\subsection{Collaboration and Work Organisation}
The work was organised as a collaborative group project with regular meetings, shared responsibility, and ongoing task distribution. According to the project vision and group contract, the group planned to meet weekly to review progress, divide work, and discuss problems as they appeared. Discord functioned as the main communication channel between meetings, making it easier to adjust responsibilities when needed.
\vspace{2mm}
Because the project remained relatively limited in scope, with a small team and a fairly small number of central features, the group did not use a heavier Scrum-oriented project management setup with dedicated ticket tools such as Taiga. In practice, many tasks were easier to define, discuss, and re-prioritise through regular meetings and direct communication than through maintaining a formal backlog with only a few active items. This reduced unnecessary administrative overhead and made the work organisation more appropriate for the actual scale of the project.
\clearpage
Version control and shared documentation were important parts of the method. GitHub was used to manage source code and changes over time, while notes and work reports were used to document completed work, encountered problems, and follow-up decisions. This created a lightweight but useful development trail that supported both collaboration and report writing.
\subsection{Why This Method Was Appropriate}
An important reason for choosing this style of method was that Study Sprint is a product where usability, flow, and reliability matter at least as much as raw feature count. A more rigid process could have described the intended system early, but it would have been less useful for improving the real experience of moving from planning work to starting a study session.
\vspace{2mm}
The iterative and scope-conscious method therefore matched the project well. It allowed the team to begin with a workable prototype, identify weaknesses through repeated review and testing, and gradually move the application toward a more coherent and dependable final form without losing control of scope.

97
AppDev/texFiles/requirements.tex Normal file
View File

@@ -0,0 +1,97 @@
\section{Requirements}
Requirements are critical for measuring the success of the project. They are both the team's guidelines for the project and determine what users can expect from the product.
\vspace{2mm}
Requirements will be divided into two main parts, those being functional and non-functional requirements. Functional requirements define what the system should do, whereas non-functional requirements define how the system should perform \cite{geeksforgeeks_functional_nonfunctional_requirements}. Beyond that, functional/non-functional requirements will both be split into 4 subcategories. "Must have", "Should have", "Could have" and "Will not have" requirements.
\subsection{Functional Requirements}
\subsubsection{Must Have}
\begin{itemize}
\item[FR1:] Users must be able to create, edit, delete and view subjects
\item[FR2:] Users must be able to create, edit, delete and view assignments
\item[FR3:] Users must be able to create, edit, delete and view tasks
\item[FR4:] Users must be able to start and cancel timed study sessions
\item[FR5:] Users must be prompted to take breaks after timed study sessions
\item[FR6:] The app must connect a study session to a specific task
\item[FR7:] Subjects, assignments, tasks and study sessions must persist between app instances to avoid losing data
\item[FR8:] Tracking of studying progress
\end{itemize}
\subsubsection{Should Have}
\begin{itemize}
\item[FR9:] Ability to set assignments and tasks as completed/not completed
\item[FR10:] Ability to set subjects as active/inactive
\item[FR11:] Notifications for important events
\item[FR12:] Users should be able to cancel active study session
\end{itemize}
\subsubsection{Could Have}
\begin{itemize}
\item[FR13:] Authentication could be set up to allow for cross device persistence and greater safety
\item[FR14:] Users could be able to customize break and study session durations
\item[FR15:] Users could be able to pause study sessions
\end{itemize}
\subsubsection{Will Not Have}
\begin{itemize}
\item[FR-W1:] Study groups will not be included, as this was deemed too large in scope for the simple design philosophy of the project
\item[FR-W2:] Calendar integration will not be included
\item[FR-W4:] Advanced analytics will not be included
\end{itemize}
\subsection{Non-Functional Requirements}
\subsubsection{Must Have}
\begin{itemize}
\item[NFR1:] The project must have a functional UI where elements do not overlap and do not become unreachable
\item[NFR2:] The UI must be easy to understand / low friction
\item[NFR3:] Project must be open source on GitHub
\item[NFR4:] Simple navigation between screens
\item[NFR5:] Timer must be reliable at tracking time during study sessions and breaks
\end{itemize}
\subsubsection{Should Have}
\begin{itemize}
\item[NFR6:] Loading states between different pages being rendered
\item[NFR7:] Page not found / error pages if something were to go wrong during interaction with, for example storage/database
\item[NFR8:] A custom UI style
\item[NFR9:] App should be prepped and ready for android deployment, and should be published on the Google Play Store if time allows for it
\end{itemize}
\subsubsection{Could Have}
\begin{itemize}
\item[NFR10:] Display daily motivational quotes to encourage users to study
\end{itemize}
\subsubsection{Will Not Have}
\begin{itemize}
\item[NFR-W1:] Advanced animations
\item[NFR-W2:] Be published on App Store
\end{itemize}

87
AppDev/texFiles/solution.tex Normal file
View File

@@ -0,0 +1,87 @@
\section{Solution}
The final solution developed for Study Sprint is a mobile productivity application that combines lightweight planning, task-based study sessions, breaks, and visible progress into a single workflow. The purpose of the solution was to help students move more easily from deciding what to study to actually starting focused and efficient work.
\vspace{2mm}
Rather than functioning only as a timer, or as a planning tool, the application connects the two. A user can create academic structure, chose a concrete task, begin a timed study sprint, continue through short or long breaks, and return to an overview that shows both recent activity and broader progress.
\vspace{2mm}
This product direction was influenced by the Pomodoro technique, where work is divided into focused intervals separated by breaks. That background was relevant because the goal of the project was not simply to count time, but to support a more sustainable and actionable study rhythm. Upon reviewing literature on Pomodoro-style study intervals, we found consistent suggestions that structured work-and-break cycles can improve focus, reduce fatigue, and support sustained performance in demanding learning situations \cite{cirillo_pomodoro_2018, pomodoro_scoping_review}. For that reason, the final app was built around the idea that planning and focused study should be tightly connected rather than treated as separate tools.
\subsection{Main Components of the Solution}
The solution consists of four closely connected parts;
\begin{itemize}
\item a planning system for subjects, assignments, and tasks,
\item a task-linked timer flow with focus sessions and breaks,
\item a dashboard for overview, progress, and quick actions,
\item persistent storage and supporting logic for user data, active sessions, and reminders.
\end{itemize}
These parts are intended to support one continuous study flow. The user should be able to define what to work on, start working without unnecessary setup, continue through breaks when appropriate, and return to a screen that still gives a clear sense of what has been done and what remains.
\subsection{Planning and Study Structure}
The planning part of the solution gives the user a structured way to organise academic work through subjects, assignments, and tasks. This allows larger and more abstract study obligations to be broken down into smaller, more digestible units. In practice, this matters because focused work sessions are easier to begin when the user is working from a clearly defined task rather than from a vague intention such as "study more" or "work on the course".
\vspace{2mm}
This means that the planning system is not only included for book-keeping. It plays a direct and central role in the app's main purpose by making it easier to convert study plans into concrete sprint starts.
\subsection{Task-Linked Sprint and Break Flow}
The most central part of the solution is the timer flow. In the final app, a sprint is started from a task, not from a detached timer utility. This ties focused work directly to a chosen piece of study content and makes the session feel like part of the planning workflow rather than a separate feature beside it.
\vspace{2mm}
The timer supports focus sessions as well as short and long breaks. In the final version of the app, the default timing model follows a familiar Pomodoro-style rhythm;
\begin{itemize}
\item a default focus session of 25 minutes,
\item a default short break of 5 minutes,
\item a default long break of 15 minutes upon completing four focus sessions.
\end{itemize}
These default values were chosen because they match the common Pomodoro model closely enough to feel familiar, whilst still fitting the project's broader goal of low-friction study support. The point was not to claim that one exact timing is universally optimal, but rather to provide a sensible default that helps the user begin immediately without having to configure the session first.
\vspace{2mm}
At the same time, the app was not designed as a rigid timer. The solution still allows for alternative session durations when needed. This was important because flexibility matters in real study situations, but the default path was intentionally kept simple so that customisation would not become a barrier to getting started.
\clearpage
\subsection{Dashboard, Progress, and Guided Flow}
The dashboard acts as the application's overview and next-action screen. Instead of functioning only as a static home page, it gives the user a way to resume an active session, start a sprint from upcoming tasks, and review recent study activity. This makes the dashboard part of the workflow rather than merely a simple summary screen.
\vspace{2mm}
The solution also includes visible progress indicators and recent-activity summaries so that study effort is easier to interpret over time. This supports motivation and orientation by showing not only what the user planned, but also what they have actually completed or spent time on.
\vspace{2mm}
To reduce friction further, the app also includes a guided setup and lightweight help flows. These parts of the solution are especially important for first-time users, as they make the main structure and intended study rhythm easier to understand before the app contains much user-created content.
\subsection{Persistence and Supporting Functionality}
The solution uses Supabase as the main backend for stored user data such as subjects, assignments, tasks, and recorded session information. This provides persistence beyond a single app instance and gives the app a clearer basis for authenticated, user-specific data.
\vspace{2mm}
At the same time, local storage is used for state that is more device- and interaction-specific, such as active-session recovery, study-cycle continuity, and some reminder-related information. This division is useful because not all app state serves the same role. Some data belongs to the durable academic structure, while other data belongs to the immediate behaviour of the app on the device.
\vspace{2mm}
The solution also includes local assignment reminders through notifications. This extends the application beyond passive planning by helping users notice approaching deadlines without requiring a more complex push-notification infrastructure.
\clearpage
\subsection{Why This Solution Fits the Product Goal}
The final solution fits the goals of the project because it remains focused on a small set of connected features rather than trying to become a broad productivity platform. Planning, sprint starts, breaks, reminders, and progress tracking all support the same main objective: helping students begin meaningful study work with less friction and maintain that work through a clearer rhythm of effort and recovery.
\vspace{2mm}
In that sense, the main strength of Study Sprint is not the quantity of features, but the connection between them. A timer alone does not help the user decide what to study, and a planner alone does not help the user begin. The solution developed here is intended to bridge that gap in a lightweight and student-orientated way.

1
AppDev/texFiles/summary.tex Normal file
View File

@@ -0,0 +1 @@
\section*{Summary}

96
AppDev/texFiles/testing.tex Normal file
View File

@@ -0,0 +1,96 @@
\section{Testing}
For the testing section of this project, the group focused mostly on creating tests that verify CRUD behaviour of subjects, assignments and tasks + an auth guard test. The reason that these specific tests were chosen is because they are core to the requirements while also being relatively obvious on how they should be set up.
\vspace{2mm}
An important note for all of these tests is that the tests should not actually interact with elements like \texttt{expo-router}, \texttt{asyncStorage}, \texttt{expo-notifications} or API's like \texttt{supabase}. Instead, they should be mocked/simulated using \texttt{jest.mock}.
% forklare hvorfor de mockes, og ikke tester direkte med UI?
\subsection{Subject Tests}
\subsubsection{Create Subject Test}
For the Create Subject test, the goal was to verify that a new subject can be created through the creation branch of the \texttt{handleSubmit} function in \texttt{upsertSubject.tsx}. Since this component normally relies on \texttt{supabase} and \texttt{expo-router}, these have to be mocked using \texttt{jest.mock}.
\vspace{2mm}
The test mocks \texttt{supabase.auth.getUser} so that a fake authenticated user exists for the test. This is important because the row level policy implemented in supabase for creating subjects requires authentication, meaning the test needs to simulate a logged in user. The supabase insert chain is also mocked, meaning one call to \texttt{insert}, one to \texttt{select}, and one to \texttt{single}. With this chain the test can simulate the supabase command used in the component.
\vspace{2mm}
For the actual test logic, the test starts by mocking a resolved value for \texttt{single}. This represents a successful database response after creating the subject. The test then renders the actual \texttt{UpsertSubject} component. Then it fills in the title field to pass the requirement that title must not be empty and presses the submit button. At this point it waits for asynchronous logic to finish.
\vspace{2mm}
Finally, the test defines its expectations. It expects \texttt{supabase.from} to have been called with \texttt{subjects}, which confirms that the correct table was targeted. Then it expects the mocked \texttt{insert} to have been called with an object containing the subject title and authenticated user id. Next, it expects the mocked \texttt{select} and \texttt{single} to have been called, completing the insert chain. Finally, it expects \texttt{router.back}, which confirms that the user would be routed back upon subject creation. If all these expectations pass, the test passes.
\subsubsection{Update Subject Test}
For the Update Subject test, the goal was to verify that an already existing subject can be updated through the update branch of the \texttt{handleSubmit} function in \texttt{upsertSubject.tsx}. Since this component normally relies on \texttt{supabase} and \texttt{expo-router}, these have to be mocked using \texttt{jest.mock}.
\vspace{2mm}
The test mocks \texttt{supabase.auth.getUser} so that a fake authenticated user exists for the test. This is important because the row level policy implemented in supabase for updating subjects requires authentication, meaning the test needs to simulate a logged in user. The test also mocks \texttt{useLocalSearchParams} so that the component receives an existing subject id. This makes the component behave as if it is updating an existing subject rather than creating a new one. The supabase update and select chains are also mocked. For update this means one call to \texttt{update}, and one to \texttt{eq} and for select this means one call to \texttt{select}, one to \texttt{eq} and one to \texttt{single}. With these chains the test can simulate the supabase commands used in the component.
\vspace{2mm}
For the actual test logic, the test starts by mocking a resolved value for \texttt{single}. This represents a successful database response after selecting the subject. It also mocks a resolved value for the update chain \texttt{eq}. This represents no errors upon submitting the update. The test then renders the actual \texttt{UpsertSubject} component. Then it verifies that the title field is filled in to pass the requirement that title must not be empty and presses the submit button. At this point it waits for asynchronous logic to finish.
\vspace{2mm}
Finally, the test defines its expectations. It expects \texttt{supabase.from} to have been called with \texttt{subjects}, which confirms that the correct table was targeted. Then it expects the mocked \texttt{select} to have been called. After that it expects the mocked \texttt{update} to have been called with an object containing the subject title and authenticated user id. Next, it expects the mocked update chain \texttt{eq} to have been called with a subject id, completing the update chain. Finally, it expects \texttt{router.back}, which confirms that the user would be routed back upon the subject update. If all these expectations pass, the test passes.
\subsubsection{Delete Subject Test}
.
\subsection{Assignment Tests}
\subsubsection{Create Assignment Test}
.
\subsubsection{Update Assignment Test}
.
\subsubsection{Delete Assignment Test}
.
\subsection{Task Tests}
\subsubsection{Create Task Test}
.
\subsubsection{Update Task Test}
.
\subsubsection{Delete Task Test}
.
\subsection{Auth Guard Test}