Team Workflow Scheduler

One workflow, several clients

The application manages shared team tasks across a JavaFX desktop client and a command-line client for testing raw protocol commands. Both communicate with the same TCP server, so task state must remain predictable even when several users connect at the same time.

Clients send one-line text commands; the server parses each request, updates the shared task list and saves the result to a JSON file. The desktop table refreshes after every operation so the interface stays synchronized with server state.

The complete task lifecycle

Tasks carry a title, assignee, status, priority and ISO-formatted due time. The application supports the full create, read, update and delete workflow while automatically moving unfinished tasks into an overdue state when their deadline passes.

• Add tasks with title, assignee, status, priority and due time
• Update every task field
• Delete tasks by task ID
• List all persisted tasks
• READY · IN_PROGRESS · DONE · OVERDUE · CANCELED
• Automatic overdue-state updates

A small distributed application

The server listens on port 5050 and creates a dedicated ClientHandler thread for each accepted socket connection. Every handler parses one command and delegates it to a shared SchedulerService, which owns the task lifecycle independently of either interface.

A ConcurrentHashMap provides the shared task collection, with synchronized task mutations and serialized saves protecting critical updates. JSON persistence restores the workspace between sessions, while the service recalculates overdue states whenever tasks are listed or changed.

• Thread-per-connection socket handling
• Shared SchedulerService domain layer
• ConcurrentHashMap task storage
• Synchronized task updates and JSON writes

A readable one-line command format

The custom protocol uses a command followed by key-value fields. Its parser accepts quoted values and escaped characters, allowing task titles and assignee names to contain spaces without making the wire format difficult to inspect or test.

• ADD title="Test 1" assignee="Lee" status=READY priority=1 dueAt=2026-01-01T17:00:00Z
• LIST
• UPDATE taskId=1 title="Review" status=IN_PROGRESS priority=2
• DELETE taskId=1

A desktop workflow and a direct protocol client

The JavaFX client separates add, update and delete actions into dedicated tabs and presents server data in a task table. Network requests run away from the UI thread, then use Platform.runLater to update the interface safely after the server responds.

A command-line client provides a second path into the same server. It keeps the protocol visible during development and makes client-server behaviour easier to inspect without the graphical interface.

Behaviour made testable

The project separates domain behaviour from presentation and transport concerns. JUnit 5 tests exercise protocol parsing and formatting as well as adding, listing, updating, deleting, persisting and automatically marking tasks overdue.

Tests use temporary JSON files, keeping service behaviour isolated from the application’s saved task data and making changes safer as the feature set grows.

Two clients, one server

Start SchedulerServer.java first, then run either SchedulerFxClient.java for the desktop interface or SchedulerClient.java for command-line access. Both clients connect to the server on localhost:5050.