Refactor: Remove local storage, query from webpage on load

Issue #53 new
Alec Douglas repo owner created an issue

Refactor idea to move away from local storage: * Query for an initial set of videos when the app is first launched * If the user scrolls to the end of the row (or near the end), query from the website more videos from that category and load them in * Search feature would query the website as well instead of the local database * All progress would be saved on Giant Bomb's side, no progress would be saved locally (possible exception: short term progress saving for each session for if the user starts watching a video, backs out, and immediately starts playing the video again)

This would eliminate some complexity from the app as well as the (legit) complaint users have about old videos not being available when the app is first installed.

Comments (3)

  1. Former user Account Deleted

    I’ve started some work on this in a forked branch here: https://bitbucket.org/neilgoodman/gbenthusiast/src/issue-46-and-53/

    Here is my high level plan:

    • Upgrade dependencies, primarily migrate from Android Support to AndroidX (done)
    • Implement a number of ViewModels using the new LiveData framework from AndroidX to fetch data directly from the Giant Bomb API
    • Refactor the UI to rely on the ViewModels instead of the ContentProvider and IntentService
    • Remove the SQL database
    • In the process of doing this I also want to integrate the saved time APIs to support tracking video progress with the Giant Bomb website, more details on that here: https://bitbucket.org/alecgdouglas/gbenthusiast/issues/46
    • I’m also planning to use the new-ish video_shows API to populate the left hand side of categories. In the future, I would like the categories to align the new homepage on Giant Bomb: Latest, Continue Watching, Quick Looks, Latest Premium, Shows

      • This would require a new list type for Shows that would then navigate to a grid or list of videos
      • Out of scope for this change
  2. Alec Douglas reporter

    Hey Neil,

    It looks like your work on this issue has been paused for a while. Any chance you could provide a status update on how far you got, what’s left to do, and any recommendations or thoughts you had in case someone else wants to pick up from where you left off?

    Thanks!

  3. Former user Account Deleted

    I did pause work on this, largely due to work load at my job. Also, my experience with the website on mobile devices is pretty good these days, Unfortunately, I don’t think I will continue this work.

    If others want support for pull request reviews or general questions, feel free to ping me here. I will do my best to respond within a few days.

    Progress update

    All of my commits have been saved to a fork, here is the list: https://bitbucket.org/neilgoodman/gbenthusiast/commits/. I have checked my local copies and confirmed that all changes I made have been pushed and synced.

    Here are some notes with commit ranges on the progress I was able to make:

    • b5427d2 to 7cfd0c0 Upgrade dependencies to bring in new AndroidX frameworks
    • 157d3a2 to 02194bc Implemented a new AsyncTask to call the Giant Bomb API, taking care of some async handling issues from the previous implementation
    • 06d2d95 to a706f48 Implemented new data layer using ViewModel pattern from AndroidX and refactored the Browse screen to use the new data layer
    • df17d80 to df17d80 Refactored the Detail screen to use the new ViewModel pattern
    • 0e42cd1 Upgraded ExoPlayer and refactored the Playback screen
    • a8e857d to ebcd8ba Attempt to mitigate some lazy loading awkwardness in the UX of the app

    I last built and tested the fork on emulators around June 23rd 2019, and at that time the builds were stable and the app generally worked. Video progress does save back to the Giant Bomb API and you can see the progress reflected if you go the website afterward. Video progress is also pulled from the API.

    I moved away from the local DB and the optimistic write approach and depended on the API directly for all data operations. I’ve implemented a rate limiter that should adhere to the API’s rate limits for any heavy bursts of requests, I still have concerns, but I think it’s fine for now. More details here: https://www.giantbomb.com/forums/api-developers-3017/api-rate-limiting-1786442/?page=1#js-message-9012544

    Next steps

    • Add support for some missing features:

      • Show lists
      • Live playback capability
    • Add unit tests for new code, I implemented a few, but ideally all classes would have coverage

    • Lots of testing needed across multiple devices, my changes are a re-write of some parts of the app and I only did basic testing in emulators to validate the approach I was taking worked

    Details on my current setup
    For anyone curious, I have found the website works well using the Silk browser on FireOS for these FireTV devices:

    • FireTV Gen 2
    • FiteTV Cube Gen 2

    FireTV Cube Gen 1 does not handle the website well, there is significant latency when rendering or scrolling, and dropped frames when playing video. The CPU resource upgrade going from FireTV Cube Gen 1 to FireTV Cube Gen 2 are significant and do address the latency and skipped frame issues. I have not tested other FireTV devices.

  4. Log in to comment