I want to understand the reason why request feature must be called before setting a view in android activity
From the documentation:
Enable extended screen features. This must be called before
setContentView(). May be called as many times as desired as long as it
is before setContentView(). If not called, no extended features will
be available. You can not turn off a feature once it is requested. You
canot use other title features with FEATURE_CUSTOM_TITLE.
requestFeature modifies the window that you are inflating a view on. The window must be set before you can inflate a view on it which is what setContentView does. In layman's terms, you wouldn't try to hang blinds before you put the window into a wall right?
When the view inflates it needs the window to be set and stable so it can properly calculate where to put items. If the window is not constant then the content view would have to be reinflated after every requestFeature. If Android did not enforce the rule of requestFeature before setContentView, on every requestFeature the view would be reinstalled and the end result would most likely be the screen flickering a few times as the view gets reinflated time and time again.
Related
According to concept of recycling items mechanism in ListView.
I want to know, actually, how i can detect a moment when a View going off-screen.
I explain why.
In most cases ListView have a custom
Adapter(? extends ArrayAdapter / ? extends BaseAdapter, etc.).
getView(...) method allows to manipulate visibility and content of views (text,bitmaps,drawables,etc.)
And in some cases i need to launch a separate Thread which doing background work, and after that update UI. Actually - using AsyncTask.
When i have many items in ListView each call of getView will be produced start a new Thread. I need to cancel them if View is no more longer present on the screen. How to do this?
You can override onDetachedFromWindow for the view.This will let you know when the view is going off-screen.The docs says:
protected void onDetachedFromWindow ()
Added in API level 1 This is called when the view is detached from a
window. At this point it no longer has a surface for drawing.
See Also
onAttachedToWindow()
is there a listener or some way to determine when contentView is created? I have used other type listeners and they work for other child views inside of content view. however content view is different. I have not yet found anything that works.
Have you tried onContentChanged() yet?
The documentation says
This hook is called whenever the content view of the screen changes (due to a call to Window.setContentView or Window.addContentView).
Hi I'm having trouble understanding how to draw a custom view at runtime. For simplicity sake, say I have a custom view (Box) that extends the View class, and basically all it does is create a square which is configured to do in my onDraw() method. Now I want to be able to draw this custom view in an activity depending on if the user clicks a button on the activity.
So if the user clicks the button once, one box is drawn, clicks again another box is drawn maybe 10 pixels down etc. I searched for a solution but all I can find is people using a pre-made xml with the view and then using an inflator but I dont want to have a pre drawn box if the user hasn't pressed the button.
Also another quick question: When is onDraw() called or do I have to explicitly call
Box box = new Box();
box.onDraw(canvas);
Eclipse says that's a suspicious call, I agree.
To make a custom View you have to extend View class and override onDraw method. Then when you want to draw this view you have to add it to your view hierarchy. This is as simple view.add(new Box()), where view is your root view, this way Android system would invoke onDraw method by itself on every rendering cycle. For more information refer to official documentation.
I'm writing a library for mobile devices. This library notifies the users when certain things happen (login, actions, etc). The way it works in iOS is modeled after GameCenter. A window animates down from the top of the screen, notifying the user, and then animates off.
In iOS, I can easily get the current view in the UIWindow and add my view to it. I'm fairly new to Android, and I can't figure out how this is possible. It seems like unless you have knowledge of the current Activity and its layout, you can't add a view to it.
Is what I want to accomplish even possible? Is this even the correct solution for Android or would an Android user expect something different?
You can get the root view of an activity by calling getWindow().getDecorView() on the activity object or inside of the activity. If this is a ViewGroup you can add a view using addView(View viewToAdd), if this is not an instance of ViewGroup you cannot add a view to it unless you wrap it in a ViewGroup.
If these are your first applications in Android, use XML layours put in resourses. In this case you always must know what Activity are you in. Whithout it you can't read resources.
If you use pure code for views, you alweys can get your activity, because every your activity is a class. Put all operations in the class base for all your activities and use this.class in them for obtaining the current activity name.
You can also pass the current activity as a parameter into the library functions. So you have access not only to its root view, but to the context, to, and that will allow you to show toast messages about problems and have access to resources. (Passing context is a very common practice in Android coding.)
All you need to do is call addView() on the ViewGroup.
I was working on an app tonight and I noticed that I have two similar activities which have different layouts (mylayout1.xml and mylayout2.xml)... but within those layouts I have some elements that are identical, right down to their ids ("#+id/mybutton" in each layout file).
When I setContentView(R.layout.mylayout1) in an activity and then findViewById(R.id.mybutton) to perform setOnClickListener(), how does Android "know" which button I'm really referring to when I finally click it?
Everything seems to work just fine, with the appropriate callbacks triggering (and not, so far as I can tell, going to the wrong activity - though only one is on-screen at a time in my tests so far (e.g., dialog-type activities). It just occurs to me (as I noticed this duplication during unrelated work) that maybe this is working simply by chance rather than design. OTOH, if Android is being smart about it, I won't worry as long as more than one instance of such an element is never on-screen at the same time (such as OK buttons).
When you are calling setContentView the view hierarchy from XML is parsed and created. When you then search for a View with a specific id android will look into that view hierarchy and search for a view with that matching id. So you will never end up with a view element which is defined in some other .xml file with the same id because these view elements are not part of the activities view hierarchy.
That's because the setContentView(View) method sets, as stands int the doc, the activity content to an explicit view, and finbViewById(int id) refers to the view object you set with setContentView. As matter of fact, if you refer an element in a layout that you do not properly set, the application crash with null pointer exception...