WorkoutPal

Setting up the SQLite database was one of the first major challenges I ran into. At first, the app was only saving workout names. I hadn’t fully considered how difficult it would be to structure and store related data on mobile.

By using Logcat to debug, I realized the app was trying to save sets, reps, and weights as separate pieces. They weren’t linked together properly as part of one workout. This caused just the name to save, but the rest of the workout details would go missing.

I fixed this by using database transactions and adding checks to make sure all the data was valid before saving. It made me realize that backend decisions impact the user experience just as much as the front end. After all, what good is a workout tracker if it loses your progress?

Implementing the accelerometer and gyroscope required UX consideration. While the technical implementation was straightforward with Android SensorManager, deciding how to present this data demanded more thought.

I ended up positioning the sensor readings at the bottom of the workout activity after testing several layouts. This placement achieved several goals:

• Kept the focus on workout logging (primary task)
• Made sensor data glanceable but not distracting
• Prevented occlusion of key interface elements

While the sensors were posting output and functioning correctly, their real value would come from better interpretation of the raw data. For example, future versions could analyze movement patterns to detect poor form or count repetitions automatically. The use case for these direct values was more niche and probably more suited to intermediate to advanced level lifters who might want to optimize aspects like bench angles (Using the gyroscope data).

The gym-finding feature evolved significantly through development. My initial approach using FindCurrentPlaceRequest failed because, as I discovered, gym locations don't have consistent tagging like restaurants or banks. This was a valuable lesson in API limitations and the importance of prototyping core features early.

After switching to SearchByText, I encountered Error 9011 which is an authorization issue that persisted despite having what I believed was proper API key setup. This became an important lesson in thorough documentation review. The solution came when I realized both the legacy and new Places APIs needed enabling in Google Cloud Console, a requirement that wasn't immediately obvious from the error message alone.

This experience reinforced the importance of comprehensive API research before implementation. It also highlighted how technical hurdles can directly impact user experience. If I hadn’t resolved this issue, the entire maps location finding feature would have been unusable.