I have one doubt and want to clear some points regarding the Activity holding multiple fragments.
I have 10 fragments attached with one Activity (HomeActivity.java); this activity contains one navigation drawer and tool bar with multiple icons like search, add, remove, back button etc.
The structure which I am following is below,
User clicks any item from navigation drawer, I am loading the fragments,
fragmentManager.beginTransaction().replace(R.id.fragment_container, fragmentToLoad, tagFragment).addToBackStack(tagFragment).commit();
fragmentToLoad -> fragment name, tagFragment -> tag to that particular fragment.
I am changing the title name, toolbar based according to the fragments in HomeActivity itself.
My navigation drawer items are having one fragment only and get replaced in fragment_container but one thing is also there, that these fragment are also having inner sub-fragments too.
In the start, I said that there are 10 fragments, those 10 fragments are navigation drawer items. There are many inner framgents.
Now, the inner fragment's click listeners and other activities I am maintaning in HomeActivity.java itself using interfaces(Listeners).
SO, some times I am getting warning "There is a lots of work going on main thread".
I understand that there is lots of activities going on HomeActivity.java.
Please tell me this architecture is wrong or is there any solution.
I wouldn't say that your architecture is WRONG. Instead, I would say that by using single central activity to handle so many fragments, you are making maintaining and debugging that activity very difficult for yourself.
As far as the warning message is concerned, it depends upon the number of frames skipped (something that is printed before 'There is a lots of work going on main thread' in the log). I believe if the number is ~ 100 then it really shouldn't be a matter of grave concern. Kindly go through this SO answer for complete explanation! Hope that helps.
Related
In order to have a persistent toolbar in my app (I want to animate/morph the icons on the toolbar when switching to a different screen), I used an architecture which consists of 1 activity, 1 toolbar and a main fragment, which gets replaced as needed.
In order to create proper navigation (including the device's back button) I need to let the activity (and/or the toolbar) know which fragment is currently being displayed.
I was thinking of creating a private Integer ArrayList - could be called fragmentNumberHistory - which stores the history of the fragment order displayed with the last being the current the number of the current fragment, simulating the back stack a little bit, only for "fragment id's".
Question: although this strategy seems to work, it feels like an unclean work-around. Is there a textbook way to implement this? I would have thought one could ask the FragmentManager which fragment is currently being displayed in a specific container but that doesn't seem to be the case?
I would recommend you to implement an interface to manage backstack.
Here is a good blog post which would help you understand this process
I know it was answered before but I am still confused, if I should use fragments or activities for navigation drawer.
What is better practice? Google does not say anything about it and I am a little dissapointed.
Also, if I create a new project from Android studio with navigation drawer template, what I get is one single activity and one single fragment, but there is also separate fragment for navigation drawer and inside it, there is an interface and above it is a comment saying: "Callbacks interface that all activities using this fragment must implement.". It confuses me even more because I think I should use activities, but I am not sure.
I will keep it very simple: When you switch between activities , user has a bit of feeling as if we are taking him to another view(as if we are making him switch somewhere and the whole view is changed with a sudden blink) but when you do same stuff in one activity and changing views through fragment, it is very smooth. Moreover passing data from one fragment to other is very easy and less expensive as android says activity transactions are expensive.
Yet many times it depends on your requirement.
Keep in mind that a nav-drawer can be used for different user interactions. By the common usage as a navigation element, you will implement it by fragment(s). In this approach the drawer is placed on the left side.
An other approach can be to perform actions by pressing an drawer entry. In this situation you wont replace any fragments and only implement the drawer to the activities which should be able to perform this particular interaction (maybe: "send contact per a email")
There are few similar questions on stackoverlow, but I haven't find clear explanation at any of the answers how to implement Action Bar pattern for more complex/multiple activities apps.
As I understand, there are two options to do this:
1.) implement multiple activities and in each of them implement/include action bar
--> problem with this is that when ever you lunch new activity, although it has the same looking action bar, it has that transition, and jumps through the screen, so it's obvious it's a new "window",new separate screen, and it kills that feeling of single app navigation frame.
2.) Use single FragmentActivity, with action bar within, and with multiple fragments that inflate content frame.
--> this is pretty nice implementation of action bar pattern, but problem is that it goes against google's recommendation that one fragment should be in one activity in the case of phone. Or it doesn't? From the "look and feel" I would say that Gmail app is done mostly this way.
3.) TabActivity - which is deprecated.
For the second solution (single activity, multiple fragments) I'm concerned if there would be any performance issue in the future? How does android handle memory in that case? will it kill inactive fragments to free space just like it does with the activities? Or it will kill the whole app, or user phone will be overloaded?
Maybe I'm missing something there, but I found implementing android navigation patterns and usage of fragments very confusing :/
Is there any reason against having one activity with multiple fragments on the phone?
(there would be cca 5-6 fragments, with nested fragments in some of them)
First of all, you might think this question and this answer to be useful.
Though you are talking about the actionbar, the real question is about the pattern of ONE activity with multiple fragments or MULTIPLE activities. As the former link states, though the "oversimplified tutorial" suggests of starting another activity to display item's content in Phone situation, this will probably cause some duplicated logic or codes.
Finally, using "FragmentActivity with multiple fragments" is recommended. As it is against the the google's recommendation, Stephen Asherson says and I quote: " do not think of it as being forced to use many activities. Think of it as having the opportunity to split your code into many fragments, and saving memory when using them".
PS. just for your information, if you change the activity's actionbar in switching fragments, you might want to do something to correctly handle the UI change when "back" key is pressed and backstack is changed. Commonly, override the onbackstackchanged() function to handle the UI.
I have seen a few questions raised on this topic (for e.g.: https://github.com/jfeinstein10/SlidingMenu/issues/5) but I am still unclear. I hope somebody can clarify this.
Context:
See https://github.com/jfeinstein10/SlidingMenu
I have an android app that organizes screens by activities and fragments (i.e.) each screen is an activity containing one or more fragments.
The new requirement is to add a sliding menu (similar to what this library provides).
Issue:
It appears from the examples and discussion that the right model would be to have just 1 MAIN ACTIVITY that will then switch in/out fragments belonging to the different screens. In fact the author mentions in the above thread: "If you were to launch Activities based upon the list selection, then you would not have the behavior where you swap the views that you're talking about. " and also "You can't put an Activity into the above view. That doesn't really make sense when you think about what an Activity is. ".
Why doesn't it make sense? Obviously, I am missing the point here.
Question:
Given that my project already contains multiple activities (one corresponding to each screen), is my only option then to re-organize the project to have JUST 1 MAIN ACTIVITY, in order to use this library? Or alternatively, is there any way to launch a new activity when a list item in the sliding menu is clicked, and still observe the sliding menu behavior, [EDIT- added the last part to be more clear] or in other words, on how exactly to use this library within my existing app design.
Thanks in advance
First, you can't have an Activity inside another and activities are completely different from views as stated in the docs:
An activity is a single, focused thing that the user can do.
Now, to answer your question, it all depends on how you want your app to behave. You could have your activities with the sliding menu implement the onClosedListener and switch to the selected activity from there. This will give you the animation of closing the menu before switching activities. It will also give you a weird effect since every time you select something from your menu you'll see the animation of a new activity coming to the front.
I think the best approach would be to have a "common purpose" between all your sliding menu options. For example, in one of my projects I have to allow the users to select between lists of different types of data. When the user selects anything from the menu, I load a new list fragment into the right corner where he may choose the item he wants to view or edit. That's the app entry point and also the only place were I have a sliding menu in my app. It is pretty much the same for every app that implements this UI design pattern. Look at google+, currents and youtube where the side menu lets you choose which feed or content to show. Once a user makes a selection, just open a new activity for the selected item (a g+ post, a video, a news article, a tweet or whatever it is).
Your app doesn't have to have lists of different data or anything like that to use the sliding menu, but keep in mind that the activity with the sliding menu should have a clear, focused goal with respect to its functionality and purpose. Having a sliding menu because many other apps have one is a bad choice, you should use it with a specific objective. Also keep in mind that applying the sliding menu everywhere would interfere with the platform's navigation pattern and lead to an overall bad user experience since it wouldn't behave as the other apps.
It doesn't make sense to place an Activity into the above view because the Activity is the main controller for the view of each screen. The Activity also shows views and keeps track of Fragments (which in turn are mini controllers, with or without their own views). So placing an Activity in the above view would mean that you would place an Activity in an Activity... Wich is impossible.
From what I can derive from your text I think it would be wise to read through the Android developer guide on Activities and Fragment again (http://developer.android.com/guide/components/activities.html) to get a better understanding of how the concept of Android works.
Now to your question:
I am not clear on what you are trying to achieve but if you want your app, with menu to behave like, say, the Google+ app then one way of doing it is to implement a base class that extends the Activity class (or what ever base Activity used in your project) and let the base set the SlidingMenu. Then you would simple extend your base Activity in each of the Activities that are supposed to have a menu.
You could also do it the way you describe it, but then you would end up with a classic example of a God object (http://en.wikipedia.org/wiki/God_object). It's a neat way to practice your Fragment juggling skills and switching between Fragments instead of starting new Activities does have it's use cases, but I still wouldn't recommend it for a project with more then a few views.
Here is the answer that came closest to the issue I had - http://www.verious.com/article/polishing-the-sliding-app-menu/. Scroll down to the bottom of the page to see the last section titled "Using the fly-in app menu between Activities". This is one option if you have a lot of activities in your existing app and want to avoid extensive re-factoring. I haven't tried this out yet but its worth being aware of.
in my app I've launcher activity displaying summaries of different stuff. There's one SlidingDrawer set up in each activity having a dashboard with 9 menus as content. When user clicks on drawer's handle, content scrolls up to display that dashboard. These menu launch 9 activities from dashboard and there are no of activities that will be having same SlidingDrawer with dashboard.
Now the thing which is disturbing me is, I'm forced to put same code blocks in each activity that controls behaviour of dashboard. Dashboard itself is inflated from single layout. So design is not issue. But I've to attach event handlers to each button and start new activities from there. Problem is whenever I make changes I need to replicate those changes in all activities.
How can I avoid such redundant code and use a single class or something that let me define launching of those 9 activities?
Sorry for title and description. It's really hard for me to put it in words. If you find title or description not suitable then tell me or edit where appropriate.
Thanks.
This might be a perfect situation for an Android Fragment
Have two fragments for each activity, one for the sliding drawer and one for everything else.
Android fragments seem complex at first, but trust me, learning them will make your life easier.