Develop Reference

May two View subclasses work as two Fragment in one screen?

I have a little app wich contain MainActivity and two subclasses of View - FirstScreenView and SecondScreenView.
Now MainActivity manages both subclasses and output them successive.
I want to show both classes in one time in a one screen (in this layout - firstscreen.xml that is used instead of main.xml now. main.xml does not exist).
I know that this challenge can be overcome by applying the fragment. But my classes extends View, not Fragment.
May two View classes work as two Fragment in one screen?
Please, tell me in what way and how should I solve this problem.
Thank you (and thanks Google Translate).

Talking from a UI perspective, the app will look the same. Talking from a functional perspective, the app could do the same. The only difference is that if you use fragments, you will have to manage both lifecycles.
I rather preffer what you have done, working with these two views. Remember that if you work with custom views, it is a best practice to delegate its logic to the activity, something you will relay to the fragmeents in the case you use them.

Situation where you would use FragmentTransaction.replace instead or show/hide or detach/reattach?

After spending a fair bit of time figuring out that the reason my fragments chosen from a drawer layout weren`t displaying sometimes due to the choreographer skipping frames (I was using transaction.replace rather than show/hide) it made me wonder -- what are the situations where one would want to use replace rather than show/hide or detach/reattach? My problem went away when I switched to using show/hide btw.
Taken from this thread I got this on what happens when you call FragmentTransaction.replace():
Android will effectively perform a sequence of
FragmentTransaction.remove(...) (for all Fragments currently added to
that container) and FragmentTransaction.add(...) (for your supplied
Fragment). Removing a Fragment from the FragmentManager will cause the
Fragment to be destroyed and its state will no longer be managed. Most
noticeably, when you re-add the Fragment all of the views will have
been reset. Note: since you are reusing the same Fragment instance,
the Fragment will still keep the value any instance variables.
and from this thread I got that it is probably better to show/hide rather than replace if you plan on using that fragment again. My question is, in which situations do you use FragmentTransaction.Replace()? The only place I could see it really being useful is for something you know you won`t need again, kind of like a dialog picker with options but I use dialog fragments for those situations.
Does anyone use FragmentTransaction.replace regularly, and if so, why did you choose that over another method? Cheers

It maybe useful, for example, when implementing a deep fragments hierarchy in Multi-pane pattern (when click on item in the right fragment moves it to the position of the left).
Also, since hiding a Fragment keeps it in FragmentManager, it maybe expensive if you have a heavy content in it or hide multiple instances. Calling remove() or replace() and properly saving fragment's state is more Android-way, I think.

Using ViewHolder-pattern in a detail Fragment

In my Android project I have an Activity that uses a Master-Detail view, created with two fragments.
My detailfragment is giving me some "problems" though.
It consists of 50+ controls (TextViews, EditTexts, CheckBoxes, Spinner). Of this 50+ controls I programmatically get a reference to 32 of these controls in my detail-fragment and load their data from my SQLite database.
When I run this and initialize my controls by using
(SomeControl).findViewById(R.id.mycontrol);
LogCat keeps warning me about that I might be doing too much on the main thread.
I know that findViewById and inflating views is an expensive operation, so I had an idea!
I was wondering if there was some way to use the viewholder pattern or view-recycling on my detail-fragment like I'm doing on my ListFragment. that way I could avoid reinitializing my detailview each time I select another item in my ListView. And avoid calling .findViewById as much as I do. Does anyone have an idea on how to implement something like this. Would it make any difference if I did initialization of the controls in the onCreate-method of my detailsfragment? I was also thinking about making my detailsfragment a "singleton" and then just use getLoaderManager().restartLoader when the selection of my listfragment changes. Any thoughts on all of this would be very much appreciated.

Well unless you're using the exact same layout for each control then I'm not sure if there's a way to do that.
But there may be a way to solve your problem: using an AsyncTask.
As long as those controls aren't necessary for your program to crunch data (and from your explanation I don't think the UI elements would be triggered until the user has interacted with it) you should be fine and the main thread will be free to do whatever it needs. The only downside I see with this method would be that some UI elements might appear maybe a half a second late (not so bad if you think about it).

Found a solution. Had to change my implementation entirely though.
Now my implementation is using loaders on both ListFragment and DetailFragment.
Here's a list of changes I've made:
Created a interface for my ListFragment with one method (onSomethingClicked(SomeObject obj)) and made ListFragment observable through this interface.
Implemented the interface in my DetailFragment and registered a listener on the ListFragment.
Implemented the method onSomethingClicked() in DetailFragment. When this is triggered i pass data from ListFragment to DetailFragment and restart my DetailFragment-loader and load data into my already initialized controls in OnLoadFinished.
No need to inflate the view every time the selection in the list changes and no need to .findViewById's AND MOST IMPORTANTLY no more Choreographer warnings :)

Listening for fragment transactions

I need to know when fragments(and which fragments) are added/removed/replaced, especially when popped from backstack. I'd like to be notified both before and after the transactions occur, as I sometimes want to delay a transaction for changing an underlaying layout. So in general, I'd like to run some code before and after the transaction plus eventually delay the transaction. I've already thought about using custom animations for that purpose but transactions only accept ids, no objects/classes. And there might be a better solution I currently can't think of. Any ideas?

I've been using the fragments for quite a while and if you want something ready out-of-the-box you're out of luck.
The only listener available is the addOnBackStackChangedListener and that's it.
But remember that every call that creates and commits a fragment transaction is made by you, either directly via code or indirectly via fragments instantiated on a XML layout or passed to you via the Actionbar tab.
So based on that you should be able to organize your code in some way to always call through a wrapper, but it will be a big work for sure.

Calling setContentView for animation

In my application we are achieving the page-animation by using setContentView every time the animation occurs. The layout contains just an image so its definitely not too heavy. But are there any other problems in calling setContentView again and again on the same activity. Will it cause memory leaks or something similar.
Tried searching the net but since our layouts contain only the imageviews the onSaveInstance also doesn't have much to do.
Let me know your inputs.
PS I know about ViewFlippers and other waqys of animation. Was just curious if its advisable not to call setContentView in an activity repeatedly and Why?
And I can't create a tag for setContentView if any of you can please tag this question with that tag.