Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix #1957 open MarkerEditActivity to receive external marker #1960

Merged
merged 14 commits into from
Jul 30, 2024

Conversation

pstorch
Copy link
Member

@pstorch pstorch commented Jul 15, 2024

Opens MarkerEditActivity to be able to receive external marker for a (completed) track.

@pstorch
Copy link
Member Author

pstorch commented Jul 19, 2024

I pulled out the location retrieval from the TrackRecordingManager.insertMarker() and provide it via Intent to the MarkerEditActivity.
But the insertMarker() is still part of the TrackRecordingManager because it retrieves also the TrackStatistics to set length and duration into the new Marker.
I see that both fields are used in the ChartView. Is that really necessary to draw the Markers on the Chart?
And there are a lot of deprecations, I don't see what the replacements should be.

@dennisguse
Copy link
Member

Long story short: yes, duration and distance are only for the charts. Best guess, we should just remove these as it doesn't always fit.
And the benefit is not that much there.
It may be a leftover from MyTracks: there were statistics marker. Those are gone since ages ;)

For the API, I would just leave these values empty.
To limit the dependency to TrackRecordingManager, I would make the call to it before the API.

If you want to have fun, you can also remove duration and distance:)

@pstorch
Copy link
Member Author

pstorch commented Jul 22, 2024

@dennisguse don't tell me to delete something. I love removing unused code 😉
length and duration are gone now from the Marker. And the Markers are gone from the ChartView.
We could now pull out the insertMarker method from TrackRecordingService/Manger into the MarkerEditActivity or the MarkerEditViewModel.

What is your opinion with EXTRA_TRACK_ID vs. EXTRA_TRACK_ID_LONG? Internally I guess you would like to stick to the Track.Id type. But this is not possible from the outside. That's why we have now two TRACK_ID Intent parameter.

@dennisguse
Copy link
Member

What about creating a new activity like .api.CreateMarker? Then this activity can do the parsing, security checks (if necessary), and we do not expose an internal activity;)

@dennisguse
Copy link
Member

And the DB migration is missing - deletion comes with ugly parts :)

@pstorch
Copy link
Member Author

pstorch commented Jul 22, 2024

What about creating a new activity like .api.CreateMarker? Then this activity can do the parsing, security checks (if necessary), and we do not expose an internal activity;)

That's a good idea. I'll do that. So external interface is separated from the internal. Should we do it for the MarkerDetailActivity as well? Even if it is "just" forwarding?

@pstorch
Copy link
Member Author

pstorch commented Jul 23, 2024

And the DB migration is missing - deletion comes with ugly parts :)

I see the ugly part now. Is it really necessary to drop the two columns from the DB? They are nullable anyway.
The SQLite version in Android doesn't support DROP COLUMN yet, so we would need to copy and recreate the table.

For the public API part, I've created two new Activities for it which receive the external extras from the Intent and forward to the internal Activities if appropriate. Do we want to allow that only if the public API is enabled? The ShowMarkerActivity might be ok, but the CreateMarkerActivity writes to the DB.

@dennisguse
Copy link
Member

Public API: better safe than sorry.
Drop column: there is code for that already in place. You can just copy and adapt it.
Been there done that countless times already :)

@pstorch
Copy link
Member Author

pstorch commented Jul 23, 2024

Been there done that countless times already :)

I know, seen that 😉

Ok, I've added DB version 38 with upgrade and downgrade methods.


private static final String CAMERA_PHOTO_URI_KEY = "camera_photo_uri_key";

private static final String NEW_MARKER_ID = "new_marker_id";

private static final String TAG = MarkerEditActivity.class.getSimpleName();
private Track.Id trackId;
private Location location;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have an internal value object for location.
Reason was that the android location requires lat/lng which is sometimes not present (e.g. only elevation via barometer).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is that? Even TrackPoint is using the android Location.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wasn't there a link to a Position class or record I saw in the email?

}

markers.clear();
// TODO: why do we need to match the markers with the TrackPoints? We will loose the manual added from the map.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dennisguse what do we do here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Old stuff. Back then there was code to only import markers that could be mapped to one TrackPoint. But that is not needed anymore.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More to delete 🙌

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gone

@dennisguse
Copy link
Member

Squashing and reordering commits and this is good to go?

@pstorch
Copy link
Member Author

pstorch commented Jul 30, 2024

Squashing and reordering commits and this is good to go?

Squashing can be done here via the Web UI as well. What do you have in mind with reordering?

@dennisguse
Copy link
Member

@pstorch if you would want separate commits ;)
Squash is fine for me.

@pstorch pstorch merged commit 389c4be into main Jul 30, 2024
3 of 5 checks passed
@pstorch pstorch deleted the export_marker_edit_activity branch July 30, 2024 13:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants