schakravorti21 / sakaiclientandroid Goto Github PK

As more features get added to the application, more Java/XML files have to be managed in the project. We should find a way to organize classes and XML files based on their respective categories and sub-categories. This might look like --> Category: Assignments; Sub-Category: Activities, Fragments, Dialogs, View Holders/Adapters, and Utilities.

The Android memory profiler shows that DataHandler's memory consumption is around 130-150MB with the Course objects being stored in it statically. This is way too large of a memory footprint -- switch to just making requests every time data is needed, or only storing serialized versions of the data, or cherry-picking the data that is worth keeping globally.

When the app shifts from portrait to landscape mode, the active tab is not saved and the Home Fragment is loaded again (regardless of what tab was previously active). This causes confusion since the selected tab stays the same (say, for example, Assignments). This bug might also occur if the app is brought back from the background after a long time.

By default, WebView doesn't support uploading files from the local filesystem. This needs to be implemented by us through calls to startActivityForResult and using ValueCallbacks to handle Intents.

This will waste a lot of resources recreating the fragment every time. If possible, more the observation into the fragment class itself so it can just recreate the treeview/recycler view and fill it with the new data.

With the app coming along, DataHandler is starting to get quite massive. RequestManager hasn't quite suffered from this issue since it doesn't manage any of the data, but DataHandler is getting bloated by the combination of making requests and managing data state. Since DataHandler performs requests for many different categories of information, we can possibly split it up into smaller pieces, such as AlertsDataHandler, AssignmentsDataHandler, and GradesDataHandler.

Fontawesome can be used as a typeface with Android. We can migrate to using Fontawesome instead of native drawables to make asset management much simpler, and ensure that various screen sizes are easily supported with Fontawesome's scalable SVGs.

There are a couple issues that arise when a new user logs in, though these should be relatively quick to fix:

1. The old user's courses remain in the database, so logging in a new user shows both old and new courses, as well as all related data (assignments, grades, announcements, etc).
   • To fix this, ensure all ForeignKeys are set up properly and delete any courses not found when refreshing courses, which should trigger cascading deletes for all related course data.
2. If a new user logs in and immediately switches to a tab different from the courses tab, then the API call to fetch courses never completes, resulting in none of the tabs showing anything until the user goes back to the courses tab and refreshes
   • Consider preventing navigation while courses are updating so that this issue does not occur in the first place

The first issue could also arise if the user drops a class during add/drop period, and they are removed from a Sakai site, so our solutions should be user-agnostic (i.e. don't do something like using SharedPreferences to see if the user has changed since last login).

We need an Announcements Tab that shows the user's announcements that come from Sakai. Announcements should be sorted in reverse chronological order since the most recent announcements are most important. Users should be able to click on an announcement to see more details about the announcement, such as the full body and attachments.

(This is already in progress, just creating an issue to document progress).

Fabric will probably stop working from March 31st, 2020. It seems like they've moved out the functionality to firebase.

All Support Library development has been migrated to AndroidX, and API 29 onwards it seems that only the AndroidX versions of the Support Library will receive updates. We should migrate to AndroidX sometime soon to support new Android versions that will arrive in the future.

Here is some info on how to start the migration (should be relatively painless... hopefully).

We need an Assignments tab where the user can check all of their assignments. This tab needs to have the following functionality:

• All assignments should be shown as small cards that can be expanded to larger cards
• The mini-cards should include stuff like assignment title, description (in a scrollview), and due date
• Expanding to a large card should show all assignment details, including:
  • Title, course, and due date
  • Assignment status, max grade, allows resubmissions
  • Any attachments the assignment may have
  • Full assignment description
  • A floating action button leading to a bottom sheet dialog that allows the user to submit the assignment
• User must be able to submit the assignment through the bottom sheet dialog by either
  • entering content into the default text box
  • or uploading attachments (a separate issue has been made for this, #12 ).
• Users must be able to sort assignments by date or by courses
  • As a design decision, we have chosen to keep everything sorted within their terms

(This is already in progress on the Assignments branch, just making this issue for documentation of progress)

Upon the first time the app loads, if the user moves away from the home page before the HomeFragment is added to the FrameLayout, the spinner keeps spinning. This is probably because the spinner is tied to the activity and not the fragment. Two things need to be done to fix this issue:

• Move the initial call to DataHandler.requestAllSites to HomeFragment
• Make the spinner belong to the HomeFragment instead of the NavActivity

Application network requests time out and fail on Rutgers WiFi, giving a java.io.SocketTimeoutException. @akench and I narrowed down the issue to malformed request headers being injected by HeaderInterceptor. Previously, when testing with Postman, it turned out that these headers were not necessary anyways, so they should be removed to avoid this timeout issue.

Currently, the all sites and gradebook pages are using nested expandable list views. Since this is cumbersome and might become difficult to maintain in the long run, it would be a good idea to switch to using the AndroidTreeView library. This will require some work, but it would be better to do this sooner rather than later. Consider creating a TreeViewUtil class to help generate the tree structures when given model objects (assignments, gradebook, etc).