Need to research a good way to accomplish something in Expo that is equivalent to local.appsetings.json from the .NET side. Ideally, this would allow for client secrets that get baked into the app (such as Google API secrets) to not get leaked into source - which has already happened thanks to yours truly 🙄

Would also be useful for Ngrok url (though this could go in the existing app.config).

Upon approval of a new marker, the app should send out notifications with the name and description.

Must be opt-in only (this may require a "settings" page).
Ideally these would deep link to the marker in question.

Bonus Points:
Ability to notify the user who uploaded the marker (we would need to be careful about device identifiers and such).

There should be a search bar that allows users to look for markers by a particular marker. The map region should be redrawn to include all results.

User report emails should be batched such that they get sent at a more reasonable clip (once a day should suffice).

This is to help us avoid a paid tier of SendGrid (100/day is the current limit).

Implementation Note:
This should be possible by refactoring the current function to push to a new queue and creating a new function that would process the queue once a day. (Note that the timed trigger will not be able to use bindings, so it will have to use a standard storage queue client).

Alternatively, we could use the database for this. I like the idea of the queue storage for its retry and poison-queue functionality, but we don't get that by default here.

The User Report emails that are generated were implemented really hastily and are very bare.

At a minimum, they should include more information about the reported marker (name, description, and photo).

Bonus Points:

• A rejection link (using the existing OTP infrastructure and Approval Azure Function), that allows a marker to be taken down from within the email.
• A flag that the user can set for the "type" of report, i.e. "missing marker", "typo", "objectionable content" etc.

Would love to be able to add all the data that's in the facebook group, but the posts rarely include the contents of the sign.

When viewing a marker, if the user's location updates significantly, the map will change its focus back to the user rather than the marker.

When viewing a marker, nothing should change the view port of the map except the user.

Note: consider refactoring so that the map with viewed marker is not the same map instance as the main page. Alternatively, make the existing behavior match the intent of the code (see the shouldNavigateToUser flag in App.tsx.

Per this screenshot from the Google Play developer console, I think we need to figure out how to handle Android permissions better. Preferably before the App gets banned (May 5th) 😑

I think this is related to use of ImagePicker instead of MediaLibrary. I believe that refactoring away from ImagePicker will solve this problem.

On certain iOS screen sizes, the last workflow step is not entirely visible.

See differences here:
https://blog.expo.io/expo-sdk-42-579aee2348b6

Use https://github.com/vadimdemedes/tailwind-rn to standardize styling across the app.

Note that we need to investigate how to customize the colors.

We should publish all changes to the Azure Functions via a GitHub action that is triggered manually. Keep in mind that this will also require us to run our Migration SQL Script against the DB within this action - BEFORE THE FUNCTION IS DEPLOYED.

Similar to the "approval" emails, we should schedule an email periodically (once a week maybe?), that includes any item that has not yet been approved. This should include enough information to create a "Permanently Delete" button next to each item, which uses the current auth scheme to allow an item to be permanently deleted.

Basically, transition iOS over to just a single number format.

It appears, based on this expo issue that Image Picker broke slightly for iOS 14.5. There isn't much we can do but watch this issue and see what happens.

Need to investigate what it would take to get off of Azure Functions for Background Jobs.

Currently, it seems like it might be possible to add a hosted service to a web server and have Azure Container Apps spin the server up whenever a message is detected in the Queue.

This needs some investigation before we can actually go down this path.

Never going to be an issue, as this occurs once you've zoomed out as far as the map provider allows, but might be cool to see why this fails. It's probably a hole in the logic that draws the bounding box (need to wrap lat/long or something).

Currently, the mechanisms for uploading and viewing photos is production only. We need to see what changes, if any, are necessary for this to run locally.

There's currently no indication of how many items are returned by any given map search. This might make the fact that the list is scrollable more apparent.

In order to capture the fun of hunting for and finding markers for future users, we should support a version of the map that contains pins that I have visited. Pins that haven't been visited should probably still be present, but should be greyed out.

At a minimum we need a "new" map and a way to set markers on that map as having been visited.

Technical Notes:

At its base this means maintaining a local list. It doesn't need to be a full on database because this will just be some of the information from the markers. (I'm thinking it shouldn't include the picture or description, just the name and location and whether the users has visited it.)

We will need to update the local list from time to time - this means considering frequency of updating this list.

Potential ideas for expanding this:

A notice (upon opening the app) that shows which pins have been added since they last checked.
Completion percentage - this really should be easy and is a really nice "polish" feature.
Local push notification to check in based on geofencing

We initially implemented image upload via a heavily compressed base64 encoded string. This was to get around limitations in .NET 5 Azure Functions Isolated Process Model, which doesn't currently give sufficient bindings for FormData.

It looks like we should be able to use something like this Http Form Data Parser to implement uploads without compromising on quality.

In anticipation of hitting our SendGrid 100/day email limit, I think we should refactor reporting emails so they are sent via a queue system, similar to our current implementation of approvals.

In certain cases the Marker Form can become hidden. Need to investigate why this is happening.

We need some way of informing the user that distances are "as the crow flies" and not necessarily driving distances. This could be a modal or alert that is brought up by hitting some kind of "info" icon.

CI

We should run Jest tests (there is currently one, there should probably be more) on every PR/Merge.

CD

I would like to add some GitHub actions for that would run expo build for both iOS and Android.
These actions might need to be triggered manually.

Ideally, this would also download the resulting package and either add it to a release or directly upload to the respective app store.

Currently, any refresh results in the map being cleared and a loading state in the list. Ideally, there would be some indicator that the map is refreshing, but all markers would stay in place until the refresh is complete.

useSWR does a great job of handling caching, but in the case of searching a new area, the cache is invalid. We may need to find a way to implement our own caching strategy around the values returned from useMarkers.

End Goal: The map should not "flash" as users change their physical location or search around on the map. We should ensure smooth transitions as data updates, as well as clear indications that data is loading.

Adding option to map to list view by parish or by city

Eventually, we will want to have some way for arbitrary marker "types" to be entered, for instance Lafourche Historical Society.

As an intermediate step, we should begin classifying signs as either an "La Historical Marker" or "Other." This will require us to to add a field to the database (should probably be an enum) and we will need to update several signs so that their type is appropriately reflected.

Within the UI, we should distinguish these by the pin color (or potentially design new "pins").

Related to #23, expo has changed the way it handles Android permissions so that they comply with recent changes to the Android permissions API.

For upgrade path, see this Medium article.

Unless they are hidden behind environments, OTA updates cause more headaches than they are worth. If we do hide them behind environments, then I'll spend a lot more time creating new builds (would need to build for each environment), which doesn't really save me time as I'm at the mercy of Expo's build pipeline.

I believe the best course of action is just to go through the AppStore process. That will give me better control of what is generally available and reduce the number of times I have to wait for expo build to complete.

User's should be able to opt into Background notifications whenever passing a marker. These notifications would let them know the name and a preview of the description.

Ideally, clicking the notification would deep link to the marker.

This would need to be a paid feature (due to cost).

Currently, I have no idea what happens if you hit the Go button without having at least one of the following app installed:
Google Maps
Apple Maps
Waze

Since we aren't explicitly using the alwaysIncludeGoogle option, something probably breaks (or nothing happens, which is also bad™️).

TLDR; we should pass the alwaysIncludeGoogle option with value true to showLocation

Related to #43
We need to introduce tabbed navigation so that we can easily navigate between the "Explore" and "My Markers" screens.

There should be a "Take Me There" option when viewing a marker. This was an obvious one we missed!

In the context of "unconfirmed" markers, we should probably warn users before we allow them to start navigation and leave the app.

Because we can't account for every screen size/text size combination we should make sure the modal content can scroll so that the action buttons are always visible.

Create a Dockerfile/docker-compose file such that SQL Server and Azurite can be spun up using docker compose.
Ideally this would eventually also include the azure function itself (with hot restart).

We should be able to use a cloud service like the Google Vision API or the Azure Computer Vision API to get text from the images of the photos.

The workflow would be something like:
Take Photo -> User Hits "Next" -> Upload Photo to Blob Storage -> Send off for OCR with Blob Url-> Prefill Title/Description with OCR results
This would require a slight refactor so that images get uploaded and processed before the user edits the Title/Description and submits.
Alternatively, we could skip the upload photo step and just send the photo directly to the OCR API? (Not sure what we gain/lose by this.)

Things To Evaluate:

• Cost of Azure/Google (probably not a real concern as we'll fall within the free realm of either?)
• Sending the photo off directly vs sending a URL to be processed
• Splitting the response between the Title and Description reasonably
• Will we need an intermediate Function to communicate with these cloud API's

We should investigate what it would take to allow manual entry of a marker's location. This is primarily a safety concern as some markers are hard to get near.

This would need to be combined with a more robust reporting system and/or the ability to add suggested revisions.

Now that I have access to the Facebook Group, I think I can more easily verify this information. The reporting/revisions would be nice but this takes priority. May also be nice to allow entering of lat and long.

When switching between markers from the Details view (using the minimized map), the underlying Selected Marker does not appear to change for the Saved Marker Modal.

For Android 11/SDK 30, you must declare in advance which apps you plan to query. I'm currently unsure of how to do that in Expo, since we don't have access to the AndroidManifest.xml directly. This will require some investigation.

Once #41 has been completed, we should force the user to select a marker type. This could maybe be a dropdown or a check mark? I want to avoid a toggle because eventually there will be multiple options and we want to actively force them to select one.

We should avoid defaulting this value so that we force users to actively select one. This should hopefully force people to ask themselves if it is one of the "official" markers or not.

Android is in desperate need of a UI pass.

In general, there needs to be padding between buttons (should probably refactor any existing padding into some kind of re-usable component or some such).

Other items that should be checked include (but are not limited to): behavior of any KeyboardAvoidingViews, behavior of DismissKeyboard, button colors, etc

The name and description should not clear when the app gets backgrounded. Instead it should persist unless the app is exited.

After making changes to the location so that it doesn't constantly refocus, the user's location isn't updated for the query to the server. This means that the distances do not change as the user moves around. Essentially we need two different location queries to drive two different behaviors.

1. Single location query on app load. This should focus the map on the user.
2. Continuous location query. This should be used in queries for nearby markers to ensure semi-accurate distances.

Because the icon should probably not be an image I cropped from Google.

Azure Functions have too many limitations. It's time to get back to full ASP.NET Core so we can move quickly on new features (and take care of long needed improvements).

The goal is to migrate all HTTP Triggered Azure Functions to Container Apps.

Approval emails should include a deep link that opens the app using a special view for editing and approving the marker. The link would need to include enough data so that the app can pull the data from the server (and authenticate?).

The only way to get to this screen must be via deep link, so that end user's can't stumble upon this feature.
Note: the above is NOT a security feature, any end point that mutates data would still need some form of authentication.

Still need to decide if we want to authenticate when pulling the data. This is a public database/API, so maybe pulling the data shouldn't require auth? But this endpoint would allow pulling data that isn't publicly available (i.e. IsApproved = false), so maybe it should?

Since markers are automatically saved and added to the "Visited" and "Authored" categories, we should probably periodically update them in case something changes during the review process.

Additionally, we should consider what to do when markers are approved/rejected. (At most, maybe some indication of what is an approved/unapproved marker?)

There are weird issues with how the Admin page navigation works.

If you are not on Explore page, the admin deep link doesn't work.

Once you get to the Admin page, the back button is no longer there.