@aaryan_s

Day 24 — Turning My Project into a Standalone Application

Today, I focused on packaging the Wi-Fi Latency Analyzer for its first public release. I also added a reset button feature so people can run the program more than once. I faced significant challenges in packaging my project t submit and make it an accessible desktop application that can be run locally, so AI helped me with this component and it took me tremendous amount of time.

• Compiled the Java application and generated its JAR package.
• Used jpackage to create a standalone Windows application with a bundled Java runtime.
• Debugged and corrected launcher configuration issues involving the classpath and FlatLaf dependency.
• Successfully launched the packaged .exe independently of VS Code.

I also began redoing my GitHub gifs to represent my current project. I have began shipping my project, so this will be my last devlog post for V1 of my project. Thank you to all who have stay tuned!

#Day 22/23 - Major changes added!

I focused on polishing my GUI for the app and implementing features like a connection health system that displays an overall connection health rather than having the user solely look at raw statistics. The app interprets 3 parameters after the ping tests: average latency, jitter, and packet loss. Jitter and packet loss is used to determine stability whereas average latency is used to determine response speeds/delay. There are currently 8 different possible outcomes such as “HIGHLY UNSTABLE,” “VERY SLOW,” “SOME INSTABILITY & SLOW SPEEDS,” and “STABLE.” This helps differentiate instability and speeds/delay as they are not the same thing.

Additionally, Some important visual changes were using red, orange, or green to visually display the connection’s overall health. I Also spent time polishing the test count field box and delay field box alongside polishing button styles. After adjust the panel’s dimensions, they take up window space more appropriately, making the app look proportionate.

Figuring out how to create metric cards (boxes with avg latency, jitter, etc.) and styling the project into an appealable GUI was especially challenging as I had to choose between various possible styles. I also have not been able to fix the test setting boxes missing a bottom side yet. After ~1 day I plan to ship my project officially and submit it to the Congressional App Challenge. Some possible minor features in the future may be light/dark mode and a visual feature, like a graph, to display ping results.

• Day 21 – Modern GUI and FlatLaf Setup – 10/19

• I installed FlatLaf, an open source java library for Java Swing applications. The goal with FlatLaf is to slowly “modernize” my app and overall make it look a lot more appealing to the user compared to it’s old basic java swing vibe. I struggled a lot with implementing FlatLaf and connecting it to my java swing application in VsCode, so I had to use some AI to figure out how to install FlatLat onto VsCode on a Windows desktop. I made a seperate folder called “Lib” and added the FlatLaf download file. For now, I have the core ping functionality/logic down, the basic GUI, and my next steps are clear: I want to have a working, publicly appealing app. Hopefully I can submit this into the Congressional App Challenge within the next week!
• P.S: Starting from this post, from now on, I am beginning to change the format of my Devlogs. Originally, they were very structured and bullet pointed. However, after double checking StarDance guidelines for a proper post, I want to make my posts more understandable and readable starting now. Thank you!

Day 20 — UI Polish & APP Refinement/Debugging

• Further developed the UI to be more presentable to users:
• Consistent color theme: light background, blue primary color, dark text, and light-gray section backgrounds
• Improved the title section with a larger blue title and a subtitle describing the application’s purpose.
• Redesigned the test configuration section by grouping the DNS target, number of tests, and delay controls into a single bordered panel.
  o Added recognizable DNS provider names to the target
  dropdown, such as Cloudflare and Google, instead of displaying only IP
  addresses.
• Added a clean border and light-gray background to test configuration panel to match Live Results section.
• Improved  Start Test button, including styling and a play-button icon.
• Worked on removing the default blue selection highlighting from the dropdown and customizing it renderer/colors.
• Redesigned LIVE RESULTS so it appears as a proper section heading above a bordered results box rather than relying on Swing’s default titled border.
• Added light-gray background + border to the Live Results panel for consistent dashboard-like appearance.
• Learned more about Swing layouts, panels, borders, colors, renderers, component alignment, etc.
• Core functionality is now running, with the desktop application connected to the existing ping backend and displaying latency statistics.

Day 19 — Connecting the Desktop Application

• Connected the GUI to the existing src.ping() backend
  o Integrated calculations for average latency, min/max
  latency, packet loss, and jitter

• Added user input for number of tests and delay between tests
  o Added input validation for test count and delay values

• Used ArrayList to store multiple ping results

• Connected the calculated results to the GUI’s live result labels

• Learned why Double.MAX_VALUE is useful when calculating a minimum value and how Thread.sleep() creates the delay between tests

• Next: Test the full workflow, fix any bugs, and make the GUI responsive before moving toward final polish/shipping :DD

Day 18 - Desktop UI & Connecting the Program

· Connected the UI to the existing src.java ping functionality

· Connecting public classes and calling methods from src.java
· Changed ping() to be accessible from the UI - Learned how classes communicate with each other

· Learned how LatencyAnalyzerWindow → src.ping() → PingResult → GUI works
· Crucial for connecting jitter, packet loss, etc. later

· Kept latency stored as a double and only formatted it for display
3 days left, with ~6–7 hours planned to finish, test, and polish the project :D

Day 17 – Beginning the Desktop App Interface

1. Core program: (everything I have been doing thus far):
o Improved name input validation, including rejecting
blank/space-only names.

o Made the name switch case-insensitive using .toLowerCase()

2. Desktop App:
o Began building a Java desktop app version of my Wi‑Fi Latency Analyzer using Java Swing
· Created LatencyAnalyzerWindow.java, which opens a real application window

o Learned the purpose of Swing components such as JFrame, JPanel, JLabel, JButton

o Added a target-selection dropdown with Cloudflare and Google DNS options
· Added fields for the number of tests and delay between tests

o Added a Start Test button and status message area

o Added Live Results section, placeholders for latency, average latency, packet loss, and jitter

· Edited the ReadMe to better reflect status of project and AI usage during the project

· Planned to connect the interface to real ping data next

Day 15/16 - Debugging, Jitter, Project Organization
15:
· Reorganized my programming workspace so each project has a folder
· Set up a “Coding Projects” folder to keep my future projects under one large folder
· Kept my Wi‑Fi Latency Analyzer in its own project folder
o its Java code, README, license, and VS Code settings stay together
· Created separate Java Practice folder for smaller programs
that help me practice Java concepts
· Reviewed the project files and learned what each one is
used for
· Found and removed an empty unused Java folder from the project
· Made sure my project folders are synced and accessible
through OneDrive
· Overall, continued building good habits for keeping my code organized, separate, and easy to find
16:
· Removed duplicate for loop that was double-counting
successful latency data
· Added jitter to the Wi-Fi Latency Analyzer
o Learned to calculate jitter by comparing each successful ping to the previous successful ping
o Used Math.abs() to find the absolute latency difference
· Added handling for cases where jitter can’t be calculated, displaying N/A (if/else)
· Tested multiple cases to make sure the new jitter calculations and edge cases worked correctly

Day 14 – Terminal Readability / Debugging (Continuation of Day 13)

· Made average/min/max display N/A when there are no successful tests
o Improved failed-test output so failed pings don’t misleadingly show 0 ms

· Fixed the test-number display (TEST 1 OF 2, TEST 2 OF 2)
· Fixed the duplicate results caused by nested loops (loop within another loop)
· Tested failed hostnames and verified that it results in a 100% packet loss
· Kept debugging messages temporarily
· Deferred method refactoring for later

Day 13 – Readability / Displaying Clean Info on User Terminal

· Improved the readability of individual ping results by labeling each test (TEST 1 OF 2, TEST 2 OF 2, etc.)

o Fixed the successful-test counter so successful tests are counted correctly

· Fixed the duplicate test display caused by accidentally using nested loops (loop inside of another loop)

·  Added the foundation for minimum and maximum latency calculations

·  Added success/failure, total latency, + min/max latency analysis into stored results analysis section

·  Fixed a variable declaration issue with totalLatency and successfulLatencyTests (order matters in code)

·  Overall: Day 13 focused on making the output cleaner and turning the stored ping data into more useful statistics

Day 12 – Formatting and Proper Displaying of Data – 8/31/26

· Added packet-loss formatting using printf to display percentages to 2 decimal places.

o Improved the final ping-test summary for readability.

· Verified the program correctly calculates and displays:
o Successful tests
o Failed tests
o Packet loss
o Average latency

· Debugged an issue where the old println formatting was still being used.

· Learned how Java printf formatting works, including %.2f, %%, and %n.

· Chose to postpone additional rounding/refinement work until later if needed.

· Day 12 milestone: The analyzer can now perform multiple ping tests, store the results, analyze them, and presents the key network statistics in a clean summary to the user.

Day 11 – Analyzing Multiple Ping Tests (Collecting Data)

· Added successful and failed test tracking using PingResult.success.
o Calculated the number of successful tests and failed tests.

· Added packet loss calculation:
o Failed Tests ÷ Total Tests × 100

· Implemented average latency
calculation using ONLY successful tests
o Failed tests do not measure any latency, so do not include within calculation

· Fixed the average latency calculation by properly incrementing successfulLatencyTests.

· Verified that multiple ping results are correctly stored in the ArrayList.

· Added a final PING TEST SUMMARY
displaying:
o Successful Tests
o Failed Tests
o Packet Loss
o Average Latency

· Tested the program with 3 pings to Google, successfully producing:
o 3 successful tests
o 0 failed tests
o 0% packet loss
o ~11.67 ms average latency

Day 10 - Multiple Ping Tests & Result Storage

• Implemented an ArrayList to store results from multiple ping tests.

• Added user input for the number
  of ping tests to run

• Added input validation to ensure the number of tests
  is a valid positive whole number

• Created a for loop to automatically run the requested
  number of ping tests

• Stored each PingResult in the ArrayList after every
  successful test.

• Added a results counter using results.size() to verify
  that results are being stored correctly.

• Confirmed the program successfully ran 3 separate tests to Google and stored all 3 results

• Debugged the output and identified/removing the unnecessary extra ping test result

• Verified latency extraction, success/failure detection, and timestamp functionality alongside  new multi-test Ping system for my code

Key milestone: The analyzer can now run multiple

Day 9 – Heavy debugging and Two-Step Verification

· Debugged and refined the program’s user-input and control-flow systems.

o Implemented a two-step verification process using if / else if / else logic to confirm intended program usage
before proceeding.

· Improved the survey consent workflow, allowing users to decline the survey while still accessing the Wi-Fi Latency Analyzer.

· Debugged several issues involving conditional statements, loops, and program termination

o Including changing Scanner object name to Input (more consistent and widely accepted)

· Improved timestamp readability

o Replacing Java’s default timestamp format with a user-friendly date/time format

o Continued testing the analyzer with real network connection

o Verified that latency measurements and timestamps were being returned correctly.

· Edited/added more relevant comments

Day 8 – Debugging and Data Collection
(beta version)

·    Debugged and improved the control flow
(survey ProcessBuilder, pingResult… etc.)

o   Fixed “if else” function displaying semi-colon

o   Added safer handling for latency extraction by checking whether “ms” was successfully found (extracting the number)

·       Verified the latency parser

o  Located time=

o  Extracted Latency text

o  Identified numerical value

o   Converting “[String]” à double

·       Tested program with multiple real DNS servers to verify successful connections

·       Kept detailed debugging output in terminal (eg. Time= …) to verify source code is running properly

·       Edited a few comments to be accurate/up to date

·       Began real world analysis and data collection (very important for future)

·       Refined the project’s architecture and
long-term direction: desktop application as the actual tool + website as the project’s documentation, research, data, and presentation layer

o   Further down the road when I begin developing the GUI/user interface

o   Reasoning for choosing desktop app as tool: websites would only run ping analysis from my computer, not from user’s computer

Day 7 – 8/23/26 – Development and Debugging

Improved survey/user-flow logic

Changed the survey from automatically terminating the program when
the user selects “no.”

Added an option for users to skip the survey and continue to
the Wi-Fi Latency Analyzer.

Added if / else if / else control flow to handle valid
and invalid responses.

Improved input validation

Continued using equalsIgnoreCase() so inputs such as YES, Yes, and yes are treated consistently.
Added handling for invalid responses instead of allowing unexpected
input to break the program.
Identified and corrected an issue where multiple scanner.nextLine() calls were accidentally being
used before the program needed the second input.

Debugging and code cleanup

Identified a major issue where scanner.close() was
accidentally placed inside the age-validation loop.
Recognized that closing the scanner could prevent the rest of
program from receiving user input.
Kept scanner closure at the end of the program instead.

·       
Began Day 7 latency extraction

Built on the existing BufferedReader that reads
the operating system’s ping output.
Added detection for lines containing “time=”.
Used indexOf() to locate the position of the
latency information within the ping output.
Began learning how substring() can isolate the latency portion
of the returned text.
Next step of extracting the numerical ms value and converting it
with Double.parseDouble()

Improved program methodology

Continued developing the project incrementally
Practiced debugging by testing individual sections

Key challenge/cool change: The program is becoming more user-friendly and robust. Users can
now decline the optional survey without losing access to the actual
Wi-Fi Latency Analyzer, while the program separately handles survey
consent and analyzer participation.

Day 5 — Detecting Ping Success or Failure.

Today I implemented and debugged the logic needed to determine whether a real ping to a DNS server succeeds or fails. I learned how ProcessBuilder, waitFor(), and exit codes work together to interact with the operating system, and how they actually evaluate the result of a network test. I also strengthened my understanding of input validation, control flow, methods, and user inputs, including using if/else if/else logic and System.exit(0) terminating the program. I tested the program with both valid and invalid targets and confirmed that it can now identify successful and unsuccessful connections. I also updated my README to better reflect the project’s current development.

Next: Day 6 — extract the latency measurement in milliseconds from successful ping results.

Day 4 progress:
I broke my Ping Latency Analyzer’s source code into two classes: one handling the intro, simple setup, and survey questions, and the other managing the actual ping measurements and user input. Most of today was spent debugging and reorganizing that structure, and I started tracking my work directly in comments (e.g., // Day4:) to keep changes easy to follow over time. I also ensure the project used a single, consistent Scanner object in the Main class instead of creating multiple instances. On the technical side, I learned how ProcessBuilder, Process, start(), and getInputStream() work together to launch and read output from an external process, and I looked into the difference between declaring void on a main method versus omitting it. I applied .equalsIgnoreCase() to make my survey questions case-insensitive, and I compared using while loops versus if/else blocks for validating user input, particularly useful for handling simple yes/no responses.

Day 2/3:

Learned what a target like Cloudfare or Google DNS is within the world of Cloud and Data Engineering. Public IP Addresses for Website Domains. Learned Arrays/List ( [] ). Learned purpose of Classes/Objects (other than Public Class). Create a numbered menu with safe public test targets. Cloudfare: 1.1.1.1; Google DNS: 8.8.8.8. Let the user choose one target. Print the chosen target back to them