Develop Reference

Netflix style next episode for Exoplayer Leanback

I am working on an Android TV Application using leanback library. I was able to integrate VideoPlaybackActivty using Exoplayer. One of my requirement is when there is about 1 minute left for current video to end, I need to make a Rest call to the server to fetch next video to play and than I would like to show the Next Video thumbnail at the bottom right of the screen. Very much similar to the Netflix functionality of "Next Episode playing in....".
My questions is, how can I find out if there is just 1 minute left in the video. Also, how can I show that "Play Next overlay" on the screen? Currently my activity_videoplayback.xml look as follows.
<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">
<TextureView
android:id="#+id/texture_view"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_gravity="center" />
<fragment
android:id="#+id/playback_controls_fragment"
android:name="com.myapp.ui.playback.VideoPlaybackFragment"
android:tag="#string/playback_tag"
android:layout_width="match_parent"
android:layout_height="match_parent" />
<ProgressBar
android:id="#+id/stream_progressbar"
style="?android:attr/progressBarStyleLarge"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center"
android:indeterminateTint="#color/orange"
android:visibility="gone" />
</merge>
Really appreciate the help.

ExoPlayer does not provide a progress update listener at the moment - the reason cited is that it would eat up too much CPU to keep raising progress events. See the discussion on the ExoPlayer issue tracker here and note that the issue is considered closed at this time (Feb 2021):
https://github.com/google/ExoPlayer/issues/3980
The suggested approach is to build a handler to poll the player and query the current position using player.getCurrentPosition().
For completeness, in case you are also looking at HTML5 video, in a WebView for example, you can check the video length and then use the progress event to check for 1 second from the end - this is 'standard' HTML5 and javascript so should work with any framework using the HTML5 video element.
The code might look something like this:
const yourVideo = document.querySelector('yourVideoID');
//Create the event handler
function handleProgressEvent(event) {
//Check if video has reached last 10 seconds
if (yourVideo.currentTime > (yourVideo.duration - 10.0)) {
// DO your work to prepare the next video here
}
}
// Add the event listener to your video
yourVideo.addEventListener('progress', handleProgressEvent);

(Android) ScrollView stutters on fling with long multiline EditTtext inside

I have the following problem, and I cannot figure out how to eve try solving it (or whether there is a way):
My problem
I have SrollView, containing to EditText input fields. One is a single line, below is a multiline. Everything's fine and works as expected, up until I put too much stuff into the multiline EditText. When I fast scroll the view, the scrolling skips and stutters, very obviously, the whole effect is rather disturbing. tried on a Galaxy S3 with a custom AOSP ROM, and Note 4 with official 5.1.1, no difference at all.
I would expect a very heavy EditText makes it difficult to smoothly redraw on a fling, but this starts happening with relatively short text (approx 4-5 screen-pages long).
Edit: This also seems to happen on a simple scroll, when I do as much as touch it and move it a few lines (scrolling is not near to being smooth, that is)
The setup
I have reduced the widgets to the bare minimum, even removed padding, only the problem does not improve. From the Java code I also removed anything (any styling, or typeface, anything that affects the widgets at all), still no improvement.
If this is of any significance, the ScrollView in question is inside a fragment, that is one of two pages of a ViewPager. There is nothing else on this fragment ATM.
Here's the XML (as you will see, it's as base as possible):
<ScrollView
android:layout_width="match_parent"
android:layout_height="match_parent">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">
<EditText
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:singleLine="true"/>
<EditText
android:layout_width="match_parent"
android:layout_height="match_parent"
android:isScrollContainer="false"
android:inputType="textMultiLine"/>
</LinearLayout>
</ScrollView>
What I tried
Any advice I found regards only ListViews, and some attributes like android:smoothScrollbar, which have no effect here (I tried them all).
For the record, I did try out of frustration all of the below ( I know most of these has not much to do with ScrollViews, but I'm becoming hopeless here):
android:hardwareAccelerated="true"
android:fastScrollEnabled="true"
android:scrollingCache="true"
android:smoothScrollbar="true"
and also tried setting from the Java code things like
.setSmoothScrollingEnabled(true);
.fling(3500);
still no luck.
Question recap
Is there any way to make a simple widget like this scroll smoothly at all?
Thanks for your time if you've read through and even more if you answer. :)

Android 2D Game Architecture

I am creating a 2d puzzle game on android and want to get the community's input on a design decision. The basic design is this. There is a SurfaceView one which the 2d graphics are drawn in a background thread. Then I also have a RelativeLayout that overlays the surface view. The layout .xml looks like this:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:id="#+id/root"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:gravity="center" >
<SurfaceView
android:id="#+id/game_surface"
android:layout_width="fill_parent"
android:layout_height="fill_parent" />
<RelativeLayout
android:id="#+id/game_overlay"
android:layout_width="fill_parent"
android:layout_height="fill_parent" />
</RelativeLayout>
All touch events will be received by the game_overlay and will be routed to the game thread as needed. I will use LayoutInflater to inflate a layouts and place them inside game_overlay, then clear the game_overlay when needed. My rational for doing things way is that you get the best of both worlds. You don't have draw your own custom buttons to the canvas (Like a reset level button), rather leverage all that powerful android layout functionality. However you are able to perform the game rendering in the background, and have that thread stay alive all the time.
So now onto my questions. If you have tried something like this before I would like to hear your experience. Can I expect to pay a performance penalty for layering views like this? And more importantly would that performance hit be detrimental to the app's frame rate? Is there any other problem with this approach that you can spot.

For better game performance you should keep buttons at minimum since its for smart devices , try to rely on touch inputs for game play.
For custom buttons i disagree ,Also having your own buttons is better for visulation. It makes fancy your game.
And for your question yes you should avoid unnecessary capsulation. But i don't think it will cause a giant performance problem.
This can be a nice tutorial for surface click me

Missing or Incorrect images and backgrounds randomly throughout app lifecycle

I was hoping someone here might have an idea what causes this sort of behaviour:
Throughout my application, in seemingly random places and in random conditions I'm observing this strange UI issue. Images are on occasion being loaded black (with the correct bounds) or with the incorrect image source (again, with the correct bounds). This effects ImageViews and has effected android:background tags with references to colour resources.
My application relies on 6 library projects, it runs Native Code via a Service and Activities in the App use GlSurfaceViews (although, not all Activities which display the problem contain OpenGL components). The problem could I suppose be from any of these places or a combination of them through using large amounts of memory.
You can see this behaviour in the following screen shots:
This is actually a 6 or so pixel wide column separator image which has been incorrectly drawn into my ImageView (the ImageView seems to have correctly sized itself).
When going out of the Application and then back in again (repeatedly) it instead appeared (and remained) like so:
After a Force Clear and a Clear App Data it returned to the correct format:
As you can also see the Magnifying Glass image next to it is displaying fine in each of these. The problems with these missing/incorrect images and backgrounds seems to happen randomly, throughout the application lifecycle, and I've been unable to find a way of reproducing it.
The layouts for these images are nothing special, I'm not doing anything funny during the rendering lifecycle (i'm not overriding onDraw() or onMeasure() or the like). The source of these images aren't being set dynamically but via the XML.
As you can see from the above example, it's not a build issue as it occurs between app lifecycles not between installs. It's also happening on different devices, Samsung 8.9, Acer Iconia Tab, Motarola XOOM,
It seems to me to be some sort of error with the reference table, could it perhaps have been nudged by my native code? Or is it an effect of me in some stages of the application using too much memory?
Here's the XML source for the above example:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:id="#+id/browseProgressWrapper"
android:layout_width="match_parent"
android:layout_height="#dimen/actionbar_compat_height"
android:orientation="horizontal">
<RelativeLayout android:layout_width="#dimen/search_bar_width"
android:layout_height="match_parent">
<EditText android:id="#+id/browseFilter"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_marginTop="4dp"
android:layout_marginLeft="5dp"
android:imeOptions="actionSearch"
android:background="#drawable/edit_text_blue"
android:maxLength="30"/>
<ImageView android:id="#+id/clearSearch"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentRight="true"
android:layout_centerVertical="true"
android:src="#drawable/ic_input_delete"
android:layout_marginRight="5dp"/>
</RelativeLayout>
<ImageView android:id="#+id/browseFilterButton"
android:src="#drawable/ic_menu_search"
android:scaleType="center"
android:layout_width="#dimen/actionbar_compat_height"
android:layout_height="#dimen/actionbar_compat_height"
android:layout_gravity="center_vertical"
android:minWidth="#dimen/actionbar_compat_height"/>
</LinearLayout>
A more full description of the code / layout surrounding another such occurrence I happened to get the screenshot for:
I have a "Settings" Activity which restarts my app after saving new settings details. It does this by stopping a Service, calling a new Activity (the Splash Activity) and finishing itself:
mConfiguration.save();
mConfiguration = new Configuration(Configuration.getInstance());
getActivity().stopService(new Intent(getActivity(), NativeService.class));
getActivity().finish();
startActivity(new Intent(getActivity(), SplashActivity.class));
Most of the time (and on most devices) this works fine, the Splash Activity contains an image which loads correctly. Sometimes though on some devices the Splash Activity loads either an incorrect resource (what my testers refer as "an upside down Nike tick") or just a blank box (as seen below). Does anyone know why?
Here is the Layout for the Splash page, as you can see it's pretty simple, no surprises:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#color/ContentBackgroundColor"
android:orientation="vertical" >
<View
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_weight="2" />
<ImageView
android:id="#+id/image"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center_horizontal"
android:src="#drawable/manager_android_400" />
<View
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_weight="1" />
<ProgressBar
style="#android:style/Widget.ProgressBar.Large"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center_horizontal" />
<View
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_weight="2" />
</LinearLayout>
Theory tested and debunct:
I've theorised that this could be a processor/memory issue where the Layout isn't being drawn fully before the Splash screen exits and moves onto the next Activity so I put in this piece of code:
image = (ImageView) findViewById(R.id.image);
image.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
#Override
public void onGlobalLayout() {
image.getViewTreeObserver().removeGlobalOnLayoutListener(this);
moveToStartScreen.start();
}
});
The hope was the code above would make sure the Image is definitely loaded before moving onto the Start page but seems to have had no observable effect.
Another Theory
I was also wondering if this could be being caused by the R.id / R.colour / R.drawable resources some how being currupted in program execution? Does anyone know why that might happen.
Could my native code be running rampant on some memory addresses that Android isn't correctly allocating?
Has anybody noticed this before - or perhaps know why this behaviour occurs?

Graeme, I had almost the same problem and found out that it was a reported bug of the android plattform. It was corrected in the 3.0 version I think. Which API are you compiling with? Try to build with the last available api and be sure to compile with JDK 1.6
If your problem is related to this bug, this should fix the problem.

This is a simple problem of refresh, clean, and rebuild.
Images in your various drawable folders or resource id indices are out of sequence because they were either changed outside of the eclipse IDE (via external source control such as GIT, SVN or other edits) and not refreshed in the eclipse navigator. Or, the files may have been updated in a library project upon which your UI Activity depends.
I have found that although .java file dependencies are propagated throughout the system, this is not always the case for resources such as images and .xml files.
The solution is fairly simple, clean everything, refresh all of your projects, and rebuild. The stretched or black edges should be gone.
Note: The predominant manifestation of this problem occurs when 9-patch images become treated like standard .png images. This means that they get stretched in a linear manner across the image instead of just at the edges. To me, this explains your 'Torn/Stretched' example. I have seen similar often. Another common manifestation is that text strings occasionally get displayed with the wrong resources!

Making floating bubbles

I'm trying to make the background of my app have randomly floating bubbles. I've been looking around for anything similar, such as falling snowflakes, rain, etc. but I can't seem to find any examples.
Even if I can't make a bubble.png float randomly upwards, I'd like to at least have a . character or something that could represent "bubbles" like in a soda.
Any ideas or references? Thanks!

You could place a SurfaceView behind your primary UI in a FrameLayout and draw the bubbles in the SurfaceView following one of the available tutorials. The rest of your UI would then overlay on top.
Example:
<FrameLayout android:layout_width="match_parent"
android:layout_height="match_parent">
<SurfaceView android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="#+id/surface" />
<FrameLayout android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="#+id/app_content">
<!-- Normal app UI goes here -->
</FrameLayout>
</FrameLayout>
Warning: No matter what approach you take you're going to be redrawing the entire screen quite frequently several times per frame. (Animating the background plus drawing the UI.) Some ways will be faster than others but you are choosing to do more work than most apps do in drawing their UI. You will need to be mindful of performance and small inefficiencies; they will add up quickly.