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

[Code health] Rearchitect Map Tasks #2601

Open
scolsen opened this issue Aug 1, 2024 · 0 comments
Open

[Code health] Rearchitect Map Tasks #2601

scolsen opened this issue Aug 1, 2024 · 0 comments
Labels
type: code health Improvements to readability or robustness of codebase
Milestone

Comments

@scolsen
Copy link
Contributor

scolsen commented Aug 1, 2024

Our current approach to map task layouts can lead to some view identifier conflict issues, e.g. #2493. In particular we're running into a conflict between identifiers because of the following behavior:

An ID doesn't need to be unique throughout the entire tree, but it must be unique within the part of the tree you search. It might often be the entire tree, so it's best to make it unique when possible.

(see https://developer.android.com/develop/ui/views/layout/declaring-layout).

We currently render all of our map task views dynamically. Each one is a subclass of and abstract map task class. The dynamic view rendering seems to create conflicts between dynamically generated identifiers and existing map view identifiers.

We might be able to simplify things by reducing our use of subclassing and abstraction here. I can imagine a simpler world in which our map tasks have dedicated layouts just as the other tasks possess, this might help with identifier conflicts. We may also need to be smart about reusing/cleaning up existing map views.

@scolsen scolsen added the type: code health Improvements to readability or robustness of codebase label Aug 1, 2024
@gino-m gino-m added this to the GA release milestone Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: code health Improvements to readability or robustness of codebase
Projects
Status: No status
Development

No branches or pull requests

2 participants