I have tested this on my own TV and it seems to work OK, but it definitely needs more eyes
Featurewise, this adds syncing progress to/from the API. If you have existing progress on the app when you run this for the first time, it’ll overwrite that with whatever progress you have on the site.
Saving happens every 10 seconds while watching the video, with the DB save. This is under the 1 request/second limit established by the API documentation so I think it’s safe to do. It reads from the API whenever videos are refreshed, and blows up whatever times are saved locally. I did not rewrite the video database because I’m lazy I also did not change the short/long video update times which may cause progress to not sync to the app as often as it could, but I wasn’t sure if those times (45/240 minutes) were chosen for a specific reason.
The big code changes in here are:
A bunch of changes in the .idea folder. I don’t…actually know how many of those are worth keeping? So if anything looks off to you, it probably is
Kotlin support, because it’s what I am more comfortable with
androidx, which is what most of the diff is honestly. Just fixing imports and whatnot.
Retrofit. IDK what the general consensus is on this library, but I really like it for the kind of simple API stuff I was doing here
I bumped up a bunch of dependencies in the gradle file and added dependencies for the various things I needed. Minimum SDK has not been changed
A few inspection changes where they were being suggested by android studio, mostly turning stuff into lambdas, ex OnFetchCompleteHandler in MainFragment.java or removing casts to specific classes like Button because they weren’t needed anymore.
Apologies for not writing the save/load in the same manner as the other API interactions - I figured if I put it into a folder of shame and called it from the existing java code it was probably fine.
I know this is probably not how you’re supposed to do open source stuff (just go in and change like 70 files) and truthfully, I did not make a ton of effort to use the exact same mechanisms as the rest of the app (I know Coroutines, but I don’t really know AsyncTask). That’s laziness on my part. I used this to watch a longer video so I’m reasonably confident it works, but I’d be happier if I got one or two more people to try it.
Thank you for taking a look! It’s entirely possible I missed something / broke some important pattern you were trying to enforce. I’m happy to make whatever changes you want. Honestly I just made these changes so the app would work the way I wanted
I have tested this on my own TV and it seems to work OK, but it definitely needs more eyes
Featurewise, this adds syncing progress to/from the API. If you have existing progress on the app when you run this for the first time, it’ll overwrite that with whatever progress you have on the site.
Saving happens every 10 seconds while watching the video, with the DB save. This is under the 1 request/second limit established by the API documentation so I think it’s safe to do. It reads from the API whenever videos are refreshed, and blows up whatever times are saved locally. I did not rewrite the video database because I’m lazy I also did not change the short/long video update times which may cause progress to not sync to the app as often as it could, but I wasn’t sure if those times (45/240 minutes) were chosen for a specific reason.
The big code changes in here are:
A bunch of changes in the .idea folder. I don’t…actually know how many of those are worth keeping? So if anything looks off to you, it probably is
Kotlin support, because it’s what I am more comfortable with
androidx, which is what most of the diff is honestly. Just fixing imports and whatnot.
Retrofit. IDK what the general consensus is on this library, but I really like it for the kind of simple API stuff I was doing here
I bumped up a bunch of dependencies in the gradle file and added dependencies for the various things I needed. Minimum SDK has not been changed
A few inspection changes where they were being suggested by android studio, mostly turning stuff into lambdas, ex OnFetchCompleteHandler in MainFragment.java or removing casts to specific classes like
Buttonbecause they weren’t needed anymore.Apologies for not writing the save/load in the same manner as the other API interactions - I figured if I put it into a folder of shame and called it from the existing java code it was probably fine.
I know this is probably not how you’re supposed to do open source stuff (just go in and change like 70 files) and truthfully, I did not make a ton of effort to use the exact same mechanisms as the rest of the app (I know Coroutines, but I don’t really know AsyncTask). That’s laziness on my part. I used this to watch a longer video so I’m reasonably confident it works, but I’d be happier if I got one or two more people to try it.
Thank you for taking a look! It’s entirely possible I missed something / broke some important pattern you were trying to enforce. I’m happy to make whatever changes you want. Honestly I just made these changes so the app would work the way I wanted
I posted about this change here https://www.giantbomb.com/forums/general-discussion-30/amazon-fire-tv-android-tv-the-giant-bomb-enthusias-1805547/?page=6