Deleting and Recovering of Bookmarks and Tracks #9859

New issue

Open

opened 2024-12-12 10:41:50 +00:00 by kirylkaveryn · 0 comments

kirylkaveryn commented

2024-12-12 10:41:50 +00:00

Member

1. Problem Statement

Users need the ability to delete lists, bookmarks, and tracks within the app using various UI actions and buttons across different screens. The deletion process should be consistent, simple, and support a recovery mechanism to restore accidentally deleted elements.

Current Implementation:

Lists Deletion: Lists are moved to a ./Trash directory that is not cloud-synced.
Bookmark Recovery: A fast, in-place bookmark recovery option allows restoring an accidentally deleted file directly from the “Place Page” screen (available until the screen is closed).

2. Key Requirements

Deletion: The process to delete a list, bookmark, or track should be simple, without requiring confirmation dialogs from every app place.
Recovery: Deleted elements must be recoverable from the “Recently Deleted” screen and restored to their original source lists.

3. Possible Solutions

Solution 1: Tagging Deleted Elements in Original KML

Approach: Mark deleted elements as “deleted” directly within the original KML file using a custom tag or an attribute. Include metadata linking to the original group.

Pros:

Simplifies the recovery process since elements remain in the same file.
Eliminates the need for additional file management.
Maintains data structure integrity.
Allows cloud-synced deleted content to remain accessible across all devices and platforms.
Should work well with the bookmarks merging mechanism that will be implemented in the future.

Cons:

Increases the original file size due to retained data.
Adds parsing overhead for systems processing the KML.
Risks cluttering the file with unnecessary metadata.
Deleted elements may not be parsed correctly by other applications or services.

Solution 2: Moving Elements to a Secondary KML File linked by the file name with the source file

Approach: Create a new file in the ./Trash directory with a name derived from the original file (e.g., "my_bookmarks.kml" -> "deleted_my_bookmarks.kml") and move the deleted elements to this new file.

Pros:

Keeps the original file clean and reduces its size.
Separates active and deleted data for better clarity.
Deleted elements are only processed when the user views the “Recently Deleted” screen.

Cons:

Recovery involves reading two files, increasing complexity.
Secondary files in ./Trash could be lost if not managed properly.
Requires additional file-handling logic.
Harder to link source and deleted versions in cases of manual file renaming or deletion.
Deleted elements in ./Trash are not synced across devices.
If both source and deleted_ versions of a file exist in ./Trash, additional logic must resolve conflicts to maintain consistency.

Solution 3: Moving Elements to the Audit KML File that tracks all the deleted content

Approach: Move deleted elements to a single secondary “audit” KML file that consolidates all deleted data. Maintain lightweight references to the deleted elements in the original file.

Pros:

Keeps the original file clean and reduces its size.
Reduces file count by consolidating all deleted data into one audit KML file.
Lightweight references minimize the size of the original file while maintaining traceability.

Cons:

Requires additional serialization/deserialization logic for the audit KML file.
Recovery involves resolving references from the original file to the audit file.
Increases implementation complexity.

## 1. Problem Statement Users need the ability to delete lists, bookmarks, and tracks within the app using various UI actions and buttons across different screens. The deletion process should be consistent, simple, and support a recovery mechanism to restore accidentally deleted elements. #### Current Implementation: - Lists Deletion: Lists are moved to a ./Trash directory that is not cloud-synced. - Bookmark Recovery: A fast, in-place bookmark recovery option allows restoring an accidentally deleted file directly from the “Place Page” screen (available until the screen is closed). ## 2. Key Requirements - Deletion: The process to delete a list, bookmark, or track should be simple, without requiring confirmation dialogs from every app place. - Recovery: Deleted elements must be recoverable from the “Recently Deleted” screen and restored to their original source lists. ## 3. Possible Solutions ### Solution 1: Tagging Deleted Elements in Original KML #### Approach: Mark deleted elements as “deleted” directly within the original KML file using a custom <Deleted> tag or an attribute. Include metadata linking to the original group. #### Pros: - Simplifies the recovery process since elements remain in the same file. - Eliminates the need for additional file management. - Maintains data structure integrity. - Allows cloud-synced deleted content to remain accessible across all devices and platforms. - Should work well with the bookmarks _merging mechanism_ that will be implemented in the future. #### Cons: - Increases the original file size due to retained data. - Adds parsing overhead for systems processing the KML. - Risks cluttering the file with unnecessary metadata. - Deleted elements may not be parsed correctly by other applications or services. ### Solution 2: Moving Elements to a Secondary KML File linked by the file name with the source file #### Approach: Create a new file in the ./Trash directory with a name derived from the original file (e.g., "my_bookmarks.kml" -> "deleted_my_bookmarks.kml") and move the deleted elements to this new file. #### Pros: - Keeps the original file clean and reduces its size. - Separates active and deleted data for better clarity. - Deleted elements are only processed when the user views the “Recently Deleted” screen. #### Cons: - Recovery involves reading two files, increasing complexity. - Secondary files in ./Trash could be lost if not managed properly. - Requires additional file-handling logic. - Harder to link source and deleted versions in cases of manual file renaming or deletion. - Deleted elements in ./Trash are not synced across devices. - If both source and deleted_ versions of a file exist in ./Trash, additional logic must resolve conflicts to maintain consistency. ### Solution 3: Moving Elements to the Audit KML File that tracks all the deleted content #### Approach: Move deleted elements to a single secondary “audit” KML file that consolidates all deleted data. Maintain lightweight references to the deleted elements in the original file. #### Pros: - Keeps the original file clean and reduces its size. - Reduces file count by consolidating all deleted data into one audit KML file. - Lightweight references minimize the size of the original file while maintaining traceability. #### Cons: - Requires additional serialization/deserialization logic for the audit KML file. - Recovery involves resolving references from the original file to the audit file. - Increases implementation complexity.

This repo is archived. You cannot comment on issues.