I have to write a simple app which will look different depending on the screen size.
On a small screen it would have a list of items and after click it will display details. On a bigger screen it would have a list of items and details next to it.
My question is: should I use fragments to do such an app or just write different layouts and place them in layout-large or layout-land folders?
If it is a new app I would always go with fragments, basically for future proofing your app. You may have a single list now, but later you may want to introduce a menu for selecting different types of lists for example. By using fragments, on a phone you can use two activities, one for selection, and the other for the list, but on a tablet in landscape mode you can place the selection and list side-by-side.
Coding for possible app enhancements and features now, saves you time and headaches later.
You can do it in both way , but the suggested solution is using fragment
check this out :
https://developer.android.com/training/basics/fragments/fragment-ui.html
and this :
http://www.vogella.com/tutorials/AndroidFragments/article.html
You should use Fragments, since Fragments were created for that purpose, besides, if you make 2 layouts, you will have to do 2 completely diferent layouts and that'll mean that the activity would not handle that, at least not in an easy way, so try fragments to achieve that, the official documentation example is a case like yours, that would be enough to believe that the correct way to do it is with fragments.
Related
Lets say that in my app i have 2 screens with exactly the same views, the only thing that changes are the texts.
Whats the best way to be more efficient here?
Using the same layout with the same fragment and same VM? And handle
all the texts logic in the VM
Use the same layout but with different fragment and different VM?
For me, if the screens are 100% the same but the only thing that changes are the texts i would go with the first option but im not sure thats the correct way to do it.
I would say go with option 1 if everything is same other than string changes. You can have a flag and based on that flag you can update strings.
I am very in doubt of the structuring of my application. When to use Fragments is a big question for me still. I understand the concept of fragment, but I would like to know how more experienced programmers use them. Is it really only when there is a specific task the fragment should do?
For instance, POP-UPs, what layout would be better used?
And back to the fragments, do you usually have a skelleton fragment that can be used for more than one thing, and then reshape it to different final forms (minor changes) or would you just use different fragments if the layout changes?
You should use fragments in a few situations but its going to depend on your app really.
If you have a layout that is going to be used in multiple places and the code is relatively the same, that is a very good candidate for a fragment so you can keep code down.
If you are making an app where the layout changes based on orientation or device type (tablet vs phone) then fragments are highly recommended to hold different layouts. It makes it easier to change or show multiple layouts if need be on a tablet.
I'm sure there are more scenarios but I would say these are the basics for fragment decision
The most common way I use them is as a kind of plugin layout for my activities. Let's say I have several activities and all of them need to display an address, phone number and some buttons (call number, launch navigation/gps, etc). I pass the fragment the id and the fragment does the legwork of grabbing the information and populating fields for my activities. This way, if I need to add anything, say an email address, I just need to modify one section of code rather than each activity and layout file.
Android Studio 0.8.10
I have developed an App that has 3 fragments. I have just used 1 Activity and when I want to display a different fragment I just replace the existing fragment with the one I want to display. However, as I have 3 fragments now, and maybe more in the future, I think this will get harder to manage.
I am just wondering what is the design pattern when programming with multiple fragments, should each fragment have its own activity?
I will be scaling this to Tablets in the future, so I am not sure what impact this will have if I stick with the multiple fragments and single activity.
Many thanks for any suggestions,
should each fragment have its own activity?
Yes, but you can also use nested fragments.
I think this will get harder to manage.
you are right but
i think you must match your app with some other widget for example if you have multiple fragments that want to show one after the other use viewpager or you can use horizontalscrollview. you can create tabs and sync them by viewpager and so on.
Yeah, this can be really hard to figure out. I think a pretty good analogy, from the web application world, might be a servlet and a frame.
An Activity is like a servlet. It is one page in your app's workflow.
A Fragment, on the other hand, is like a block of content. It might appear in several different contexts and it might be served by several different servlets.
In MVC terms, the activity is largely part of the controller. A fragment, on the other hand, is more like a view include.
Much of the time, those two concepts align. A page in the workflow frequently contains exactly a single block of content. As you have, wisely, noticed, though, when you get more screen real estate (on a tablet), it is entirely possible that a single activity will display more than one fragment.
A single activity, on a tablet, might show, for instance, both a list of selectable items, and the details for the currently selected item in that list. When you have less space on the screen, though, those two things would be displayed as separate workflow items. Clicking on an item in the list invokes an entirely new activity.
The content is constant. The workflow changes.
Most modern applications will use a Fragment to display Activity content. It makes the application more flexible and easier to adapt to wildly different screens.
I'm currently developing a little application that uses a login screen and a main screen. I'd been watching how another developers had been made the screen switch, some developers adds and remove fragments on run time, anothers have an Activity for each view (in my case that will be a MainActivity with the main_activity layout, and the LoginActivity with the login_activity layout). And I don't know wich is the way to go. I think that have a fragment for each view will be the solution with more sense, but I want to listen some opinions before continue.
There might be others who disagree with me, but in my opinion, Fragments are better suited when you want to keep a part of the screen static and change something in the other part (analogous to AJAX in websites).
Activities should be used for individual views in those cases where there is only one thing happening on the application front-end.
On the other hand if you have a Gmail like layout (with static links to Inbox, Sent, etc. on the left hand side and a dynamic list of mails on the right hand side of the screen), Fragments is the answer.
But since you have two different screens for layout and main, in my opinion, it would be neat if you used different Activities for the layouts and used Intents to navigate around.
For two completely different Activitys such as Login and Main I think you want to use two different Layouts and two separate Activitys and no need for fragments. However, you may want to use fragments inside any of them as #swayam suggested depending on what you want to do inside of them. You need to look at the docs and decide which is better suited for your needs. No one can really decide that for you.
Activity
Fragments
I want to know how to chech whether object is existed in layout.
To make clear, I want to check ListView is existed in layout for different screen resolution. If client device is tablet, I'll process for ListView and will make some action. If client device is mobile, I'll ignore this ListView and set visible mode to GONE.
You should define the default (say, phone) layout in /res/layout and the tablet layout in /res/layout-w720dp or something similar. See here for more information on qualifiers for layouts. Then you have defined your different layouting in xml and don't need to jump through hoops in code to make it fit to different screen types.
To know whether object exists or not, just try to find it with findViewById and compare result to null
Disclaimer: This is a link to post on my blog (there is no advertising). I think it might help you think about the way you construct your app to deal with phones vs tablets.
http://damianflannery.wordpress.com/2011/10/16/architecting-a-single-apk-app-to-handle-phones-and-tablets-on-android/
It sounds like your intention is to hide a listView from the screen if the users device is not a tablet. This is easily done using different layouts for different as mentioned in Damians blog post.
However the new correct way of doing this is to use fragments. The basic idea is you combine the code and layout into a fragment and only use the fragment if there is space on the screen. This means that your screen would be formed of 1 fragment if phone and two if tablet, one of which would contain and code for your listView.
Fragments - Android Developer