Adding a view to an already created activity/fragment without considering their root layout

from the CommonsWare Community archives

At September 12, 2019, 5:09am, root-ansh asked:

So the case is this : i have a view whose details like size , content as well as position(in terms of gravity: like centre, start ,end, top, bottom, etc) are loaded from the server as an asynchronous request.
I know only framelayout would be able to exactly support these, so what is the possible way by which i could somehow add my view “over” its current layout?

At September 12, 2019, 10:55am, mmurphy replied:

So would ConstraintLayout or RelativeLayout.

I do not know what “its current layout” means and how this relates to this view. You can create the view using its constructor, and you can add it to a parent ViewGroup using addView() and a suitable LayoutParams object to describe your requested size and positioning.

Going back to your question title, each activity has a FrameLayout known as android.R.id.content. You are welcome to try adding your view to that FrameLayout. At least initially, the view will appear “over” whatever else was previously added to the FrameLayout, as later children are higher on the Z axis.

However, the “without considering their root layout” concept can fail in many ways, such as:

Choosing “top” gravity might have your view appear over the Toolbar or action bar, which may or may not be what you want
The activity might clear the “content view” FrameLayout, wiping out your added view
The activity might add other things to the “content view” FrameLayout, and your added view will no longer be on top in terms of the Z axis

For reliability, activities should participate in the placement of this view.

At September 15, 2019, 9:02am, root-ansh replied:

You are a great help, thanks.

I forgot i posted this question here and was able to solve that myself, but seeing your reply makes me worried about my approach.

I also used android.R.id.content, but i didn’t knew much about that, so i am using a fragment: inflating my view inside that fragment(as per its lifecycle) and then adding it to this android.R.id.content view using the fragment manager.
Your point regarding activity being able to remove it once refreshed looks very much validfor any other view, But is that true for fragments also? Anyhoo will test for that, nice edge case.

I tried another way in which the activity was giving its root layout id as well as its Activity instance to my library. I then created a frame layout and added its view along with my view dynamically. And then ibwas calling activity.setContentView(…) . My Senior noped it right away ,as it was creating a big memory overhaul xD

At September 15, 2019, 11:18am, mmurphy replied:

Yes, insofar as a fragment is really a manager for views. If an activity can get rid of views that you create (manually), an activity can get rid of views that you create (via a fragment).

At September 16, 2019, 6:12am, root-ansh replied:

can you post a code that a developer might add that would cause this? I know that calling the statement setcontentView(<new inflated view>) anywhere in the activity would update user’s layout. But since we are using android.R.id.content, I am guessing (but would probably also test this) that it wouldn’t affect our fragment which is overlaying on the top. I have also added a decent elevation to my view inside that fragment so as to always keep that “floating over the view” .

At September 16, 2019, 10:57am, mmurphy replied:

setContentView() would be one. Changing the mix of fragments in android.R.id.content would be another, such as replacing or removing your fragment.

As would setContentView(R.layout.whatever).

setContentView() inflates a layout into android.R.id.content.