|
Hi, I compiled the sportstracker sources before although I am new to Java and Maven. Last time it kind of worked so I dared to build the last update. Got me the latest sources and updated Java to AdoptOpenJDK16, Maven was already at 3.6.3 and tried to build the sources which got me a list of error executing "mvn clean package" that I can't interpret and gives me no clue. [INFO] ------------------------------------------------------------------------ |
Replies: 7 comments 8 replies
|
This is a known Kotlin compatibility issue with JDK 16+, that's also commented in the TODO.txt
You can found further information in the TODO.txt. |
|
Thanks that worked well. After adjusting the package script with the right name it could also be packaged |
|
Yep, the constants in the packaging scripts always needs to be adjusted, the commited version is from the latest release. Although that's documented, automation would be nicer ;) |
|
Hi Stefan,
I have been fiddling a bit to make heart rate zones work. For now it is listing and showing them only but it looks to me as a start to integrate it with the existing usage.
Since I could not upload files I send them this way and you can stay in charge of your code.
I envision that there is a store of heart rate zones similar to weights which can be manually and automatically updated.
So anyone can use these whether or not the device provides this information.
When a device is able to provide heart rate zones the last in the list ought to be checked and if the devices provides different heart rates a new set is made. This will take some extra time, since I now concentrated on the first part, the list and did not dive into the existing use of the heart rate zones.
Of course I had to make some design decisions:
- implemented 5 zones for it covers most of the heart rate zone models and did not make the number of zones optional for I am not fluent in Java
- treated it similar to weight, this enables storage and infrequent changes
- edited some icons, funny to do but it does not reflect the applications style yet
Hope you like the idea and could add parts of it in the future.
Kind regards
Peter
… Op 11 apr. 2021, om 13:45 heeft Stefan Saring ***@***.***> het volgende geschreven:
Yep, the constants in the packaging scripts always needs to be adjusted, the commited version is from the latest release. Although that's documented, automation would be nicer ;)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#242 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARRFODJNGNDS2EVIVJ7TFPTTIGDUHANCNFSM42WR72EQ>.
|
|
HI Stefan,
Worked a bit on the remaining issues and at least tackled the reading of heart rate zones from the FIT-file. Made the reading dimension independent, still have to figure out how to match the list and the reading.
Issue not implemented yet is how to deal with the plethora of heart rate zone models although I guess it will be allowing for the maximum possible zones and only filling what is available.
Update contains all files modified from 7.8.2.
Kind regards
Peter
… Op 12 apr. 2021, om 22:54 heeft Posteo pvdmvh ***@***.***> het volgende geschreven:
Hi Stefan,
I have been fiddling a bit to make heart rate zones work. For now it is listing and showing them only but it looks to me as a start to integrate it with the existing usage.
Since I could not upload files I send them this way and you can stay in charge of your code.
I envision that there is a store of heart rate zones similar to weights which can be manually and automatically updated.
So anyone can use these whether or not the device provides this information.
When a device is able to provide heart rate zones the last in the list ought to be checked and if the devices provides different heart rates a new set is made. This will take some extra time, since I now concentrated on the first part, the list and did not dive into the existing use of the heart rate zones.
Of course I had to make some design decisions:
- implemented 5 zones for it covers most of the heart rate zone models and did not make the number of zones optional for I am not fluent in Java
- treated it similar to weight, this enables storage and infrequent changes
- edited some icons, funny to do but it does not reflect the applications style yet
Hope you like the idea and could add parts of it in the future.
Kind regards
Peter
<sport_tracker_with_hrz.tgz>
> Op 11 apr. 2021, om 13:45 heeft Stefan Saring ***@***.*** ***@***.***>> het volgende geschreven:
>
>
> Yep, the constants in the packaging scripts always needs to be adjusted, the commited version is from the latest release. Although that's documented, automation would be nicer ;)
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <#242 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARRFODJNGNDS2EVIVJ7TFPTTIGDUHANCNFSM42WR72EQ>.
>
|
|
Hi Peter, thanks for your input regarding the heartrate zones. I was already often thinking how to manage that and there were also multiple user requests and suggestions on this topic.
With "complicated" I mean that this is not very user friendly, this needs a lot of description and knowledge. It's always a tradeoff, but a simplistic UI/UX is often more important than features for me. And yes, it's also more effort from the technical side. Therefore I favor a simiplistic solution which tries to read and display the heartrate zones defined by the training devices. So when the ExerciseParser implementation is able to read them, then the ExerciseViewer can display them. I have not investigated the FIT file format that much in detail, but it seems that you were able to find the info. Unfortunately I can't see any attachment on this discussion with the sources. Bye, Stefan |
|
I see something went wrong in attaching the files, apparently .tgz is not supported. I 'll call the .tgz file .zip I recognize the time dependance, that is why I choose to use the list of heart rate zones. Since I am not fluent in Java/Kotlin I started with a fixed number of zones but I already found out how to make it flexible in the parser part so I will try to make the list implementation also flexible, will be somewhere next week. |
|
I've fiddled today a bit with the Garmin FIT parser implementation with the goal to parse the current user heartrate zones from the recorded activity files. Although the FIT format documentation contains such data, I was not able to read them from my recorded FIT files (Garmin Fenix 6), this was just missing in the appropriate message data. |
|
That is a bummer. Can you find the data when you read the output of FitCSVTool.jar tool from the Garmin FIT SDK? That way I found out Suunto stores those values there. |
|
Interesting, by inspecting the converted CSV tool I was able to find a message record which contains the hr zone ranges, the max heartrate and the lactate threashold. Unfortunately it's not clear what kind of message and field this is, these are just listed as "unknown". But this is at least a good start :) Thanks for the hint with the FitCSVTool. |
|
Interesting filed " unknown" :) |
|
Went into the various datasets of the FIT SDK and implemented a few of them to have a starting point to add relevant data on Main and Optional tabs. Also tackled the device recognition issue I had in this search |
|
Finally I was able to parse the heartrate zone information from the Garmin FIT files, if it is available (is there on newer devices). You can find the details in the PullRequest #244 which has already been merged to the master branch. The majority of users should now be able to see the heartrate zone information directly from the recorded HRM files without the need for manual configuration and maintainance of these zones. And the displayed zones are now valid for the date of the displayed exercise. Therefore I would prefer not to add an additional user heartrate zone configuration, it just makes the application more complex. And it would also be not clear, which zone configuration is displayed when there is a user configuration and the availability in the HRM file. |
|
Agree for the user entering and complexity. |
|
Regarding the weight I'm a bit sceptical. Yes, it's stored in almost all FIT files, but this is just the weight the user enters once when configuring the initial user profile for the e.g. Garmin watch. This is typically not maintained and fixed for years. It might be maintained automatically when you have a digial scale connected to Garmin Connect, but I guess this will only be the case for a very small fraction of users. |
This is a known Kotlin compatibility issue with JDK 16+, that's also commented in the TODO.txt
Kotlin 1.5.0 will provide a proper solution, meanwhile you need to bypass this problem by setting the environment variable MAVEN_OPTS:
export MAVEN_OPTS=--illegal-access=permitYou can found further information in the TODO.txt.