@row: Drat. I figured that was the case, but I couldn't help but hoping. If you're willing to do a bit more testing, I've uploaded a new APK that adds a drop-down next to the quality drop-down. Each option causes the app to use a different combination of ways to put the app into a full-screen mode and, with a bit of luck, at least one of them will work.
soup_menu's forum posts
@atomicedge: If the player gets removed from memory while it's in the background it should be able to recreate itself when you go back to the app, but it's entirely possible there's something going on that I haven't accounted for. Reporting the crash if/when it happens again would be awesome.
Thanks for the DLC purchase! Much obliged.
@row: At the risk of asking a stupid question: that clean install was done by sideloading the APK I linked in my last post, not by installing from the Google Play Store, right?
If so, was there any change in behavior? Maybe it's now drawing the video on the whole screen even if it's not properly hiding the system bar?
If there's been no change at all, maybe the device is a bit more non-standard than I thought (that you can hide the system bar at all indicates that the manufacturer has tinkered with the OS at least a little). Does the main interface show the video details on a separate screen from the list of videos or are they shown together with the list on the left and the details on the right?
@row: Perfect! It looks like your device is using the old 10" tablet (and larger) UI that was introduced in Android 3.0 and phased out in 4.2. I had a hunch that might be the case, so I banged together a new build for you to try. You can grab the APK here.
If that works (and, at the risk of jinxing it, I think it probably will) I'll upload it to the Play Store. Please let me know once you've had a chance to give it a try.
@atomicedge: Google doesn't consider ART ready to ship as the default runtime yet, so I wouldn't be shocked if it were somehow to blame. That said, I just switched my Nexus 7 over and couldn't reproduce the issue, so other elements could be involved.
Have you allowed Android to report the crash? I'm not seeing anything in the developer console.
@row: Could you please provide some additional information? The name of the device you're using and the version of Android it's running are the two most important details.
The reason I always ask for this is that there are currently 4,968 different phone/tablet models registered with Google Play that are capable of running the latest versions of GBVB. Most devices receive at least one OS update in their lifetime, so the number of device/OS combinations should easily be twice that. Unless an issue affects everyone it can be hard to track it down without a better idea of where to look.
@hellxpress: No, I don't believe there is. If you had some additional info to filter by (like release year) you might be able to pare down the results, but I think that's the best you could do.
Since you're firing a request per game it occurred to me that there's something else you might need to be aware of: the API rate limit. It's not mentioned in the documentation, but there's now a limit to how quickly you can query the API. The most recent figure I can find is 400 requests per API key per 15 minute interval (see: GB thread & CV thread). If this is for a personal project then you probably don't need to worry, but if it's something you're going to make widely available you'll most likely want to add some sort of handling.
@zombieclem: I can keep that in mind, but, at least for now, I think the menu is going to stay as-is.
@briankbl: I'm happy to hear you're up and running. Thanks for following up!
@phantomsnake: Awesome! Thanks for letting me know.
@phantomsnake: A+ bug report! That's exactly what I needed. It turns out that the code for detecting the navigation bar and re-positioning the player controls accordingly wasn't firing correctly on pre-Kit Kat (4.4) devices. The back button taking two taps is the default behavior (the first tap dismisses the player controls), but I think you're right that it makes more sense to close the player right away. I've uploaded a new build with both of these changes and it should be hitting the Play Store within a few hours. By the by, is there a particular reason you're sticking with 4.3? Kit Kat has been available for the Nexus 4 and 7 for quite a while now, so I'm a bit curious.
@briankbl: When a Chromecast receiver is detected on the network the usual cast icon will automatically be added to the Action Bar. Detection can sometimes take a few seconds, but if waiting doesn't seem to help you might try rebooting your phone and/or Chromecast dongle. If GBVB still isn't seeing the receiver while other apps on the device are, please let me know and I'll see what I can see.
@bobby & @zombieclem: I can appreciate that requiring two taps to mark a video as watched is a bit slower, but now that the control toggles between marking as watched and unwatched I have some concerns that an icon may not convey what will happen when pressed as well as text does. That said, I frequently make poor decisions and if the consensus ends up being that this is one of them it's certainly something I'm open to revisiting.
Q1 & Q2) If I've understood you correctly it should be possible to do this in one step:
That will retrieve all games with "frogger" in the name that were released on the 2600, which is apparently "Frogger" and "Frogger II: Threeedeep!"
Q3) To the best of my knowledge the "image" field is an all-or-nothing affair. There are also two things to note about images:
- Sometimes you will get absolute URLs and sometimes you will get relative URLs. A fix should be on the way, but it's something to be aware of.
- Some images may be missing. It's pretty rare, but it happens.
Q4) If you're only looking for a single resource type I've found that it's generally easier to just filter on the name field rather than use the search endpoint.