Package structure: could it be cleaner?

[dennisguse]

Our current package structure was just taken over from MyTracks and, since then, was not really modified. It seems to be organized by the technical functionalities (e.g., .adapters and .fragment).

From a maintenance perspective, it might be easier to handle if we create something like features packages.

Some examples:

• move everything that is settings related into .settings: activities, fragments, and PreferenceUtils
• create a package for the TrackRecordingService and it's related classes (so called handlers)
• move adapters and viewmodels into a package with their activity
• make the .chart a subpackage of TrackRecordingActivity (where ever this one lives then)

[dennisguse]

• one package per activity (if the activity uses exclusively other classes)
• splitting up StringUtils by package (check other Util classes as well)

[dennisguse]

@rgmf @pstorch @vanous Are there any changes that you have pending? I would want to do this issue soonish and it might lead to some ugly merge conflicts. Technically, it is just moving files around, but still...

[rgmf]

@dennisguse nothing from my side.

[vanous]

Nothing cooking at my kitchen 😄

[pstorch]

I try to tackle the nextcloud permission issue and working at this branch: https://github.com/OpenTracksApp/OpenTracks/tree/nextcloud-persistable-uri-permission. It has a little improvement, but unfortunately doesn't solve the problem yet. Feel free to refactor the packages. My changes are small, I can rebase later.

[dennisguse]

I guess we are done with this issue.