-
-
Notifications
You must be signed in to change notification settings - Fork 356
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
Simplify featureDictionaryFuture
interface in quests
#5219
Comments
@FloEdelmann there are lots of small things that could be slightly improved. It doesn't make sense to open issue tickets for all of those. A PR is welcome anyway. |
Regarding the feature dictionary, it's worth looking what other uses of the feature dictionary there are and whether it makes sense to simplify these, too. (Did you pin the iOS ticket #1892 by mistake?) |
Okay, I just thought I'd open an issue so that we don't forget it. Should we maybe open a collection issue with many of those small tasks (maybe also linking to other issues) instead?
No, I pinned it since it is a highly upvoted issue and contains many actionable tasks, to highlight it for contributors. |
Hm well, any task that has some kind of label in this issue tracker should be actionable. So, I'd say as far as you are concerned about that people who want to contribute to the project but don't know what to do, you don't need to worry, as there is enough of it in the issue tracker. That's my view. Regarding the tasks in the iOS ticket - well I would say, for most tasks I listed there, most of them do not have an additional benefit other than bringing us one step closer to an eventual iOS port. For this reason, I am not sure if it is worth funneling volunteer time into that as long as there is not a big "OK, go!", i.e. someone or an organization leading the charge. |
@FloEdelmann Another class that implements all the FeatureDictionary element filtering stuff (Like FeatureYesNoQuest : SimpleYesNoQuest) and AddAmenityCover etc. uses this instead of SimpleYesNoQuest, so we only need to define the quest-specific parameters in AddAmenityCover,AddIsAmentyIndoor,etc. But we still need to pass featureDictionaryFuture in QuestModule? Or should it work without passing featureDictionaryFuture as a parameter? But i have no idea yet how to do this, so it would need some time. |
Well, don't mind this then. |
Ok, I just didn't want to leave it unanswered, since I was addressed directly. |
Currently, quests that want to use the feature dictionary, accept a
FutureTask<FeatureDictionary>
, e.g.StreetComplete/app/src/main/java/de/westnordost/streetcomplete/quests/QuestsModule.kt
Line 249 in 80781a7
StreetComplete/app/src/main/java/de/westnordost/streetcomplete/quests/amenity_cover/AddAmenityCover.kt
Lines 16 to 18 in 80781a7
As suggested in #5212 (comment) by @westnordost, this interface could be simplified to something like:
@qugebert Would you fancy giving it a try?
The text was updated successfully, but these errors were encountered: