https://support.google.com/faqs/answer/6325474

Users can only report problems from the website. However, problems (e.g. location does not exist) are typically encountered in the field.

Amazon's Fire OS is based on Android, so it may be easy to support.

• Compatibility testing tool
• Developer account
• App submission
• Developer guide (Chapter 2 in particular)

The locale-specific full type names "Common name [Scientific name]" should now be injected into the add_location form type dropdown (also used for editing).

Although not experienced on Android (Nexus 5x), one user reports this behavior on an iPhone 6s+:

It's just a bit temperamental in that I had to hold my finger on the point for a longer than usual time to get the curser where I wanted to edit the text.

(reported by Lady J)

"name" is now jus the (en) common name, not the full name "Common name [Scientific name]" (as needed by the type selectors). Such a field can be added client-side to the data once downloaded.

@ezwelty said:

@dbalatero types.json already returns common name fields and scientific_name. This is a reminder to generate a locale-specific full name – <Localized common name, or English common name if not available> <[Scientific name] (if available)> – in the mobile app.

@ezwelty What are your thoughts on this? I was thinking the type search should use the new locale-specific type string.

Types are currently sorted by descending English common name. For example:

• Apple [Malus]
• Apple berry [Billardiera scandens]
• Apple mint [Mentha suavolens]

They should instead be sorted by descending scientific name, then by ascending taxonomic rank (from broader to more specific).

Clicking the password visibility toggle loses the focus on the password field and makes the keyboard close.

Localization does not yet support type names, which appear in the location description, list view, and type filter. These should update when the locale is changed.

Currently, only location fields can be edited, but not the location's position.

Both should now be switched to using the same API call and data so that locations.json isn't called twice. Should include the type filter as a parameter (as currently done by map) and lat,lng (as currently done by list).

It is defined on the website: "If you doubt the existence, location, or identity of this source." However, no such information is provided on the mobile app.

Give user the choice to upload existing photo from their library, not just take a new camera photo.

If "Edit the map anonymously" is selected by a user via the website, changes made from the mobile app should respect that selection.

This will only work well once Map and List display the same locations. Then the map does not need to be panned when switching between Map and List views (which would reload both views), and instead simply highlight the marker by color and z-index or a mini-infowindow.

After a photo has been taken via the Add location or Add review forms, there is no confirmation that the photo is attached to the form. There should be confirmation text, or better yet, a thumbnail of the photo embedded into the form.

Hi Falling Fruit Team,

I am writing an app and hope to get all plant maps on board.
Features:

• Publishing to multiple APIs (Mundraub, na-ovoce)
• Mapping Categories
• Offline mode with downloaded markers and Fruit Radar notifications

https://github.com/niccokunzmann/mundraub-android

I would like to incorporate Falling Fruit markers. Also publishing if the API is documented (should take me a day or two then).

I could not find your API documentation. Do you have an API documentation?

• https://falling-fruit.github.io/api-docs/#tag/clusters%2Fpaths%2F~1clusters~1cluster%2Fget does not tell me about markers
• https://falling-fruit.github.io/api-docs/swagger-ui/ tells me "Can't read from server. It may not have the appropriate access-control-origin settings."

I can read your source code. A documentation like na-ovoce was really great.

How would you like to cooperate?

For example:

• Open app
• Search for "Bungendore, Australia" and hit enter
• The map appears blank
• Zoom in and locations now appear in Bungendore

(reported by Lady J)

Requested in a Google Play review. Alternatively, we could open the location in those apps (from which the user can then request directions), or simply display Latitude, Longitude and perhaps the reverse geocoded address for use in other apps.

The usual "Done" button to close the dropdown menu selector in iOS is not appearing (iPhone SE, iOS 12.4.1). Possible solutions are given at https://stackoverflow.com/questions/31839925/bug-no-done-button-for-select-tag-in-ios.

If you add a new location, then click the back button to return to the map, no marker appears where the location now exists. One solution is to force reload (locationsService.fetchData with cache: false) but performance would take a hit. A marker can be manually added to window.do_marker(), but no equivalent exists for the list. Since these views share the same data, I wonder if it wouldn't be better to somehow inject the location into a locations array and then update the views from that?

Only filtering by a single type is currently supported. Given the number of types, this might require the added ability to save and load custom filter settings, and perhaps support for Falling Fruit-provided presets (e.g. "basic forager mode").

For consistency with our other interfaces, the user registration page should include an opt-in checkbox for the (upcoming) newsletter.

Currently the photo is sent to Falling Fruit servers but never saved locally. I think the expected behavior is that the original photo (before resize / compression) be saved to the phone's local storage.

On Android: Adding saveToPhotoAlbum: true doesn't seem to do anything. Apparently only works if destinationType: Camera.DestinationType.FILE_URI but then this breaks upload (which expects the data as base64). Might require tinkering to pull from local storage and encode ourselves?

Some users complain about the little messages that keep dropping in from the top. Although it's important for users to distinguish between an absence of data and loading data, we should think of a way to make these less obtrusive.

Issue:
When clicking "Take Photo" after uploading point on iOS app, the camera does not pop up.
After clicking elsewhere on screen (Access dropdown) the camera then pops up.

Issue is documented in this video: https://drive.google.com/file/d/1ux1zh_7Z0txH44frkQQ7Kcyz0i5DkQO4/view

Model: iPhone 7
Version: iOS 12.4.1

The mobile app doesn't yet support adding types that don't yet exist in the database.