I have a time recording app which consists of two activities. One for managing the projects and one for time record manipulation.
The core of both activities are views I draw on my own. TimeRecord activity has a self-made calendar and Project-Activity has a TreeView.
Yesterday I started to play with the DrawerLayout. Everything works fine but I'm a bit unconfident because I had to merge all my code that was split in two activities into one.
I guess it's the easiest way to post some screenshots so that you can get a clear understanding of my app and I don't have to write many more paragraphs that describe how my app looks like :P
First the timerecord activity.
Second the open drawer with the former projects activity.
I already tested it on my devices (even older ones) and performance seems still to be ok. I just feel a little unconfident because now my activity has grown up enormously (same thing for layout-xml file).
Can anyone share his experience with me.
Cheers,
Stefan
You could split your Activity into two Fragments, one fragment with Tree and second fragment with calendar. This would be better option and you will be able to reuse fragments later.
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.
My doubt is why we choosing fragment over activity even i too read that it is reusable i has its own life cycle etc etc. But as a beginner its quite difficult to work on it . Then i Have an another doubt to so far what i did in my project is i have only two activity one is for login and another one is for navigation drawer and action bar rest of things are all fragment which comes under activity 2 is it right way to do with or am making mistake . Many fragments are coming under activity 2 like multiple fragment inside a fragment is it right way it may be dumb question as a beginner is quiet difficult to understand for me can anyone clarify my doubt
Fragments were invented for tablets in order to combine several fragments on one screen. Most commonly they are used in master detail relationships. Look at this question from this point of view. Does it make sense to put two fragments on one screen? Are they connected?
Read this article one more time to clarify when fragments are needed. http://developer.android.com/guide/components/fragments.html
1) You don't have to use fragments if you don't feel they are necessary for your application.
2) Having multiple activities is fine. Most applications do.
3) Having fragments inside fragments is permissible, but you should just be aware that it can cause odd behavior in your application if you are not familiar with the lifecycle events.
4) In the Android Dev Summit (2015), a great overview of a sample Android architecture was presented, I encourage you to view it: here
Hope this helps to clarify things some.
I have read the documentation and some other questions' threads about this topic and I don't really feel convinced; I don't see clearly the limits of use of this technique.
Fragments are now seen as a Best Practice; every Activity should be basically a support for one or more Fragments and not call a layout directly.
Fragments are created in order to:
allow the Activity to use many fragments, to change between them, to reuse these units... ==> the Fragment is totally dependent to the Context of an activity , so if I need something generic that I can reuse and handle in many Activities, I can create my own custom layouts or Views ... I will not care about this additional Complexity Developing Layer that fragments would add.
a better handling to different resolution ==> OK for tablets/phones in case of long process that we can show two (or more) fragments in the same Activity in Tablets, and one by one in phones. But why would I use fragments always ?
handling callbacks to navigate between Fragments (i.e: if the user is Logged-in I show a fragment else I show another fragment). ===> Just try to see how many bugs facebook SDK Log-in have because of this, to understand that it is really (?) ...
considering that an Android Application is based on Activities... Adding another life cycles in the Activity would be better to design an Application... I mean the modules, the scenarios, the data management and the connectivity would be better designed, in that way. ===> This is an answer of someone who's used to see the Android SDK and Android Framework with a Fragments vision. I don't think it's wrong, but I am not sure it will give good results... And it is really abstract...
====> Why would I complicate my life, coding more, in using them always? else, why is it a best practice if it's just a tool for some cases? what are these cases?
I am sorry if I wrote too much, and thanks for your time. I hope I will get your attention, because I really need ideas and experiences about this topic.
Best regards, Ahmed
You shouldn't always use fragments. Fragments have their uses, such as when you want to page in and out parts of the screen or when you want to drastically change the UI in different orientations. When they make sense, use them. When they don't, skip them. I find they make sense in maybe about 10-20% of apps- I rarely see the need.
If there's a certain positive aspect apart from the simpler reuse of logic through different layouts, it's the ability of Fragments to be kept alive by the system at orientation change, aka while an Activity is reconstructed from zero, a Fragment can retain its instance, and therefore using them is more stable than an Activity. Also, switching between Fragments is quicker.
Personally, if I don't need to mess around with different orientations and layout sizes, I still prefer using Fragments and a singular container Activity around it, for stability and seamless switching between the different screens.
Its quite a general question and not directly related to a specific programming problem. But in my opinion good software is based on good design and therefore a good understanding and best practices. So your question is a good one for stackoverflow.
So, what about fragments. It took me a while to understand why you could or even should use them. As #pskink said, you can easily live without them. But if you are planning to rollout your software on different devices, you should definately think about fragments.
The screen resolution and density is not the only problem. Think about a smartphone. The screen is much smaller, so you can not present your app the same way as you can on a tablet. For instance a master detail flow. Left side, a list of elements and when you click one element, you will see details of that element on the right side. Easy to do on a tablet. But on a smartphone you would put the master-view into one fragment and the detail-view into another one.
You got two options to realize that scenario. Either programm different activities for smartphone and tablet but because they are actually doing the same logic, it's better practice to put the logic into fragments and reuse those fragments in two layouts (phone/tablet).
In an Android app, I have two screens* the user sees, one for preparing a query and the other for displaying the results. The right UI here is to have the query preparation in one screen, and then see the result on the second screen. Since this app is aimed at phone users, there's no need to display the two at once.
The traditional Android way is to use two activities, a QueryPreparationActivity and a DisplayResultActivity, and switch between the two. However, I've been hearing more and more about how the Android UI is switching to fragments. I can implement the two screens as two fragments and have the activity switch them, but is it worth the trouble? I will essentially be reproducing the Activity management code Android already has.
Is there a reason to use two fragments here?
*I'm using the term screen, because it isn't necessarily an activity...
Personally, I always develop using Fragments.
But the best reason I can give you for using Fragments is when you develop for handset and tablet devices you get a lot of reusability.
I know you already mentioned that there is no need to show both screens at once. But say later you were to develop the same "screen" for a tablet device and realize that the preparation screen is too barren and want to have both queryprep and display result show at the same time, you would have to write a totally new 3rd activity.
If you used fragments, you would reuse your 1 activity and 2 fragments, and that activity should be coded smart enough to determine the size of the screen and show the proper layout.
Code Reusability & Flexibility are the buzz words here.
If you have any questions please leave a comment and I will expand my answer. If you like my answer, please upvote and accept.
Fragments were introduced encapsulate UI elements and related behaviour into a single, reusable module. Before fragments you had to re-write the much of the same code that 2 or more activities had in common especially if you couldn't find a good approach to abstract the UI/control code into a super class. This was further complicated by the limitations that activities only call setContentView once. So sharing some code between activities wasn't all that nice.
Now, to answer your question, it all depends on you. If you think that further down the road you could use the QueryPreparation or DisplayResult ui as a module (layout and logic behind it) then go for the fragment implementation. It could be a different layout for landscape view on phone or if you decide to support smaller tablets like the nexus 7. If you are sure that it will never happen then stick with activities. Personally, I use fragments everywhere and they are a sure way to "future proof" your implementation for reuse down the road.
In short Fragments were introduced to accommodate the emergence of tablet/large screen devices and allow developers to create applications that will run across a wide range of screen sizes with very little change to code.
More can be read here at the Android Blog. That blog also details some of the finer technical details for the reasons for the move toward Fragments. Also introduced at Goolge IO 2012 were DialogFragments which you should consider using instead of Dialogs. Another blog post here describes them.
You're better off getting used to using Fragments and DialogFragments from the get go as this is the way Android is moving. Only use individual Activities if you really really need to do a quick-and-dirty app for say testing purposes. Fragments, in my opinion, do require a bit more code-work to incorporate and to initially get your head round but it's worth the effort.
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.