Can we make use of multiple Activity classes in a single screen of Android app?
For example, make use of multiple Activity classes to call different web services and populate information on the screen?
A activity represents one screen on android. I think Fragments are what you search for. With Fragments you can show more layouts on one screen.
Related
This is the image explaining the usage of fragments. The first image shows two fragments and two activities.
Lame doubt. Why use two activities when the sole concept of using fragments is err.. using fragments instead of switching activities.
Depending on your goals you can do it either way.
The method shown in the guide can be implemented entirely in XML layout files so it is a better method to teach to a new user of fragments.
The method you suggest requires the developer to manage fragment transactions in code, which is not too difficult, but why do it if your app does not have any special behavior that requires the extra work.
Also, since the animated transitions between fragments look different than activity transitions, your method will reveal the use of fragments at the user level. The method in the guide uses fragments as a modular programming technique that is transparent to the user.
You end up with an app that uses available space on all device types, but on a small device it acts just like a classic app that users already understand.
The idea is that when you have extra room (such as on a tablet), you can display the content from what would have been two activities side-by-side rather than as two separate activities.
Think about a mail application. On a phone, you fn really only fit the list of mail on a screen, and you click on one to open the content of that mail on another screen.
If you did that on a tablet, there's a huge amount of wasted space; you can display the list of mail on the left side of the screen, and the selected mail's contents on the right side.
Because the list UI is the same in both examples, and the mail-display UI is the same in both as well, you can reuse that UI by including them as fragments. The logic for those UIs is also self-contained in the corresponding Fragment classes.
This allows the user to see more content with fewer activity switches.
Just I have created graph chart using Chart Engine Android
I have used data from my database to use value for chart.
Now I have one activity which is main to display graph chart with left menu options.
So Whenever i am calling chart activity its going to show its own activity sepratly.
I want to embed that chart activity with my main activity with left menu options.
Is it possible? I am using android 4.0
How to solve this task? Please help me friends.
It sounds like your application would benefit from using Fragments The developer site has some very good information you should read.
You can't embed an Activity into another in Android, as Activities are meant to be independent objects.
Since android 3.0, you can use Fragments, which are Activities sub-elements, which you can combine in many different way. For example having your Activity using one left fragment to display a list of items and a right fragment to display the details of the selected item.
You should take a look at the Fragements documentation to implement this in your application.
Try Activity Group.
http://developer.android.com/reference/android/app/ActivityGroup.html
This question already has answers here:
Dilemma: when to use Fragments vs Activities:
(17 answers)
Closed 4 years ago.
I often need the different parts of my applications to have their own special behavior and UI, and I don't know how fragments can help. In most cases, I think it is quicker to create 2 different activities (e.g., 1 for tablets and 1 for handsets), and to share the common behaviors and events in a third class.
So, keeping this in mind, why should I use fragments ?
Fragments are more of a UI benefit in my opinion. It's convenient for the user sometimes to see two different views of two different classes on the same screen. If, in your moment of creativity, you decide it would be nice to display your application with, say, a listView that takes up half the screen and a webView that takes up the other half - so that when you click on a list item in fragment A it passes an intent to the webView in fragment B, and suddenly you see what you just clicked without the app switching activities - then you could use a fragment. That's just an example I came up with off the top of my head.
Bottom line: Fragments are two or more activities on the screen at the same time.
The benefits I see when using fragments are:
Encapsulation of logic.
Better handle of the lifecycle of the fragment.
Reusable in other activities.
The drawbacks I see are:
More code(For example, instantiating a fragment manager, adding the fragment transaction, writing the callbacks of the fragment)
Communication between fragments and activities is harder. As #jonney said it, you would need to deal with a parcelable interface to serialize your objects you wish to pass.
So, when deciding to use a fragment, I would ask myself the following questions:
Is the lifecycle of the fragment different from the activity's lifecycle?
If the lifecycle is different, you get better handling of the lifecycle using a fragment. For example, if you want to destroy the fragment, but not the activity. Such is the case, when you have a pager adapter.
Is the fragment going to be used in several activities?
The user input events will be reusable if you use a fragment.
Is the amount of communication between the fragment and the activity small?
If you need to pass big objects to the fragment, you would need to deal with the code that serializes them. Also, if you need to communicate between fragment and activity, you would probably need to implement interfaces. This, in most cases, adds complexity to your codebase. It's not a difference maker, but a criteria to take into account.
Google advises you to ALWAYS use Fragments.
Why? It's simple:
In the simplest case, Fragments are used like containers of activities.
Why do you need this? Again, it's simple.
Android 4 (ICS) supports both Smartphones and Tablets. This means the SAME application will be running on a smartphone and a tablet and they are likely to be very different.
Tablets have big screens which will be empty or unused - unless you assign it properly.
That means- Putting two fragments on one activity like Contact List and Contact Info.
The smatphone will display contact List, and on a touch- display the contact's Info.
On a tablet, the user will still see the list and the info will be next to it.
2 fragments- on one screen....
Smart? yes... supposed to be back compatible down to Android 1.6......
#############################################################
O.K, Already Knew That? then - just try to understand the case solved:
A lot of things work that way- list & details, Menus and Sub-Menus, Info, Detailed Info and some more detailed info.
You want a way to keep it natural and smooth for a tablet which you expect to preform that way, but can't expect smartphone to display it all like the tablet did...
Get it?
for more Information, check out this.
I really think you just need to catch the concept....
Historically each screen in an Android app was implemented as a separate Activity. This creates a challenge in passing information between screens because the Android Intent mechanism does not allow passing a reference type (i.e. object) directly between Activities. Instead the object must be serialized or a globally accessible reference made available.
By making each screen a separate Fragment, this data passing headache is completely avoided. Fragments always exist within the context of a given Activity and can always access that Activity. By storing the information of interest within the Activity, the Fragment for each screen can simply access the object reference through the Activity.
https://softwareengineering.stackexchange.com/questions/244771/why-use-android-fragments
Fragment primary support more dynamic & Large UI Screen like Tablet.Because Tablet screen is much larger than normal Handset. There is more room to combine & Interchange UI Component.
Fragment allow such design without the need for such complex change in the View hierarchy.
By divide activity layout in fragment, we become able to modify activity's appearance at runtime
Are there any patterns on how to handle UI Transitions in Android Activities vs Fragments? I am currently looking into a UI that has at most 3 columns in Landscape.
I would like the UI to start with 1 column all the way across the screen and then on selection of something move in the second column and then on clicking on something in the second fade in the 3rd on tablets and phones and fade out the 1st column on phones.
I am wondering when I should do this as an Activity transition and when I should just use Fragments with Views that Appear. As far as I have read fragments can be moved over to other activities so my choice is either implement Activities with static column layouts that then transition taking the fragments with them or have one Activity with all 3 columns and have the Activity manage the Appearing of the Fragments. Both approaches could work but I was interested in pros and cons from as many angles for both solutions.
There are two questions similar to what I am asking but don't quite answer mine
Two panel UI with Fragments vs Separate activities
Android Honeycomb: layout problem - hide/show FrameLayouts
Fragments can seem like more code up front (since you're putting a view in a fragment, and a fragment in an Activity, instead of just a view in an Activity), but they're great at saving you from headaches in just this kind of situation- Definitely go with Fragments. They even handle the transitions for you.
We have some sample code called "Honeycomb Gallery" you can take a look at here, which has a two-column-plus-actionbar layout, and the ability to show/hide the leftmost column. This should give you a good head start in figuring out how to do layout for multiple fragments and show/hide them.
FYI, one important trade-off to using multiple fragments in an Activity instead of multiple Activities, is that fragments don't directly respond to intents - For instance, if you had a note-taking app where "View Note" page was an Activity, and you changed it so that there was a "view note" Fragment inside the main Activity, then you'd have to set it up such that the main Activity received a note ID AND a note action (create, view, edit, whatever) in the Intent, as opposed to just having the "view note" activity receive the note ID in the Intent. The main Activity would then need to set up the fragments on the page accordingly. Not a huge deal, but if external accessibility to various parts of your application via Intent is important, then it might be easier to break your app out into a few Activities, as well as use fragments to represent the individual components.
Based on the page The Android 3.0 Fragments API, an Activity is stand alone while a fragment can be though of as as a mini-Activity, which must be hosted within an actual Activity.
It goes on to say that the introduction of the Fragment API gave the android developers the opportunity to address many of the pain points developers hit with Activities, so in Android 3.0 the utility of Fragment extends far beyond just adjusting for different screens:
I think that using a single activity for an app is not necessarily a wrong decision, just a matter of style. It is a decision that you should make based on what you are trying to accomplish.
However, the introduction of Fragments was seen to solve real world problems. Based on that alone, I would recommend that you writing some "Proof of Concept" code and evaluate the results. At this time, this may be the only real world test that will matter
Use Activities for Full Screen
Use Fragments for Part of or no Screen (but not a service)
In my main application, there is on-screen tabs in a horizontal scroll-view I wanted to persist across multiple sections of the app. Sections include
News,Photos,Videos,Schedule etc. All single-user focusable tasks.
The main Application that houses it all is a application, and the tabs are just a view which call the fragment Manager.
However, I use Activities for complicated user activities deeper in the application. E.g. if someone plays a video, views a item detail page and the photo-gallery/slideshow sections, because they are all full screen components.
There is no need to show/hide fragments when transitioning to full screen because the activity stack handles everything you want to do it quickly and easily, and keep your code minimal and clean.
So I have Activity -> houses fragments -> launch full screen Activities for special commands.
i am using the following method in a new application i'm developing.
there is a main activity, which instantiates different classes that extends RelativeLayout, and i'm using setContentView to switch between the different modules of the application.
i wonder if this is a good approach or necesarily i have to use different activities to the several screens the app haves.
I'd recommend using different activities, then you automatically get navigation between them via the back button. Plus, there will be subtle things that won't work right if you do it the way you're describing -- for example, Android automatically saves the focused control when you switch activities. It won't do this for your content views; you would have to save/restore focus yourself.
Alternatively, if it doesn't make sense for a user to go "back and forth" between the screens of your application, then you could still implement the application with multiple activities, using android.app.TabHost. This is what the Contact app uses, for example. Then each screen is just a sub-activity, and the whole app is really treated as a single activity. And if you want, you can use TabHost without actually having tabs. You can hide the tabs and enable navigation via buttons or menu items instead.