I was able to get a TabActivity working properly with multiple Activity's using ActivityGroup. However, I noticed a weird behavior. When clicking on multiple screens in one tab, going to another tab and navigating back to the original tab where user was already navigating several screens, the ActivityGroup goes back to the main Activity rather than the last visited one.
I was following the tutorial here:
http://ericharlow.blogspot.com/2010/09/experience-multiple-android-activities.html
Is there a work around for the ActivityGroup to prevent this kind of behavior?
I think it is better to look for a tutorial on Fragments.
I know this is not really the answer to your question, but I think it would be better to immediately use Fragments. This because Fragments are now recommended for Android development, and should be used as much as possible in favor of older technologies. And the stuff you want to do, are the perfect example of things that should now be done with Fragments.
The tutorial you are pointing to is from 2010, so that means that the technology used there will be rather old (I haven't read it though, but I can imagine it will). It is best if you want to develop something, to immediately use the latest technology, in this case: Fragments.
Some information on Fragments
Related
I am developing a forum reader, which I expect that it will be run on phone only, not tablet.
The application originally have 3 views, and each is assigned with an Activity.
For example, if the user select a board on "Board selection screen", an Activity will start, and show the thread list of the selected board to the user.
Recently I have learned how to use fragment in an Android application. therefore I decided to convert my application from an Activity based apps to a Fragment based apps.
Although the apps works as fine as usual after the change, I encountered a problem in saving the state of the fragment. I failed to find the event to let me save the state of fragment (When I am switching from A fragment to B fragment). The most likely event is onSaveInstanceState(Bundle), but according to the API guide, it will only be called when an activity is about to be stopped, and it is not my case.
Actually I have tried to save the state in getArgument() in onDestroyView(). Nevertheless, according to the API guide, the values in getArgument() should only be used for instancing a fragment. Although everything work normal when I am saving the state in getArgument(), I believe that I am doing it wrong.
I have tried to do some googling about Fragment. I found that most of the artist suggest that Fragment is useful when an application is expected to run on both phone and tablet. And I don't find any artist that is talking about how to do screen switching between few Fragment within an Activity. I started to doubt that Fragment are only useful for supporting different device, but not for screen switching.
Sorry for the above junks. My questions are, does Fragment is not very useful when I am developing an application which for phone only? Should I change my application back to an Activity-based apps if I don't expect this to run on tablet?
One more thing Fragments are good at is they are good for Dialogs. Fragment-based dialogs have none of the problems you usually have with showDialog() when rotating the phone
No, you should stick with Fragments. They're incredibly versatile and will make your life easier down the road if you decide to rearrange things. As far as saving state, you just need to override onSaveInstanceState() in your Fragment (not the Activity). This will absolutely be called when switching between Fragments -- I use this all the time.
If we're talking about "just work" you can just go ahead and use fragments or just normal activities and layouts. However, what fragments provide, apart of scalability when developing for other devices like tablets, is that it's giving you more code separation, which is so, so great for the maintenance of the app.
It took quite a while searching stackoverflow and google and can not find a guide to properly explain to me how to implement Tabs in my application.
I know it should not be used TabActivity, I also read about the recommendation not to use TabHost (at least that understanding). My interest is not just changing the content is run a full activity when changing tab.
Example
MainActivity:
- Tab1Activity
- Tab2Activity
- Tab3Activity
My goal is to build an application that is supported by a wide range of devices from api 8 to the latest. I'm using android-support-v4.jar.
My second goal is to load in each tab an activity because at least two of them consume enough resources and speed should always prevail.
Can help me with a guide or explain a "correct" way to achieve this.
You should use Tabs with Fragments.
Look this : http://android.codeandmagic.org/2011/07/android-tabs-with-fragments/
As the other suggested, the best way to implement tabs in your application is to use fragments.
You should not use activities contained in a tabactivity, which is currently deprecated. Even the official documentation suggests to use fragments, stating that
New applications should use Fragments instead of this class
However, if you still feel retro' and you REALLY want to use tab contained activities, you need to use tabhost. A nice tutorial can be found here, but again, I strongly recommend to go for the fragment way.
What are the advantages/disadvantages of using fragments over activities in an application when designing for a phone and tablet?
Should we have activities for phones and fragments for tablets. Is there any advantage of fragments for phones besides making the code reusable?
The android dev site http://developer.android.com/guide/components/fragments.html says on the phone, the fragments are separated into different activities. What then would be the point of using fragments?
1 & 2 what are the purposes of using a fragment & what are the advantages and disadvantages of using fragments compared to using activities/views/layouts ?
Fragments are Android's solution to creating reusable user interfaces. You can achieve some of the same things using activities and layouts (for example by using includes). However, fragments are wired in to the Android API, from HoneyComb, and up. Let me elaborate;
The ActionBar. If you want tabs up there to navigate your app, you quickly see that ActionBar.TabListener inferface gives you a FragmentTransaction as an input argument to the onTabSelected method. You could probably ignore this, and do something else and clever, but you'd be working against the API, not with it.
The FragmentManager handles "back" for you in a very clever way. Back does not mean back to the last activity, like for regular activities. It meeans back to the previous fragment state.
You can use the cool ViewPager with a FragentPagerAdapter to create swipe interfaces. The FragmentPagerAdapter code is much cleaner than a regular adapter, and it controls instantiations of the individual fragments.
Your life will be a lot easier if you use Fragments when you try to create applications for both phones and tablets. Since the fragments are so tied in with the Honeycomb+ APIS, you will want to use them on phones as well to reuse code. That's where the compatibility library comes in handy.
You even could and should use fragments for apps meant for phones only. If you have portability in mind. I use ActionBarSherlock and the compatibility libraries to create "ICS looking" apps, that look the same all the way back to version 1.6. You get the latest features like the Actionbar, with tabs, overflow, split action bar, viewpager etc.
2
The best way to communicate between fragments are intents. When you press something in a Fragemnt you would typically call StartActivity() with data on it. The intent is passed on to all fragments of the activity you launch.
For more detailed understanding of Fragments check Link
I have been browsing the web for a while now and looking at different examples of how to implement a tab bar.
The problem I am having is deciding the correct approach to creating this feature. The option that seems most used is to have one main activity called MainActivity or something and using fragments as the tabs. This is all well and good and I have created an application like this fine.
The problem I am having is I am in two minds as to whether this is the right way to go about it as coming from an iOS development background it just doesn't seem right due to these tabs having different functions.
Any pointers would be great.
EDIT I have also looked into ActionBarSherlock but couldn't get to use it in a project as it kept coming up with errors and I couldn't find a thread that sorted the problems I was having out.
Disco
You should be using fragments, yes. There is an example of how to do it here: http://developer.android.com/guide/topics/ui/actionbar.html#Tabs
This "only" works with Tabs that are part of your Actionbar, though. Shouldn't be too much of a problem, because they usually should be part of your Actionbar. You can also manually move the tabs if you're not content with their location, or roll your own buttons that look like tabs.
Keep in mind that tabs in Android aren't quite the same beast as the tab bar is in iOS. They look similar and behave similar, but there are subtle conceptual differences in how they are supposed to be used. Don't use them for your basic app navigation, but rather for switching between similar "things".
If you want to employ this on device pre-3.0 though, you will have to use ActionBarSherlock. It does work fine and we're using it in several projects, so if you're having problems integrating it I suggest creating a new question for that, I'll be happy to help.
As Android documentation states: "An activity is a single, focused thing that the user can do."
However with Fragments we will be able to do many "things" within the same Activity as Reto Meier suggest. His suggestion is to replace a selection fragment by a content fragment within the same Activity (section "Within our code this produces a dilemma").
Lets say my application is a "bit" more complex, with many activities, with a complex navigation tree and designed with the "single, focused thing that the user can do" principle in mind.
Lets say now I have to adapt it to Fragments and large screens... and that I don't want to create a second application, neither have two completely different logics (one for phones other for tables) inside one application.
Should I have one Activity to manage all the application fragments and fragment transactions? Like Retro Meier suggest above. Is that the recommended path to follow? Thus breaking with the "single, focused thing that the user can do" principle for Activities?
Or am I missing something? I hope ;)
BTW, I think Fragments looks great, but from what I have seen till now, only if you are creating an application from the scratch. Because making applications to be compatible with phone and tablet looks like going to be a bit tedious. Hope to be wrong :)
Dianne Hackborn already has answered (thx for the link mgv):
you could put your entire application in one activity in which you change the fragment structure as its state changes
So then Activity becomes a sort of container where you will be able to plug Fragments. I like the approach, but... in my app there are about 30 different operations available, each one requires about 2 to 4 screens steps to be performed(forms and selection lists), all of them differ and there are also navigation restrictions. It works fine with Activities each one handling one screen/step behaviour.
So then to port to Fragments I should move each screen logic to Fragments and use Activities as containers for each operation. Thus leaving Activities as the ones managing the navigation between Fragments for every operation, right? Looks like going to be a pain to adapt long applications. :(
Current Activity definition should change a bit btw. :)
Should I have one Activity to manage all the application fragments and fragment transactions?
That is impossible to answer in the abstract. However, most applications will have multiple activities, even in a fragment-based world. Some of that will be to accommodate smaller screen sizes, where it will tend to be one fragment per activity. Some of that will be required by the framework (e.g., inheriting from PreferenceActivity). And, some of that will be by GUI design.
Thus breaking with the "single, focused thing that the user can do" principle for Activities?
That portion of the documentation was written in 2008, perhaps earlier. Had fragments existed back then, I imagine the documentation would state that a fragment is a "single, focused thing that the user can do", with activities serving as an orchestration layer, determining what fragments are visible in what circumstances.
The documentation will not in all places be updated to reflect fragments, and even if it does, it will take some time. For the balance of 2011, at minimum, you will need to perform your own translations of 2008-era instructions to convert them to 2011-era fragment-based UIs.
Lets say now I have to adapt it to Fragments and large screens... and that I don't want to create a second application, neither have two completely different logics (one for phones other for tables) inside one application.
I have no idea what you consider "completely different logics" to be. In a fragment-based app, most of your business logic will be in the fragments themselves. The activities, again, serve as an orchestration layer, determining what fragments should be visible and coordinating event handling. The latter will get a bit more complicated than it used to be, since sometimes clicking on an item in a list will bring up a new fragment and sometimes clicking on an item in a list will start a new activity, depending on screen size.
Or am I missing something?
To be honest, you are missing enough concreteness to your question to make it reasonably answerable.