steelhacks-2023 / lost-at-pitt Goto Github PK

"A slight nitpick we can handle later is the fact that pushing and popping gives an unsmooth feeling where if we click on nav bar we expect a smooth transition, but that may be transitions and not push and pop. Maybe make this an enhancement later on?"

^ With regards to opening sub-pages via route.dart

We can maybe define transition(s) to use throughout the whole app in route.dart. This will have to be looked into and is not high priority right now.

Items should have

1. datetime - Time submitted
2. boolean - whether the item was successfully returned or not yet
3. string - User UID that submitted the post

Update the PostPage UI to include 1) and 3) probably not 2) because we'll just not display the post if it's been returned
Update Firebase for both dev and prod

Do we need User document storage as well to store user data? like PFP and other settings? especially once we work on user messaging and we have to store chat logs for a period of time. @jeffzheng13

• Pitt color theme
• Dark mode / Light mode

Just ideas ^

https://pub.dev/packages/logger

Should move away from print statements and move to using an actual logger. For now we can just do console logging, I don't think there's any reason to have to do file logging right now.

As a part of this issue we should also work on cleaning up the output currently being logged. There are some warnings being thrown during runtime that we should either address, or disable if we deem them as unimportant.

When multiple markers take up one place, it gets too clustered. Use google_maps_cluster_manager or some other library to handle this. Additionally, need to handle when markers are at the same location. Although, we do have the list capability.

When submitting an image on the submission page, depending on its aspect ratio it sometimes will overrun the bottom of the page. Need to constrain the image preview to a certain size or make the page scrollable (should be a very easy fix)

We are currently developing and focusing on the web version extensively. However, my worry is that when we shift our attention to launching this as a native app of mobile devices, there will be a bunch of changes needed. For those interested in exploring mobile app development, feel free to begin setting permissions and diving into Android or iOS settings.

Something I noticed that we should fix in the future. Right now we need to have two StreamBuilders so that we can separate the lost items from the found items by querying them separately - but in the future I think we should move to have all the items in the same table of the database but just with an extra attribute that is either "lost" or "found", then we can query all the data with one StreamBuilder then put it in separate lists based on that attribute.

Alternatively, and will probably be way easier, we can use a MultiStreamBuilder to listen to two streams at once.
https://stackoverflow.com/questions/51880330/flutter-stream-two-streams-into-a-single-screen

Item information popup
Pin List page
Individual pin view

Clicking on the map does not produce desired behavior on mobile web.

When clicking on the map to add a listing, if the user attempts to press the 'X' icon and wants to go back to the map page, the submission page disappears and pops back up. Same thing happens when we attempt to close a post page after clicking on map marker, we see the submission page pop up upon exiting the post page.

Make the login and signup pages fit with the look & feel of the rest of the app.

Thinking probably we can have a search bar at the top of the list page? And some way to filter based on category and location? like within X miles of me... we already have user's location so it shouldn't be too hard

Title ^ Just need to organize the codebase

For now it just has a logout button, however, ideally we can show user profile. The next stage after showing a user's profile is to be able to edit their display name and other fields to their account.

Currently clicking on map icon results in out of bounds on mobile devices. Works properly on Windows and MacOS web versions. We can move away from an AlertBox which is the current implementation?

Right now we have 1 database would ideally have one for testing that we can mess up and one for the deployed web app to connect to.

Potentially we could add another configuration in firebase_options.dart to connect to a test DB? @jeffzheng13
A sample repo we could look at as well, looks like they have two main.dart files that can be launched from https://github.com/lohanidamodar/flutter_firebase_starter

• Chat page that shows log of messages with another user
• Page with your conversations that you can click into

Should try to look for an existing UI we can poach or something probably and then fit it to our theme

Rename to submissionPage.dart, class SubmissionPage
Update the body Widget passed into buildSubPage

Build PostPage in a similar way. Because it's still bad lol

What I can think of right now:

1. Need to update database schema with:
   • User table for their home Geoposition (#2 )
   • Their submitted posts
   • Their messages to other users (which we will work on in the future)
2. Need to implement the messaging system between users
3. Filtering / Searching functionality through the current posts in ListView
4. Move database operations to their own file (instead of having "FirebaseFirestore.instance.collection" and add / remove functions everywhere)
5. ... add more

Database calls are made in the following files:

map_page.dart
auth.dart

And soon we will need to make calls for the messaging functionality of the app when we build that. I think it would be beneficial to move all our database access to a separate file.

Another somewhat related issue: the map page is wrapped in a StreamBuilder2 widget listening to the Lost and Found streams. Then when the user switches to the list page, the current data is passed into that page from the map page. This seems like a bad way to do it since one page is in charge of doing the updates. Why don't we wrap the current page in main.dart MaterialApp widget in the StreamBuilder widget instead? Then we can pass the data to whatever page wants it.

To illustrate my point -

child: MaterialApp(
            debugShowCheckedModeBanner: false,
            routes: {
              'loginPage': (context) => const LoginPage(),
              'mapPage': (context) => const MapPage(), // this page has a parent StreamBuilder in the build method
              '/': (context) => const Wrapper()
            },
            initialRoute: '/',
            theme: AppTheme.getTheme(),
            themeMode: themeManager.themeMode));

Instead I suggest we do this -

child: MaterialApp(
            debugShowCheckedModeBanner: false,
            routes: {
              'loginPage': (context) => StreamBuilderWrapper('loginPage'),
              'mapPage': (context) => StreamBuilderWrapper('mapPage'),
              '/': (context) => const Wrapper()
            },
            initialRoute: '/',
            theme: AppTheme.getTheme(),
            themeMode: themeManager.themeMode));

Where StreamBuilderWrapper is defined in the database operations file and we simply pass the current data into the correct page based on the parameter, 'loginPage' or 'mapPage' (and in the future chat pages)

Backlog item. Make the MapPage auto refresh again like it used to before we restructured. Low priority right now

There's some bugs with the sign in state of the app - sometimes when a user logs in, their user data is not pulled from Firebase correctly which is demonstrated by the name on PFP page being "null null". Need to pin down exactly why this happens and fix it

Map should load up at the location of the user. This would need permission from the user in order to access their location

Color and UI theming needs to be moved to a global ThemeData class. Some things that should be globally defined:

1. Color styles (primary, secondary, tertiary colors, background color...)
2. Button styles
3. Card styles
4. Global font
5. Title / Subtitle font weights & colors
6. Border styles

This will allow us to do two things:

1. Allow user customization of the color scheme of the app
2. Easily adjust the theme of the whole app if we want to change the look and feel

Need to do this before #18

The flutter package google_maps_flutter now endorses google_maps_flutter_web. This means that there is no longer need to include google_maps_flutter_web as a package as importing google_maps_flutter will do so. We can now build iOS/Android/Web all at the same time.

TODO items:

• Switch over to google_maps_flutter
• Ensure app does not break when we do so

With the new release and UI changes scheduled in PR #50. There are some more small improvements that may be desirable:

• Map takes a while to load, and the default layer is shown before our custom layering is applied. We should fix this if possible.
• Map should have POIs (points of interests), especially Pitt buildings to make it easier for users to locate common buildings.
• Map should have better clustering of markers as denoted in issue #8.

TO RECREATE:

PRECONDITIONS: Navigate to the PostPage via the NavBar at the top, by clicking the list icon.

EXECUTION STEPS: Clicking on a PostCard on the PostPage brings up either the red and green alert dialog, or a form to submit for lost/found item.

EXPECTED BEHAVIOR: Clicking brings up the picture or more details of the lost/found item.

Might be too big of an enhancement to label as an issue, but moving forward we definitely want to implement a user system so that we can (potentially) have in-app messaging when users are working to get lost items returned. Maybe this is much more complex to be worth it, though.

We can re-use the sign in page from Remedi and tweak the styling to fit with our app style.

@jeffzheng13 Add any thoughts you have to this as well

To work on after #28

Instead of having a utils class we should have JSON file data then import that data in the dart files that need it.

A not necessarily comprehensive list (@jeffzheng13 add to this if you see anything else)

1. Map styling (currently in utils.dart)
2. Options for drop-down menus (item tags, item "types")
3. App settings (default location ... other settings I'm sure there are configurable options we will want to add in the future but I'm blanking right now)

We could go crazy and use JSON for the string data displayed in the app pages as well but that's way too much work than its worth I think

Two Parter
In order to limit free reads and writes to the firebase, there are a few ways we can go about it.

• Add user authentification
• Limit to our own app signature?? (don't really know if that's a thing)
• Rate limit users per write
• Write Firebase rules

Uploading images works, but pulling the image data from Firebase backend to display on an individual post page has not been implemented.

IDENTIFIER: DEFECT-NAVIGATE-LOST-FOUND-CARD

SUMMARY: There is no way to navigate back to the map after clicking on the marker

DESCRIPTION: There is no way to navigate back to the map after clicking on the marker which pulls up a card displaying the item that was lost or found information.

REPRODUCTION STEPS:

• Preconditions:

• Login to app using username: [email protected], password: Test123

• Execution Steps:

• Click on a marker that is on the map.
• Card should be displayed on the screen.
• Click outside the card location.

EXPECTED BEHAVIOR: Card should disappear and map should be clickable again.

OBSERVED BEHAVIOR: No way to exit. Clicking [esc] on the keyboard works, but is impractical for mobile devices.