I am coming from iOS. I want to create a picture slider and instantiate it different activities. I want to reuse the code that controls the slide and detects the gestures, so I can just instantiate the same class in each activity.
In iOS I do that by just adding controller logic in a view that I instantiate. How would I do that in android?
Thanks
Ok, after a few days of googling and thinking outside of the iOS mindset I found the solution, which ironically was the same as iOS.
Extend the View class. You can also extend a fragment but that has its own tradeoffs, mainly being that you can't instantiate a fragment inside another fragment. So to not limit your reuse of the class extend views. The downside to that is that with views you need to manage states, meaning that if the user rotates the view, you need to be able to store and restore the state of your view items (text view contents for example).
These links might help you out
https://www.youtube.com/watch?v=YIArVywQe8k
http://www.vogella.com/tutorials/AndroidCustomViews/article.html
http://developer.android.com/training/custom-views/create-view.html
Related
I am working on android application and some team members suggested using one activity and one parent layout for the whole application and each time we need a new screen we just inflate a new layout in the parent layout and destroy the old one.
I on the other hand think that using fragments would be the way to go.
Do you think one way is better than the other?
I would be grateful if you can think of solid arguments to support your claim.
Thank you
UPDATE:
We are using MVC in our application. They want to create a new class for the view while i opted for using the fragment as my view. As it stands now the application has one activity and one layout. To change the view we are calling the same layout,removing its child views and inflating the new view .I dont see how that would be better then just using the fragments as views
I think most Android developers will tell you to use one or more Activities or Fragments. But why?
Basically, because one Activity which is responsible for each and every View in your app would be something like a "god object". This is considered an antipattern, I suppose because it may fast become a maintenance nightmare.
The Android pattern of one Activity and several Fragments on the other hand is following the Single Responsibility Principle, so your code is easier to maintain. All the more so because Android-specific things like saving state on configuration change are much easier to implement if you are able to use the built-in methods.
The demo project provided by google for using the Youtube API. which allow developers to include a youtube player inside there app. I noticed to demoes one is using YouTubePlayerView and the other used YouTubePlayerFragment. I can't really figure out the difference.
Maybe there is a technical difference. What is it?
Fragments:
"A Fragment represents a behavior or a portion of user interface in an Activity. You can combine multiple fragments in a single activity to build a multi-pane UI and reuse a fragment in multiple activities. You can think of a fragment as a modular section of an activity, which has its own lifecycle, receives its own input events, and which you can add or remove while the activity is running (sort of like a "sub activity" that you can reuse in different activities)."
http://developer.android.com/guide/components/fragments.html
Views:
"This class represents the basic building block for user interface components. A View occupies a rectangular area on the screen and is responsible for drawing and event handling. View is the base class for widgets, which are used to create interactive UI components (buttons, text fields, etc.). The ViewGroup subclass is the base class for layouts, which are invisible containers that hold other Views (or other ViewGroups) and define their layout properties."
http://developer.android.com/reference/android/view/View.html
What's the difference?
"So, the main reason to use Fragments are for the backstack and lifecycle features. Otherwise, custom views are more light weight, simpler to implement, and have the advantage that they can be nested."
What is the benefit of using Fragments in Android, rather than Views?
Hopefully this help clears things up.
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.
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 :)
I am trying to make a sudoku application. It's a fragment based design, in which a fragment hosts a custom view which is a board. I am trying to learn how to build an effective communication within FragmentActivity, Fragment and View
Although a view is created using the FragmentActivity context and I can catch a reference to that context within the current view and then call methods inside FragmentActivity I don't want to tie views so directly to a fragment activity. Instead I want to tie the view to use methods inside a fragment. How can i do that, I can I capture a reference to a fragment and call methods inside that fragment from a view?
First of all, I strongly recommend that you read through the documentation on Fragments, as you clearly don't understand the whole concept/purpose of using Fragments in the first place (which is OK, because they are confusing the first time you learn them :P).
A lot of your question doesn't make very much sense to me, because I'm not sure what the View you are speaking of refers to. What I can tell you is that Fragments have their own UI/layout, along with their own separate lifecycle. So it sounds like you don't want your FragmentActivity to interact with the Fragments layouts/methods at all... instead, you should implement the UI's behavior and layout inside of the Fragment itself. That is, the Fragment will be in charge of updating the UI, receiving click/touch events, displaying information on the screen etc. The FragmentActivity will simply hold a reference to the current Fragment(s), and will be in charge of displaying/swapping in and out new Fragments as necessary (via the activity's FragmentManager).
Hope that answers the question somewhat... read through the documentation a couple times, it sounds like you are just misunderstanding the theory/purpose behind Fragments.