Can anybody briefly explain the advantages and disadvantages of dynamically modifying layouts as opposed to having static layouts? I faced this question in a quiz. Please explain your answer in detail. The following are True/False questions.
Dynamically-created layouts will appear on the screen and will respond noticeably faster than static layouts will.
Dynamically-created user interfaces can adapt to an application's runtime state, such as the amount of data that needs to be
displayed at any one time.
Dynamic layouts can take advantage of contextual information that's not tracked by Android's configuration system (such as current location, usage time, or ambient light measurements).
Static layouts can't take advantage of contextual information, such as the device's orientation.
The first statement is False because the idea of allowing static and dynamic layouts isn't to improve efficiency but to better seperete the view from the model/controller and to allow changes to the layout without recompiling the code. See here for more information: Android xml vs java layouts performance.
The second and third statements are True because this is information that can only be determined at runtime so to take advantage of that you would need to create some dynamic layout settings e.g. updating a position on a map, or updating the current weather for the area you are in.
The bottom statement is False because you can have layouts in XML files that are named specifically for the devices orientation e.g. layout-land.xml. Android will correctly pick this layout when the configuration is changed to landscape.
Remember that Android allows you to use both static and dynamic layouts but from what i've read most people opt for the static layout options where possible as this separation makes changes to the layout much easier. Dynamic vs XML layout in Android?
Good luck with the course, I believe i'm doing the same one.
Cheers,
Alexei Blue.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am little confused about the best way how should I design my application. I have used XML to define the position of objects. But now when I'm developing application with more complex design I'm starting to think dynamic define of object can be more practical and suits all screen resolutions. Basically I would like to combine imageViews, ImageSwitcher, TextSwitcher etc... Now I used XML code and it has more than 270 lines and also it is very chaotic, difficult to suit to all screen resolutions and every small change will crash my app. I would like to use percentage for set positions of objects, set scale of objects etc. Should I go on with XML or is it better if I start to use programmatically way to set positions of objects. I was looking for some books or tutorial about dynamic designing app but I always found only easy tutorials can be also done in XML. Has someone good hint for some book or tutorial about dynamic designing? Thanks a lot.
Now I used XML code and it has more than 270 lines
If you have that many lines in one xml file then I think you need to reconsider your design. Use Fragments, ViewPager, ListView, etc.. depending on your needs. But I don't know how you can have that many lines in one layout file.
difficult to suit to all screen resolutions
I'm not sure how it is any easier doing the layouts programmatically. It really isn't that hard to support multiple screens. Use dp, layout_weight with LinearLayout when necessary, and other various tricks. See this part of the docs about supporting different screens. For the most part, you just create different layout folders (3-6 maybe depending on what your need)
Should I go on with XML or is it better if I start to use programmatically way to set positions of objects
It is typically easier to do your layouts through the xml. There are certain properties that need to be set in xml (can't think of any off-hand but they exist). I would only suggest doing it programattically when absolutely necessary. There have been times when I spent a bunch of time creating a layout programmatically then realized there was a much easier way to do it in xml.
The main reason, that I know of, to create a layout/view programmatically is if you don't know the number of/ what kind of Views will be used. Say, for example, if a user can press a Button to add another field to contacts. Even then you can do it in xml if you know the amount of Views available.
Make sure to go through the Design Sections of the Android Docs and you can Google design patterns, principles, etc... and find a lot of information.
Speaking from experience - the best way to create layouts is using XML. This should not break your app every time. This sounds like you are not following best practices. One of the major drives behind using XML rather than programmatic view creation includes supporting different screen sizes and resolutions, and simplifying the use of Fragments.
That aside, there was a time about a year ago that I asked myself the same question. The result was an open source library for creating layouts using Java or XML (interchangeably), and supports customizing sizes based on the current display, using percentages, etc. It is called AbLE (Annotation-based Layout Engine), and is available for download here: https://github.com/phil-brown/AbLE .
I do not currently use this library (I use XML instead), and do not currently maintain it.
In this article http://developer.android.com/guide/practices/tablets-and-handsets.html
we use res/layout/main.xml with one fragment for handsets and res/layout-large/main.xml with two fragments for tablets. We must check if second fragment is in the layout to define if app runs on tablet or on phone.
I have 4 layout (2 for phone and 2 for tablet):
layout-port
layout-land
layout-sw600dp-port
layout-sw600dp-land
I check screen orientation to define if display is in portrait or landscape mode and check if layout contains a fragment to define if it is tablet or phone.
Is there any better way to work with layouts and fragments?
Is it possible to use one layout if we have two fragments for example http://i.stack.imgur.com/FtzKs.png and if a phone display doesn't fit both of them to show only the first one?
Thanks in advance! :)
What you're showing there is indeed possible! That is something called a Master Detail Flow (if you're developing in Eclipse with adt, check out he new activity wizard, which provides this as a template option).
This layout is basically just two fragments inside an activity (or, now, as of android 4.2, they can be nested in another fragment as well!) that interact with each other in a certain way. To create the layouts you linked to, one would detect whether the device is a phone or a tablet, and then set the visibility of the two fragments in different situations accordingly.
You will find a number of methods for detecting screen size here, whether you want to use screen size in inches, pixels, or the manufacturers' default categories.
And properties like visibility and sizing can be set programmatically using Layout Params and its various subclasses.
In any particular case, whether you choose to use multiple layouts to support different screen sizes or to do more of it programmatically is up to you. Personally, I think that it is always a good practice to design your code modularly and then use layouts to put all the pieces together (it'll save you a lot of headaches down the line if you decide you want to change things up). But either way, supporting more devices will always require more code, and there are no two ways around that...one of the curses of android development :P
Suppose I have a ViewGroup that can contain several optional children views, say a VideoView, an ImageView and a few optional buttons.
Are significant resources wasted if I include all possible children views in the layout file but set all of them to visibility gone by default, but change visibility as appropriate at runtime?
Is it better just to add the views at runtime as needed? Is there another approach that would be more sensible? Fragments?
I prefer to create them all and hide them. I've noticed that a most of the built-in Android layouts I've looked at do the same. Personally, I think it cuts down on NullPointerExceptions and the checks needed to avoid them.
The resources saved by not creating a handful of views in the layout file should normally not make a large difference for the runtime resource consumption of your application, except for cases where they contain huge images or other very heavy ressources.
On the other hand, having those views in the layout file (and hiding them)
makes them much more readable than creating them in Java code
leads to them being checked by Android Lint.
That's why I always suggest to have them in the layout.
In android, we can design user interfaces by two methods: Procedural and declarative. In procedural we write code in the program to design interfaces as we do in swings. While in declarative design we do in the XML files under res folder. For example, creating button inside res-->layout-->main.xml using <Button> tag. The declarative design is more preferred method among the two.
So, my question is that why to prefer designing by declaration. How much efficient is designing the interfaces through XML's.
According to the documentation the advantage to declaring your UI in XML is that it enables you to better separate the presentation of your application from the code that controls its behavior. Your UI descriptions are external to your application code, which means that you can modify or adapt it without having to modify your source code and recompile. For example, you can create XML layouts for different screen orientations, different device screen sizes, and different languages. Additionally, declaring the layout in XML makes it easier to visualize the structure of your UI, so it's easier to debug problems. You can go through this for more.
Some of the advantages of XML layouts over Java code are as follows:
Easy references to strings, drawables, dimensions, themes, etc.
Automatic support for multiple configurations. Without changing your code you can have different layouts for landscape and portrait by just having an XML layout in layout-land/ and layout-port/. You can do the same to adapt the layout to different resolutions, languages, densities, sizes etc.
The XML code is often shorter and easier to understand than the corresponding Java code, and it’s less likely to change in future versions.
More at this link.
I'm making a new application and its basically filled with information about Warcraft.
I have similar apps on my phone that have similar information and when I looked inside their .apk they only had like 10 layouts.
The app that I am making already has 5 layouts and it seems like I will need about 50-60 layouts.
So now my question is it normal to have that many layouts? Or do I have to learn to make one general layout and keep reusing it? For example, like if I need to display information about a topic for instance the classes in warcraft which are 10 different classes with 2-3 different guide pages on average for each class, would I need to make a different layout for each page or is their a better way of doing it?
I would really appreciate any input/suggestions.
What I recommend is having one layout for every type of screen (basically one per Activity) and use Java to fill in all of the info. Use getResources().getString(int id) and pass something from R.string. That means you need to keep all of your information in a strings.xml file in your values folder (located in /res/values). List all of your views in the layout XML file and then find them by ID and set their values.
It's best to keep all of your string resources in a separate XML file and not hard code them into the layout (otherwise it's a pain to replace every instance of a word you realized you misspelled or something). If you don't know how to write XML, that's okay since there are tools in Eclipse, but I HIGHLY recommend learning it.
You can re-use layouts without any problems. In fact for maintaining the code it is a very good idea to do so. No one wants to maintain 50+ layouts and associated code.