-
-
Usage Scenarios
-
Pain Points & Concept Overview
-
Main Screen
-
History / Activity Log
-
Workout Screen
🏋️♂️ GymPlayer: Powering Every Lift with Rhythm and Grace
Listen to your own AI-generated music and control your workout through Bluetooth headphones—without repeatedly touching the screen. GymPlayer combines workout tracking, offline music playback, rest management, and gym etiquette into one focused training experience.
Inspiration
GymPlayer began with a simple frustration from my own workouts.
There are countless fitness applications available, but many of them are designed as if workouts happen in a quiet, predictable environment. Real gyms are different. Your hands may be sweaty, the machines you planned to use may be occupied, your music may be playing in another application, and you may need to record a set immediately after lifting a heavy weight.
I repeatedly encountered several small but disruptive problems:
- Switching between a music application and a workout application broke my concentration.
- Entering weights and repetitions after every set was inconvenient, especially when my hands were tired or sweaty.
- Traditional paper records were difficult to manage during training.
- In a crowded gym, machines could not always be used in the planned order.
- Resting between sets sometimes created social uncertainty because other members could not tell whether I was finished with the machine.
- Network connectivity inside gyms could be unreliable or intentionally restricted.
These problems may appear minor individually, but together they interrupt the rhythm of a workout.
I am both a software engineer and a fitness enthusiast. I also enjoy creating AI-generated workout music with Suno. I wanted an application that treated music, exercise logging, rest timing, and gym etiquette as one connected experience rather than four separate tasks.
That idea became GymPlayer.
My goal was not simply to build another workout tracker. I wanted to create an invisible training assistant that helps the user remain focused, move efficiently, and interact respectfully with others in the gym.
What it does
GymPlayer is an Android workout application designed around real gym behavior.
It combines offline music playback, workout routine management, body-metric tracking, rest timers, Bluetooth headphone controls, local data storage, and cloud synchronization.
🎧 Touchless Bluetooth headphone controls
The core innovation is the ability to manage important workout transitions through Bluetooth headphone buttons.
Instead of repeatedly reaching for the tablet, the user can trigger workout actions using familiar media controls.
A typical flow works like this:
- The user completes a set.
- A Bluetooth media-button action marks the set as complete.
- GymPlayer announces that rest mode has started.
- A countdown begins automatically.
- When the rest period ends, the user hears an audio notification.
- Another headphone-button action begins the next set and resumes the music.
The user can remain focused on training instead of constantly interacting with the screen.
⏱️ Rest and gym-etiquette timer
GymPlayer clearly displays:
- The current machine
- The current set
- The total number of sets
- The remaining rest time
- The completion status of the workout
This is useful not only for the person training but also for nearby gym members.
For example, someone can immediately understand that the user is resting between sets and has only one set remaining. This reduces uncertainty and helps balance personal training efficiency with consideration for others.
This design was strongly influenced by Japanese gym culture, where sharing equipment responsibly and minimizing unnecessary occupation time are important.
🎵 Integrated offline music playback
GymPlayer includes local music playback directly inside the workout experience.
Users can play downloaded music files, including custom AI-generated tracks, without depending on a network connection.
The offline-first music design provides several benefits:
- No switching between workout and music applications
- No dependence on gym Wi-Fi
- Reduced interruption during training
- Consistent Bluetooth media-button behavior
- Personalized motivational music
For me, this also meant that the AI-generated music I created with Suno could become part of the actual training workflow instead of remaining a separate creative experiment.
📊 Flexible workout routine management
Gym machines are not always available in the order planned.
GymPlayer allows users to select and complete machines dynamically. If one machine is occupied, the user can move to another exercise and return later without losing track of the remaining routine.
Each machine supports a structured three-set workflow:
- Select the machine.
- Enter the weight.
- Perform the set.
- Enter the repetition count.
- Complete the set.
- Start the rest timer.
- Continue until all sets are finished.
The interface shows completed and remaining exercises at a glance, replacing handwritten notes with a clearer and more adaptable digital workflow.
☁️ Body metrics and cloud synchronization
GymPlayer also records health and body-composition information.
Before training, users can record:
- Blood pressure
- Pulse
After training, users can record:
- Weight
- Body-fat percentage
- Muscle mass
- Body-water percentage
- BMI
- Basal metabolic rate
- Visceral-fat level
All workout and body data is stored locally first. When a network connection becomes available, the user can synchronize the data with Cloud Firestore.
This architecture allows the application to remain fully usable inside the gym while also preparing the data for future analytics.
How we built it
GymPlayer was developed as a VibeCoding experiment using Codex with GPT-5.5 and GPT-5.6.
I defined the product requirements, user flow, interaction rules, architecture, and visual direction through natural-language instructions. Codex then helped generate, revise, debug, and integrate the implementation.
I did not manually write the application line by line. Instead, I worked as the product designer, system architect, tester, and reviewer while using AI as the implementation partner.
Technology stack
- Programming language: Kotlin
- User interface: Android Jetpack Compose
- Media playback: Android Media3 and ExoPlayer
- Bluetooth control: MediaSession and media-button event handling
- Local database: Room
- Application preferences: DataStore
- Authentication: Firebase Authentication
- Cloud database: Cloud Firestore
- File storage: Firebase Storage
- Build configuration: Gradle Kotlin DSL
- Supporting tools: Node.js scripts for machine-data initialization and maintenance
Offline-first architecture
GymPlayer was designed so that its primary workflow does not depend on the cloud.
The local Room database acts as the operational source of truth while the user is training. Workout sessions, exercise records, body metrics, and synchronization status are saved locally.
Firestore serves as the cloud synchronization and future analytics layer.
This approach ensures that temporary network failures never prevent the user from completing or recording a workout.
Bluetooth media-button integration
One of the most technically important parts of the project was connecting Bluetooth media events to workout actions.
Media buttons are normally expected to control playback. GymPlayer extends this interaction model so that the same buttons can also represent contextual workout commands.
The application must determine:
- Whether the user is currently training or resting
- Which set is active
- Whether a button press should control music
- Whether it should complete a set
- Whether it should advance to the next set
- Whether music should resume automatically
This required careful state management across the media player, workout session, timer, and user interface.
Development workflow
The build process was iterative:
- I documented the real gym pain points.
- I converted them into product requirements.
- I designed the core training state machine.
- I asked Codex to generate the initial Android structure.
- I tested the application on a physical Android tablet.
- I reported errors and interaction problems back to Codex.
- I repeatedly refined the code, layout, database structure, and media controls.
- I tested the complete experience during real workouts.
This real-world testing was essential because many of the most important problems could not be discovered through an emulator alone.
Challenges we ran into
Handling Bluetooth controls reliably
Bluetooth headphones, Android devices, and media-button implementations do not always behave identically.
A single press, double press, previous-track action, or play-pause command may be interpreted differently depending on the headset and Android environment.
The challenge was not simply receiving the event. The application also needed to interpret the event safely according to the current workout state.
An accidental button press should not incorrectly complete a set or skip an exercise.
Coordinating multiple application states
GymPlayer manages several connected states:
- Music playing
- Music paused
- Set in progress
- Set completed
- Rest timer active
- Rest timer completed
- Machine completed
- Workout completed
- Local data saved
- Cloud synchronization pending
A change in one area often affects several others.
For example, completing a set may need to:
- Save the repetition count
- Update the current set
- Start the rest timer
- Change the visible interface
- Play an audio notification
- Preserve the music state
- Prepare the next Bluetooth action
Maintaining consistency across these transitions was one of the most demanding parts of the project.
Designing for crowded gyms
The original routine model assumed exercises would be completed in a fixed order.
Real gym usage quickly showed that this assumption was wrong. When equipment was occupied, users needed to jump between machines while still clearly seeing what had been completed.
The workout model and interface therefore had to support flexible ordering without making the experience confusing.
Creating an offline-first synchronization model
Local-first storage sounds simple, but synchronization introduces difficult questions:
- What happens when the same record is modified twice?
- How should failed uploads be retried?
- How does the user know which data has been synchronized?
- How can duplicate records be prevented?
- What happens if the application closes before synchronization finishes?
Building a dependable local workflow while keeping cloud synchronization simple required careful database and status design.
Physical hardware safety
One challenge was completely unexpected.
During real-world testing, vibration from a gym machine caused the Android tablet to fall. The screen cracked.
Although this was an unfortunate accident, it revealed an important product-design issue: software designed for physical environments must also consider hardware placement and safety.
The damaged screen became a kind of badge of honor from real-world testing, but it also inspired future improvements such as:
- Stronger mounting solutions
- Better portrait-mode support
- Phone-optimized layouts
- Reduced need for direct screen interaction
- Wearable or headphone-first operation
Accomplishments that we're proud of
Building a working product from a personal problem
GymPlayer is not only a concept or prototype screen. It is a functioning Android application that I have used during actual workouts.
It solves problems I personally experienced and has already improved the way I train.
Completing a full VibeCoding development cycle
The entire application was created through a VibeCoding workflow with Codex.
I am proud that the project demonstrates how an engineer can move from idea to requirements, architecture, implementation, testing, and refinement while working with AI as a development partner.
The project was not produced by asking AI to generate a single application in one prompt. It required continuous product decisions, debugging, testing, and architectural judgment.
Integrating hardware interaction with workout logic
Reusing Bluetooth headphone controls as workout commands transformed the application from a normal tracker into a more immersive system.
This interaction is simple for the user but required the coordination of Android media APIs, workout states, timers, audio feedback, and local persistence.
Creating a gym-etiquette-focused experience
Many fitness applications optimize only for the individual user.
GymPlayer also considers the people sharing the gym. The visible rest timer and set-progress display make the user's intentions clearer and encourage more considerate equipment usage.
I am especially proud that cultural and social behavior became part of the product design rather than an afterthought.
Receiving positive real-world feedback
I tested GymPlayer during actual training sessions and showed it to my trainer.
The response was positive, particularly regarding its practical workflow and potential for future training analytics.
That feedback confirmed that the project addresses a genuine need rather than only demonstrating technology.
What we learned
The best product ideas often come from small repeated frustrations
GymPlayer was not inspired by a grand technical theory. It began with repeated moments of inconvenience:
- Reaching for a tablet
- Losing track of a set
- Switching applications
- Waiting for a machine
- Wondering whether a rest period was too long
When these moments are observed carefully, they can reveal meaningful product opportunities.
AI-generated code still requires engineering judgment
Codex dramatically accelerated development, but it did not remove the need for software engineering.
I still needed to make decisions about:
- Application architecture
- State management
- Data modeling
- User experience
- Error handling
- Testing strategy
- Firebase configuration
- Security
- Hardware behavior
VibeCoding works best when the human provides clear intent, domain knowledge, evaluation, and continuous feedback.
Real-world testing changes the product
Testing in an emulator could confirm that buttons worked and screens rendered correctly. It could not reproduce sweaty hands, machine vibration, crowded equipment areas, Bluetooth latency, or the social pressure of occupying a machine.
The gym itself became part of the testing environment.
Several of GymPlayer's strongest ideas—including flexible machine ordering, touchless control, and hardware-safety considerations—were shaped through actual use.
Offline-first is a user-experience decision
Offline-first architecture is often discussed as a technical pattern. In GymPlayer, it is primarily a user-experience requirement.
A user should never lose a workout because Wi-Fi is unavailable. The technology should adapt to the gym environment, not force the user to adapt to the technology.
Good interaction design can make technology disappear
The most satisfying GymPlayer experience occurs when the application becomes almost invisible.
The user lifts, presses a familiar headphone button, hears a notification, rests, and continues.
The less attention the application demands, the more attention the user can give to training.
What's next for GymPlayer
🤖 AI-powered training analytics
The next major step is to use accumulated workout and body-composition data to generate personalized insights.
Future analytics may identify:
- Changes in training volume
- Strength progression
- Repetition and weight trends
- Recovery patterns
- Plateaus
- Relationships between body metrics and performance
- Recommended adjustments to workout intensity
By comparing this value over time, GymPlayer could detect whether the user's workload is increasing, remaining stable, or declining.
🎯 Smarter workout recommendations
With sufficient historical data, GymPlayer could recommend:
- The next working weight
- A target repetition range
- Rest-time adjustments
- Deload periods
- Exercise substitutions
- Machine order based on gym availability
- Training plans based on personal goals
⌚ Wearable and voice integration
Future versions may support:
- Smartwatches
- Voice commands
- More Bluetooth headphone gestures
- Heart-rate devices
- Automatic exercise detection
- Hands-free repetition confirmation
The long-term objective is to reduce screen interaction even further.
🛡️ Improved hardware and mounting support
The tablet accident made physical usability a real product priority.
I plan to explore:
- Secure tablet mounts
- Phone-first and portrait layouts
- Larger controls for distant viewing
- Vibration-resistant placement
- Lock-screen workout controls
- Companion wearable interfaces
📈 Richer progress dashboards
Future dashboards may visualize:
- Weekly and monthly exercise volume
- Personal records
- Muscle-group balance
- Workout consistency
- Body-composition changes
- Correlations between training and recovery
- Cloud-backed long-term progress
🌍 Community feedback and open collaboration
GymPlayer began as a solution to my own workout frustrations, but many of these problems are shared by other gym users.
I hope to continue improving the application through feedback, Issues, and Pull Requests from fitness enthusiasts and developers.
Test Account
- Android APK: Download GymPlayer v1
- Email:
test@vibecodingjapan.com - Password:
testtest
Source Code
The project source code and image assets are available in the GymPlayer GitHub repository:
💪 GymPlayer is my attempt to combine code, music, fitness, AI, and thoughtful interaction design into one practical experience—helping people build stronger bodies without losing their rhythm.
Log in or sign up for Devpost to join the conversation.