Thank you!
But there is still some bug actually, please be patient 
I am planning an update to stabilize the Android app
Is anyone interested in a GPS tracking app that can be controlled directly from a Pebble smartwatch?
I’ve submitted the upcoming version to Google Play.
I might be cheating a little bit, but I tested it while driving on a business trip, and it seems to be working well.
Even with long hours of driving, repeated pausing and resuming—and even when the connection between the Android app and the smartphone dropped during a stop at a gas station—the app didn’t crash.
The automatic export function worked as intended, so I’m hoping this means the software’s stability has improved.
I’ve done 2 more tests since. The first one failed as well, despite applying every “whitelist-option” for battery usage there is the companion app got suspended after like 1-2 hours. This time it was still running and I could stop and save the recording, but after that 1-2 hour window it just had no data recorded.
Yesterday I did another test (just sitting around watching a series 
) with the “Manage background apps”-Option completely disabled, which seems to have done the trick. There was a segment with a flat (constant) heartrate, which was I think when I dismissed a calendar alert using the back-button and had my watchface open for a few minutes instead if iron.
So it seems my issue is the Motorola tools (running a Motorola Edge 50 Neo) not honoring whitelisting the app and still interfering with it’s background execution. Not sure whether there’s a way using android APIs or some workarounds (maybe different options for the notification?) to prevent this or if Motorola just whitelisted some apps like Strava specifically, because for some it does work. I’ll do some more testing in the future with the “Manage background apps”-Option disabled and see how it goes.
Update: “Foreground services” might be an option to get around the issues I’ve got with the app being suspended/killed https://developer.android.com/develop/background-work/services/fgs (In case you’re not using that already)
Thank you for telling me your situation!!!
Every smart phone maker has unique battery management system… It makes app difficult to work back ground…
Yes, i have added the foreground service to Iron, but I added more foreground service for health at this 2.0.6.
Besides that, Iron sent too much message to pebble, so I cleaned up those things.
Right now 2.0.6 is released!
I’ve recorded a 3 hour climbing session today (“Manage background apps”-Option still disabled) without any problem, so that seems to do the trick at least. I’ll try to enable it again some time soon and test whether your changes in the latest version improved the situation.
Hi, Gabriel here. I tried version 2.0.6 on a couple of kayak trips and walks since it eas released on Aug 21st, and it works great - distance notifications work consistently and the distance measurement seems accurate. Thanks!
The average speed recorded in the history seems off, though - for example, a walk of 2.86km in 41:14 minutes records and average speed of 3.6 km/h - it should be 4.16. (if there’s any additional information I can provice please just let me know).
It’s a minor issue, though. The app is great and very helpful.
Thanks to everyone’s feedback, I believe the Android app has achieved stable performance. Therefore, I plan to move forward with updates to the watch app. In fact, since releasing the PBW update to the Pebble App Store on July 3rd, I have been focusing entirely on improvements to the Android app. Since it is impossible to display additional text or other information in the graph area without modifying the watch app itself, I will be working on that next.
You always reach out to us from the Pebble Up Store, don’t you? Thanks for joining this forum as well!
Also, thank you for letting us know about the issue that looks like a bug. Please allow me to take a look at the Android app regarding the average pace calculation. By the way, where exactly is the incorrect pace being displayed? It would be great if you could send a screenshot
Right, I did contact you previously via the app store. I’ll send you the screenshot via email from there.
Thanks for the last update regarding changing the interval settings mid-activity - I just downloaded V2.0.7
Thank you! I saw your message!
Everytime you try Iron, I really appreciate it
Just tried the latest watch app (V1.3.0) with the latest phone app (V2.0.9), and everything works:
- watch notification work, and you can change the distance for a notification mid exercise
- Average speed on the history page is right.
Thanks a lot for you hard work!
For those with a strong stomach for early-version bugs, please consider testing my Fit Tracker app ( Fit Tracker - Pebble Appstore ). I have used it for several dozen exercise runs that I have uploaded to Strava. I have had one terrific beta tester help me with finding some bugs, and there may be a few more to tease out. Below are some watch and screenshots.
Thank you for trying new version!
I have never imagined watch app side caused issue Anyway I fixed it thanks to you find it such quickly
Building a website—that’s an impressive thing to do
I’ve got one more question/suggestion. Right now the recording is very phone reliant. This week I went rock-climbing and tried to track my heartrate as an “other” workout, but at some point going up the 50-60m rock walls the phone connection obviously broke off.
Taking my phone with me while rock climbing is not an option for obvious reasons. The watch is already quite questionable, but with a bumper and a sweatband on top to protect it, it’s not that bad. (I might buy/build a heavy-duty phone case with climbing attachment at some point, but that’s not a quick fix)
Long story short, here’s my questions/issues:
- If the connection breaks all HR-Data during that time is lost. Is there a way to “buffer” that data on the watch and transmit it to the companion app as soon as the connection is back?
- I observed one of the recordings crashing / aborting probably after a very long time not having a connection, which means I couldn’t even save the recording with the gaps in data where the connection was lost. Is there some intentional stop in such a case or is that some kind of bug / edge case?
Edit: One more thing. Can you please make the menus bigger? (At least for the PT2) Telling apart the activity types is brutal for me. Today I logged a run as “rowing”, because I couldn’t read it well enough.
Hi, I’m not the developer, this is just one opinion.
There is some local storage on the pebble for buffering, but it’s limited and shared among all watch apps. It’s possible to use it for buffering while connection with the phone is lost, but such programming is a bit tricky - it needs to handle running out of local storage and do something rational and explicable then, and possibly provide some setting regarding what to do in such a case.
This type of code is not trivial to debug, since failure conditions depend on how much storage is available and how much data buffered, and are difficult to reproduce. It complicates the code and raises the cost of maintaining it in the long run.
I think the value of such work would depend on how much demand there is for it. Also, it seems to me that the Pebble was not meant to work independently of a phone, and trying to shoehorn it into this role could become costly.
I see your point and agree that it should be done carefully. Easiest safety-measure would be making it a setting defaulting to off.
My point is not making it fully independent (missing watch-side gps already makes that problematic), but rather bridging short-ish gaps in connectivity. In my case that could be climbing, leaving the phone at the ground. Also e.g. swimming (for those daring to risk it) while leaving the phone on the pool side.
The amount of memory required should be quite minimal. A measurement can be stored in a byte (0-255 should be fine for the heartrate) and even with a single-second interval that would be 60 bytes per minute / 3.6 kbytes per hour.
One more safety-measure could be reserving a buffer when starting the recording, that way if it fails it would do so at a time that’s obvious for the user.
I’ll gladly have a look at the code and try to get it implemented cleanly if possible. I have not yet checked if both the pebble and android app are fully open source.
Are you considering putting the app into a “phoneless” state, where it buffers just HR data (and maybe steps)? Makes sense. When connection returns you’ll probably want to make sure that the other data being recorded has not been corrupted by the interruption and that the gap in recording is somehow made clear.
(Sorry, you started me thinking, the problem got stuck in my head) On second thought, it might be easier to switch the app mode between “phoneless” and “connected” manually rather than respond to losing the connection. It would still provide the desired functionality.
Sorry for the delay. I caught a cold and have been stuck in bed (No time for training right now!).
Also I am glad to see such discussions, because this is a watch app discussion channel
Anyway, regarding how to handle Bluetooth connection drops. As you understand, the Iron app relies entirely on the Android app for data storage. The watch app itself holds almost no data locally—probably just the color settings from the color picker screen.
So, when the Bluetooth connection between the Pebble and the Android phone disconnects, data naturally cannot be acquired. Furthermore, when the Iron watch app is closed, step and heart rate data cannot be sent to the Android app. I did once consider using the Pebble SDK’s Background Worker to fetch data, but I didn’t go with that approach because the exact timing of when the data gets sent to the Android app wasn’t clear.
Returning to your point, if the watch app is open in the foreground on the Pebble (like on a Pebble Time 2), it is probably technically possible to temporarily buffer the data on the watch when the connection to the phone drops. However, even if we were to buffer and later sync that data back, it probably wouldn’t have accurate timestamps, so I think we need to be quite cautious about that approach.
Therefore, my main concern is actually why the Bluetooth connection between the phone and the watch is dropping. Since I personally haven’t experienced such disconnections very often, I might need to figure out a way to find out what kind of phone models or specific settings users are running.