Ask once which country the places nearby are in - #1082
Merged
Merged
Conversation
process() looked the country up from each place's own coordinates, once for the address's fallback country code and again inside japaneseAddress(), and each of those is an R-tree query over the country boundaries plus a point-in-polygon test for every candidate. filterLocations() builds fresh LocationDescriptions on every uiState change - roughly once a second while the screen is open - so the whole visible list was re-resolved that often. Everything in the list is within a grid of the user and so in the same country they are, so PlacesNearbyViewModel looks it up from their own location and carries it in the ui state for the rows to share. It only asks again once they have moved 5km, which a country is not something you do by accident. process() takes that as an optional argument and falls back to the feature's own location without one, which is what a search result on the other side of the world needs. japaneseAddress() takes it as a lambda rather than a value so a feature with no quarter or neighbourhood still short-circuits before the lookup. Near a border a place a few hundred metres over the line is now written the way the user's side writes addresses rather than its own. For a list of what's nearby that's the better answer, and the only behaviour this changes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01THRgoVbh1G3pVacd7csDqJ
ef4feb9 added --configure-on-demand to the ios-build and ios-firebase jobs in build-app.yaml, but nightly.yaml has its own copy of the same :shared:compileTestKotlinIosSimulatorArm64 step and was left as it was, so the nightly iOS build still fails on the self-hosted Mac: * What went wrong: A problem occurred configuring project ':app'. > java.lang.NullPointerException (no error message) which is AGP's NdkLocator dereferencing a null File.list() on $ANDROID_HOME/ndk. Same flag, same reason: this job only needs :shared. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01THRgoVbh1G3pVacd7csDqJ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
process() looked the country up from each place's own coordinates, once for the address's fallback country code and again inside japaneseAddress(), and each of those is an R-tree query over the country boundaries plus a point-in-polygon test for every candidate. filterLocations() builds fresh LocationDescriptions on every uiState change - roughly once a second while the screen is open - so the whole visible list was re-resolved that often.
Everything in the list is within a grid of the user and so in the same country they are, so PlacesNearbyViewModel looks it up from their own location and carries it in the ui state for the rows to share. It only asks again once they have moved 5km, which a country is not something you do by accident.
process() takes that as an optional argument and falls back to the feature's own location without one, which is what a search result on the other side of the world needs. japaneseAddress() takes it as a lambda rather than a value so a feature with no quarter or neighbourhood still short-circuits before the lookup.
Near a border a place a few hundred metres over the line is now written the way the user's side writes addresses rather than its own. For a list of what's nearby that's the better answer, and the only behaviour this changes.
Claude-Session: https://claude.ai/code/session_01THRgoVbh1G3pVacd7csDqJ