I'm working on an Android app having an always visible tabbar.
However, each tab potentially contains many nested "screens".
Of course the back-button needs to handle this correctly.
I've now spent most of the day finding out what's the best architecture to achieve this.
There are also several similar questions on stackoverflow, but I couldn't really find an answer working for me. Two proposals I found and tried out:
switch view, see here
work with ActivityGroup, see here
Another approach I thought about is just implement all "screens" as normal activities and have them all have their own tabbar (but looking the same, so for the user it doesn't change).
I've seen that should be possible without too much redundant code by using include statement in layout xml and maybe create a common base class "CustomActivity" which configures the tabbar.
However since I'm not yet experienced with Android, I wanted to ask here before spending more time with try and error style.
Is this an approach which makes sense? If not, what would be a better solution?
Btw: The proposals mentioned above didn't work for me mainly because with neither the back button worked for me.
Thanks for every input!
Use Fragments API, ActivityGroup seems to be deprecated.
Related
I can't seem to find an answer for that. How many fragments can an app have, or how many xml layouts in general, before it starts getting cluttered and slow? All I found was that with too many nested layouts the activity itself performs worse.
Yes, theoretically it can. But it's not the number of fragments which can make an app slow, it's the way you use them. Even 2 fragments, if badly used, can make an app slow. On the other hand, tens of fragments could be handled fine. If your app instead needs 50, or 100 fragments, unless it's a really complex app and you're on top of it, then it's a good indicator that you're doing something wrong, either in the app flow, or the design. Android Studio provides you very good tools for profiling an app, use them, see where your bottlenecks are, and fix them. Measure the improvements before and after the fix.
No, there is no limit on making any number of fragments in Android app. And it does not harm any app if you make hundreds of fragments. But the way you are using those it DOES MATTER. As far as the matter of nested layout is concerned, yes it all depends upon your hierarchical level. Suitable approach should be used. Obviously not all layouts you will be showing in your activity. On depends or in certain conditions you will be using different nested layout. If this is the case then you can use fragment for dynamically update the UI or the Activity or Secondly you can dynamically add the views in your activity on demand. All at once if you are going to show complex nested layouts and those are in deep as well, this can cause sometimes some jerk or flick to load.To overcome this, You need to first think about weather it is necessary to load all the views else load on demand. Hope that helps you.
Is there any way, specifically in android studio, to see what one's custom dialog would look like without actually running the application? It seems that the Design view of layouts account only for entire-screen designs. It also seems that sometimes the way the "dialog" looks in the design view is wildly different than the way they look live.
I would share some of my code, I know you guys love that, but this isn't exactly a coding question, is it?
You can use third party tools and mirrors. I think the closest you can get is by checking this out.
This is hot swapping in general and you get interactive previews but like I said it is the closest you can get. I haven't worked thoroughly with it but I think this should be what you are looking for.
I am developing an application for tablet which has Split screen functionality,as we see an Gmail Application. My Left layout is fixed and my right one will change as per the buttons clicked on it.
I googled a lot for the solution,I found that we need to use Fragments for performing these.
Can anyone help me in solving these things.
Thanks
You could have explored d.android.com but now I would suggest you to refer it whenever you are facing problems/issues or looking for basic help.
Now, As you want to provide split functionality kind of UI in Android, check: Building a Flexible UI and I would suggest you to learn and explore Fragments.
Yes, you got that right. Fragments is the solution here. Using Fragments is easy and it's lifecycle is similar to that of an Activity. First get an overview of what a Fragment is here. Go over some of the tutorials about the use of Fragments : here and here.
this is a working example of what you want to achieve, good luck!
https://github.com/Jachu5/Android-UIprojects/tree/master/FragmentSplitedScreen
I'm wanting to extend both a MapActivity and a FragmentActivity. I know Java doesn't allow multiple inheritance, so how do I do this? I've read something about a 'composite' type, but I've never implemented one so I don't know how to go about doing that.
Someone else HAS to have run into this before, how did you solve it?
EDIT: The reason I want this is because I have 3 activities in tabs; a map, an image gallery, and a settings list view. The code for all three of these "acitivities" is inside one big MapActivity called "Main". Yes I know this is ugly, and not good programming practice, and I don't remember why I wrote it this way. I think it was because I was reading most people recommended NOT having separate activities for separate tabs... which if I decided to split them into separate activities, I wouldn't have this problem anymore.
I have no idea why you would want such a thing, but I suppose the easiest solution is something like ActivityGroup, something similar to how TabbedActivity works.
I ended up solving this by going in and modifying the source of the Android support package and deploying my app with that. Outlined here, all I did was make FragmentActivity (android.support.v4.app) extend MapActivity. I don't think the reverse works... though maybe, and it would require you having the source of the mapping library you're using (in the case of Google Maps - no go)
I've been working on a app for the past month which basically consists of a TabControlActivity with a few ActivityGroups within this Tab.
I decided on using ActivityGroups basically because my knowledge as far as Android programming goes is very limited and at the time I had no clue that you're "supposed" to use Fragments for these things(Making sure that the tabwidget persists even if a new activity is started)
Now, Using ActivityGroups has forced me into doing things I really didn't think was needed. These are the methods I feel like ive been forced to implement in each ActivityGroup to make the application act the way I wanted it to.
I hope I've been able to pain a pretty good picture of my project. What I want to know is how much "effort" and recoding it would take to switch into using fragments instead of ActivityGroups.
Your question is not narrowed down enough. But from whatever I understood, this link might help. It says move the code from activity's callback methods to corresponding Fragment's callback methods. Thats a good way to start.
Good luck.