I have one question about when closing my activity and letting it be destroyed.
I think, in my java class that is going to reference my views (for example, my java class references my buttons and textviews on the screen), is it ok for me to put all the view references into a ViewGroup for the purpose of closing them out 100% later?
Sorry for my poor English. Let me further explain:
I create (in java class) variables for my button, textview, and other screen items, and put them into a group so when I want to delete them (null them) later, I can tell Android to delete all the child of the group? Also, maybe I can use group of all my buttons to do loop later too.
Is this bad practice? Is this ok to do this or is this not the intention of the ViewGroup? I read document on ViewGroup, but it does not say about if this is also a use for View Group.
Thank you for all answers. I am learning every day.
When designing a view, you use layout xml typically. That's loaded into Activity's onCreate() as a view. So in layout xml, you're required to use any layout managers, like LinearLayout, RelativeLayout, FrameLayout etc. They're all child of ViewGroup. So by default, every view is contained in a ViewGroup already.
Regarding your question about destroying, if there's no special case that is retaining the view and its child views, Activity's default implementation will take care of destroying the view and letting it get garbage collected.
Have a look at document reference of onDestroy() funtion, also the method onDetachedFromWindow() is worth looking at.
If you've a special case, that's retaining the view, overriding the onDetachedFromWindow() is a good place to release those views.
Related
ViewSwitcher can be used only for two childs in it. But for a group of textviews to be converted to Edittexts what can be the ways?
It's easy enough to replace views for other views but converting - I don't think so.
To replace views, you can simply do something like the following:
LayoutInflater inflater = LayoutInflater.from(this);
View view = inflater.inflate(R.layout.edit_texts_layout, null);
viewSwitcher.removeAllViews();
viewSwitcher.addView(view.findViewById(R.id.first_edit_text));
viewSwitcher.addView(view.findViewById(R.id.second_edit_text));
So what's going on here?
1) You create a layout called edit_texts_layout which contains two EditText's with the ID's: first_edit_text and second_edit_text.
2) You then inflate this in your Activity or Fragment.
3) You then remove all of the existing views in your ViewSwitcher since, as you rightfully said, there can only ever be two views in a ViewSwitcher.
4) You then add the two EditText's inside that ViewSwitcher by view.findViewById()
Also...
It would be wise to have another layout called text_views_layout and do the exact same thing so that you can switch the EditText's with the TextView's.
But why have the EditText's inside a layout and not create them programmatically?
Good question. Views should live in layouts and live separately from code when possible. It makes life easy where you can work with a view in a layout since you have XML autocomplete and the preview screen so you know exactly what the view looks like - saving you from any nasty surprises later on.
Are there any other alternatives to this?
There's always more than one way to skin a cat and this situation is no different. You could possibly create TWO ViewSwitcher's and with different child views. What you'd have to do then is toggle the visibility to View.GONE and View.VISIBLE alternatively. The caveat? It'll be troublesome to maintain both in memory and to perform any operations on the child views as you'd have to remember which one is visible and which one isn't. With my original answer, you won't have to worry.
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...
I see this question here, and it makes me wonder if what I'm asking isn't really possible:
How to share a view across various activities
Basically, I have a common footer view that I'm inflating (including) in all of my views. However, it uses the same repetitive code to do that. My thought was to create a parent activity class to do this, but it doesn't seem correct to have one activity render the view of another. So should I just create a utility class of some sort, or is there a better way?
You can include other layout XML files directly in another layout file. So whenever you set content to a layout file, along comes your footer for the ride.
If your footer needs code to drive it, just create a custom class for it along with the layout file. Then perhaps during instantiation you can drive the code that needs to execute.
This is a blog of how to do it.
include is very useful while reusing View components.
But remember, if any problem occurs while using include tag, wrap the included view by an arbitrary layout.
If I understand your question, another way of having multiple Activities use the same View instance is by doing something like creating your own Application class (it's seriously easy).
MyApplication extends Application ...
#Override
public void onCreate(), onConfigurationChanged(), onLowMemory(), onTerminate(), getIstance().
As there is only a single intance of "Application" that is statically available it makes it a good place to store and share various objects that need to be passed around.
When overriding the baseadapter on an android listview, you have to implement this method public View getView(int position, View convertView, ViewGroup parent). The convertview is the view that was previously pushed off the list when scrolling, and it's given so that you can reuse that view instead of creating a new view.
My question is, is it really necessary to reuse the view? I can understand reusing it if only a piece of the data is changed. But is the overhead of creating a view really THAT significant? Every tutorial on using listviews I've seen tells you to recycle the view, even on trivially simple views like a textview.
I guess my question is why did google decide to make this the default behavior of the getView method?
A couple of reasons to recycle views:
Object creation is relatively expensive. Every additional object that is created needs to be dealt with by the garbage collection system, and at least temporarily increases your memory footprint
This is more important for more complex views, but inflating and laying out the view objects can be expensive. Most often, you are only making minor changes to the view in getView that won't affect the layout (e.g, setting text) so you might be able to avoid the layout overhead.
Remember that Android is designed to be run in a resource constrained environment.
Finally, its already done for you, and it certianly doesn't hurt anything, so why not use it?
Is it necessary? Only if you like an extra 30-40 fps during flings on a Nexus One. :) (See the slides from http://code.google.com/events/io/2010/sessions/world-of-listview-android.html, slides 13-17)
Why make the device do work that it doesn't need to do by ignoring a significant optimization that's been 95% done for you?