Option to play a sound when close to a quest

[Natenom]

Useful while driving and when the display is off.

Maybe a setting how close one needs to be (100m, 50m, ...).

[westnordost]

If you are driving, you should look on the road..! ;-)

But well, seriously, actually you should.

StreetComplete is more geared towards on-foot survey, actually. Usually, the density of quests - perhaps not now since there are not many yet - is so high, that you do not need to drive anywhere to "find" quests.

I plan to add a feature that displays an arrow at the screen border that points towards the closest quest if none are in view. That should solve the issue of "finding" quests if the quest density is really that low that you have to drive there.
So, I'd close this feature request if you don't mind, and instead implement that feature (later, it's on my todo).

[Natenom]

I use your app while cycling. And I cycle a lot in different areas so it would be nice if I could get a notification when I am close to a quest because the display consumes a lot of battery.

[westnordost]

Ok, sounds reasonable. However, this has no high priority

[rugk]

It would be awesome if this sound (or maybe: just a default Android notification) could also be played when the screen is off (optionally, at least). This could be very useful to save energy and the advantage of Android notifications would be that some devices/custom ROMs/… light up when a new notification is shown and display it shortly so the user can see that this is from this app and maybe could even read the type of the quest or so.

[ghost]

I would appreciate a sound notification while the screen is turned off. I dont want to look always on the screen while I am walking with my dog

[westnordost]

A feature like this would mean that the app continuously needs to monitor your position while in the background. Personally, I despise functionality like this as long it is not clearly announced in the app before.

I am not sure if there is a technical difference between "in the background" and "in the foreground but the screen is off". The latter would be less invasive. On the design side, the app could show a notification just like when it is currently downloading quests that communicates to the user that a "quest proximity alert" is on.

However, as said, this has not high priority right now, there are so many other things that need to be done in this project atm.

[corsac-s]

Sorry for the duplicate, I saw this issue but somewhow from the title it didn't seem it was the same (not sure why :)

Indeed, if this distinction exists I think it'd be better to use “app in the foreground with screen off”. Citymapper (and other navigation apps I guess) do something like that: when you're on your way you don't need the screen to be on to have navigation tips.

Notification would be just fine for me, at least for my use case where I just use the app while commuting and I don't have my eyes directly on the smartphone but rather on the path (I could also use the app while skateboarding, where you definitely don't want to have your eyes on the phone).

Anyway, I can understand low priority, thanks for the work!

[madduck]

+1 for having the app run in your pocket and notifying you when you're within a configurable distance of an unsolved quest.

[HolgerJeromin]

This should be implmented after the filters. For house numbers a want a notification but not for building levels.

[madduck]

Well, why not let the user decide what quests they'd like to get notified for? Sure, this could be post-filters, but it'd probably make sense to consider offering notifications for only a subset…

[lenod]

I also have the same need when walking and there is no quest for a few minutes. I don't necessarily want to look at my phone all along the walk if quests are quite rate. This is in particular true when new quests appear on a path you use regularly and for which you have already solved mosts quests.

I suggests that this could be configured as in the quest-selection menu, with a button on each quest, rotating between:

• no notification (default)
• vibrate
• ring

We could first do this without background mode: the screen is still on while the phone is in your pocket.
Later, we can improve it with: if any quest has one of the latter two options, then run in background mode (with a warning on first use).

[Saijin-Naib]

Was just thinking this would be amazing when I'm out walking or biking!

Currently, I have to keep my phone unlocked and up to my face which can make me a bit distracted. A more "ambient" mode would be great so that I can decide if I want to listen to the notification or not at the given moment.

[Echolon]

Im not sure if this functionality makes sense. I think either you are actively looking at your screen or you are...not. Why getting notified? And also, most areas have bunches of quests on each street. SC would go crazy for most quest where one actually knows that this area should be mapped. So why extra remind?

[eMerzh]

Sorry folks for the notif, just want to add my 2 cents here,

i feel the way google map does it is really powerfull, like maybe you don't need a notification and sound and all, but whenever you open your phone you got a notif like "hey, you where in a shop there right? what is it's name?"
or "seems you've stayed on street X, do you know it's name?"

Sometimes while walking i don't think about streetcomplete, and a small nudge (de-activable) could be really helpful, even apreciated :)

[NotSoImportant]

Thanks for pointing me here.
The usecase I have is when being outside you don't want to look at the phone all the time. Especially when going for a walk with others. But if close by a quest (of type you selected) you would get notified, quickly turn it on, solve the quest and put the it back into your pocket.

[NotSoImportant]

Please also consider making the solution independend of gapps.

[westnordost]

StreetComplete doesn't use gapps at all

[NotSoImportant]

Perfect 👍 Just thought that it might be tempting to use it for notification, but please don't (or implement an alternative in case they are not available on the device)

[BalooUriza]

I can see this as a being useful but only if quite configurable, like notify by quest type and at what distance. Off by default would be good. I suppose this means a bit of an increase in data usage since it would need to download areas it doesn't have cached while not actively using the app, though, for some cases, this is pretty desirable (like walking or bicycling in a busy area).

[westnordost]

Hey, bad news for everyone who would like this implemented. I decided to close this issue as will not fix, after conferring with @matkoniecz about how it could be implemented. During our conversation, a lot more difficulties and/or problematic UX was revealed, so that we don't think anymore there is any reasonable way to implement it. Probably none of the reasons below are absolutely not solveable, but in total, it just adds up to the feature not being reasonable:

So, the use case is that you are on the road, e.g. cycling, thus covering a large area or rather, route. And certain (or all?) quests are really important to you, so you want to be notified (with sound) if any of this is near.

Issues

1. First of all, my standpoint is that this may never be an option that is by default on. So first, users need to find this option. And they also need to configure it. E.g. configure that it should be shown only for certain quest types, not for all. This places this feature already firmly in the "power users" category, which is not the main target audience. Most people will not even know that this feature exists, thus it is automatically worth less to work on it, effort-impact wise.
2. The configuration itself will add another UI complexity in the setting and users of this feature will likely wish that they can also (quickly) turn it off and on (or change for which quests a notification is issued) depending on their current situation, which further increases the scope and complexity of such a feature
3. Second, this issue was written in 2017, one of the first issues overall. Back then, quest types were very few und they were downloaded one-by-one with overpass. Now, the app is using the regular OSM API and downloads all data. This is relevant because looking for certain quest types in a very large area was (much) faster than the current approach, while downloading ALL quests (in a smaller area) is much much faster in the current approach. This is relevant for point 7. Download speed was definitely a big problem with the old (Overpass-based) download, which suggests a usage like "OK I started the download process, now I do something else and hope the app will notify me if anything is nearby" but this is not hte case anymore.
4. This requires accessing the users' GPS location in the background. This adds quite the battery drain, not only because of the always-on GPS, but also because (at least) the quests for which there should be a notification need to be pulled from the local database (i.e. from the disk drive) and the user's distance need to be calculated to each of these in quite short intervals
5. Google is very trigger-happy to throw out apps from their app store that have features that use location in the background (even if they don't) if they have (in their opinion) not a very good reason for that. See App currently not available on Google Play #2909, I am not sure if such an ordeal is worth to go through again on its own
6. notification spam is an issue. Certain quest types (the user selected to be notified about) may occur in big numbers, so users may be overwhelmed by hundreds of notifications about quests. The spammy behaviour (last time I checked) of Vespucci that issues a notification for osmosis warnings is really a disaster and I would want to avoid that. Yes, even if it is the user's fault because it was in his hands to enable the notifications in the first place. Users shouldn't be able to configure the app in a way that it ruins their user experience. Somehow smartly limiting the number of notifications per time interval is possible, but any such "smart" solution runs the danger of not doing what everyone wants or expects.
7. OSM data needs to download in the background for the feature to be useful, because when you are on the road (cycling tour etc), you cover large distances. It's very hard to download all relevant data beforehand. But when the download happens in the background all the time while cycling, huge areas will be downloaded throughout the day while the user itself may not always be aware of this (despite a constant notification about it being shown) because his phone's screen is maybe off and he forgot about it. This further contributes to the battery drain, and the exploiting of the user's data plan. Finally, the downloaded data needs to be persisted somewhere: On the user's phone. Currently, StreetComplete deletes downloaded data after 14 days or so. A three-day cycle tour with "notifications in the background" enabled, as innocent as it sounds, may lead to gigabytes of data being downloaded and persisted. Compare it with having JOSM open all the time while you cycle and download a new bounding box every 30s or so, for several days, but without you having to actually manually do that but with it being a process that happens automatically without you knowing about it all the time. I think this would be quite bad.

[Saijin-Naib]

Thanks for the explanation.

Sucks, but totally reasonable. Thanks for investigating it.

[rugk]

Thanks for that good long reasoning and explanation!

Regarding this, I just want to add a valuable resource:

The configuration itself will add another UI complexity in the setting

Yes, definitively. Each setting has a cost that should not be undeterminated.

[matkoniecz]

ad 7: I managed to download enough data that StreetComplete started having noticeable slowdowns. Just by solving quests along my way as I cycled on multiple longer trips.

Clearing app data completely fixed this slowdowns so it was almost certainly caused by persisting data for a large area.

[westnordost]

Not sure how these slowdowns are posssible though. Fetching the data to display should not take inherently more time as the local database grows. Well, maybe a little, but I don't expect it to be by much. Access to data by bounding box is indexed in the database.

Not sure if database fragmentation (=database becomes scattered over the file system on the disk drive) is possible with SQLite.

Other causes for a slowdown currently don't come to my mind.

Theoretically, displaying all those quests at once on the map may slow down the app. When you move, or even just scroll through the map, ever-more-larger areas with quest pins are pulled from the database for display which involves converting the data to a GeoJson string and pushing that data into tangram-es.

But IIRC each time you solve a quest, all quest pins that are displayed are cleared and the quests for the currently viewed area are pulled from the database again (because tangram-es does not support removing/adding single quest pins, only remove/add everything). Yes, this itself is slow, BUT then only the quests that should currently be in view are pulled from the database, not the potentially huge area that was displayed before. So in other words, this should not get worse over time / with more data.

Maybe next time this occurs, try the following (and report back to me:)

1. restart the app. Does this help?
2. in the app settings, select to "clear the cache". (No need to clear the app data). I think there is no way that this doesn't help.

[matkoniecz]

OK, next time I will do this. There are many cofounders possible, but I am pretty sure that there was a slowdown. As bonus, even uninstalling was tricky: I triggered uninstall and phone become frozen for quite long time (around a minute) and I rebooted it. After that I triggered uninstall the second time which worked.

Sadly, I have not checked how much space app was using or tried clearing app cache then.

[mnalis]

For those adventurous enough to try it, in SC Expert Edition fork v48.0-beta1 there is now an setting which would put notification (with sound) when there are quests nearby!

[westnordost]

Interesting!

@Helium314 : How did you overcome the issues I described in the post that explained why I closed this issue?

Allow viewing photos when creating a note

Is there any reason why this cannot be added upstream, too?

[Helium314]

@Helium314 : How did you overcome the issues I described in the post that explained why I closed this issue?

Currently this is a rather simple implementation.

• It only uses data that is already downloaded, My experiences with Android power saving leads to the expectation that background download and processing will be horribly slow.
• Nothing done against notification spam. I don't like it, but if users want it...
• Currently only uses passive location provider, so location needs to be requested from some other app.
• Not publishing on Play Store, so I don't need to care about Google.

And it's not tested at all on Android versions that require background location permission.

Allow viewing photos when creating a note

Is there any reason why this cannot be added upstream, too?

• I guess that users will want to zoom/pan the photo, which is not implemented. And indeed 15 min after the release there was issue Zooming in on picture review? Helium314/SCEE#392
• I chose a really simple implementation: show an AlertDialog and set the view to an imageView of the photo. Could maybe look better...
• I am not a heavy image note user, and didn't really test it... maybe you want to look at Helium314@5a37dec

[NotSoImportant]

I was unable to get it working. Could you provide exact steps needed?
I tried with

• display on / off
• app beeing the active/foreground app / background
• setting toggled on / off
• location recording in the background by osmand every 2 seconds gpx fix
• sound and vibration on
• different types of quests active or not
  Walked around, but unfortutately did not manage to get any notification...

[mnalis]

Whitelist app via https://dontkillmyapp.com/ instructions?

@NotSoImportant But you should likely open a new issue at https://github.com/Helium314/SCEE/issues as it is implemented in that fork, and not here in upstream StreetComplete. (I only linked to this upstream SC issue to notify interested parties of the related implementation in SC EE fork)

[Helium314]

@NotSoImportant you should see a permanent notification if the setting is enabled, and SC is in background.

[mnalis]

• (ref: Pushes to propose modifications to the user, around #5680)