Regarding Android programming,
This question has been bothering me for a while, should I inflate layout as much as possible or should I programmatically create the layouts as much as possible?
If we put "convenience" aside which is better? faster? safer?
Any concrete inputs are greatly appreciated.
Regards,
I see, so inflating is the Google/Android recommended and conventional way of doing layouts
Yes.
and it doesn't slow down the runtime of the application by much
It doesn't slow down the runtime of the application by much when compared to doing the same work yourself in Java.
Because I read somewhere on the developer site of Android that it is a slow process and views should be "reused" as much as possible before resorting to inflating.
Recycling views in an AdapterView -- the most likely place for you to have read that advice -- is important, because recycling views is faster than creating views, no matter how those views are created. Again, the comparison is not between inflation versus rolling your own Java code, but between inflation and not creating new views.
should I inflate layout as much as possible or should I programmatically create the layouts as much as possible?
Inflate, please.
which is better?
Inflation takes into account resource sets (e.g., different layouts based on screen size and orientation). Inflation takes into account overrides of styles. Inflation works better with tooling.
faster?
There are probably some scenarios where hard-coded Java is faster than inflation, just as there are some scenarios in which hard-coded assembly language is faster than C. In most cases, the speed difference is not important enough to warrant the hassle.
safer?
I do not know what you consider "safe" to mean in this context.
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.
I am a junior developer and I am somewhat puzzled about writing xml layout files.
There are many implementations for the UI layout of the same style, RelativeLayout, LinearLayout, RelativeLayout And Linearlayout, and so on. Different implementations have different nesting levels. We know that there are as few nesting levels as possible, and that LinearLayout is used instead of RelativeLayout for the same number of layers.
But careful analysis, how do we measure the A implementation of a layout is better than B, two layers of nested LinearLayout really do not have a RelativeLayout to save performance? How to determine this? By experience? But where does the experience come from? It may be a good way to read the source code, but it is more difficult.
I think it is possible to find a good way of writing by analyzing the rendering time of an xml layout file and comparing the time spent on different implementations.
So I would like to ask everyone, is this a feasible way?
I'm not sure about, how we check the rendering time. But check below URL's one after one it may help you to understand more about rendering and performance related.
1) https://medium.com/#elifbon/android-application-performance-step-1-rendering-ba820653ad3
2) http://adavis.info/2015/03/android-overdraw-what-is-it-and-why-should-you-care.html
If i find any way to check the rendering time surely will let you know.
This question has been bugging me for some time. I've already developed a couple of apps on the Android platform and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable? Or should XML files be the go-to approach? I usually find XML a more tedious approach and often, these layouts don't look the same on all devices. I just don't get it. From a professional viewpoint, has anyone really been able to develop apps with complex views purely using XML files? This question is killing me because Google recommends using XML but the UI never looks the same on all devices unless done programmatically. Or am I doing something wrong?
Note that I'm referring to Android 2.2 and 2.3, which majority of the users use.
I use XML layouts on pretty much every fragment and activity of every app I write. I very rarely see any need to create Views dynamically, tho configuration of ListViews, showing/hiding views, etc needs doing in code. For me the advantages of XML are:
Ability to use layout editors (Eclipse)
Easier to preview layouts
Possible to benefit from auto-localisation of layouts
Easily maintain different parallel layouts for difference devices (screens)
Can get a sense of the layout by looking at it (easier than code)
Easy to break layouts down into pieces (fragments, includes, etc) to remove duplication
Keeps a separation between the visual design, and the functionality behind it
I can't think of any good reasons to put all my layouts into code - that sounds like hell.
I expect the reason your layouts don't look the same is because your XML is not defining the layouts correctly. Bear in mind the Android tools convert XML layouts into code, so there's no inherent problem with using XML layouts versus dynamic - both end up as code.
OckhamsRazor,
The answer very much depends on your needs, flexibility, and knowledge. The first thing to understand is that every Layout, whether created via XML or programmatically can be tweaked specifically or made to conform to many screens via properties.
... and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable?
Yes, it is. Android makes those available so you can do just that. However, the benefits of managing layouts via XML include standard MVC segregation, simpler debugging, and an easier time modifying the resource, if needed. Additionally, you may maintain multiple copies of Layouts depending on device configuration easily.
... has anyone really been able to develop apps with complex views purely using XML files?
Absolutely! There are some amazing programs that fully utilize XML rather than programmatic views. The key to them is how much information (that is non-standard view properties) is required from parental Views. Even in those cases there are ways to pass that information provided you know where and how to do so.
Or am I doing something wrong?
I don't think so. Honestly, I've run both ways depending on need. I'd say it really comes down to your lack of knowledge of the quirks. But the job is to get the job done. Here's an example: There are some times when I don't know how big everything needs to be until its run on the device, and there are times that I make the device conform to my layout's needs. Ultimately, I use the following chart to make my determinations.
Do I need information from parental Layouts that is aside from view properties
Do I need to dynamically size more than one element independently.
Is the View type pre-determined or will it change as well?
If the answer to 2 out of 3 of those is "yes", I will use some level of programmatic layout. If not, I will go pure XML. That being said, programming is one of those professions that encourages ingenuity (provided it is safe) and nearly anything can be accomplished in any number of ways. Ultimately, I'd say do whatever makes your job making quality apps easier.
Google makes its recommendations based on their own knowledge of software programmers and their general practices. They also created the platform, so they know which things are optimized in which ways. Its all about experience and we all have our own. If you have trouble utilizing XML, its worth taking the time to figure out the quirks simply so that it is another tool to utilize. Also, it will give you the information you need to answer this question for yourself.
To sum things up: I could say chocolate is better, but if you like vanilla, you'll disagree. Be aware of the drawbacks and benefits of each and take the time to learn how to accomplish the same tasks with both methods. It will make you a better programmer and give you a better sense of when to use which technique.
Hope this helps,
FuzzicalLogic
I typically do a lot of work with highly customizable UIs, where large portions of it need to be done in code. That being said, wherever possible I try to use layout fragments and inflate them, so as UI sections are added, removed, or rearranged I'm still just doing some of the layout, not all of it.
That being said, it's not that hard doing layout via code. The big advantage to it is compile-time checking. I'll find issues that way faster than using the preview pane. The preview pane can be nice for initial layout, but I use the Hierarchy Viewer for figuring out why my layouts don't look right.
It really depends on what type of project it is, or piece of a project, and what type of programmer you are. Some people just prefer pure code, while others like leaning as much on other tools for design as possible.
XML definitely has some benefits, like being able to switch between interface designs quickly. For specific design themes that are repetitive, is definitely useful for most programmers.
I personally prefer doing everything programmatically, and it is quicker for me to develop than writing XML, with the libraries and classes I have created. XML is quicker straight out of the box.
As for performance, there really isn't a difference worth mentioning unless you are using the same view so repetitively, at the same time, to the point that it no longer fits on the screen many fold. I did a test of how many text views Android could render on a Moto X - Android 4.4, and it couldn't get much over 5000, but there is never a purpose for that. If you are at that point, you are either need to dynamically load and unload data or are just doing something very wrong to begin with.
So learn both sides of it, definitely get to know the pros and cons with your style of programming, because there is no right answer for everyone, and let loose and have fun.
It is much better to separate the layout and put it in the xml file. I occasionally have to adjust the layout in code, but it is always an exception and only when I determine that it cannot be done in the layout .xml. If you use the layout views correctly, the application should look very similar on all devices.
I am looking to create a common header for an android activity and have 3 possible ways to solve the same. I would like to know which is the best solution in terms of performance and memory usage.
Copy the XML across all XML Layouts : I believe this is the least impressive solution which uses a lot of memory
Create a custom HeaderView , which I can then use where needed. Drawbacks : it still creates a lot of instances.
Use <include > to include an XML component , not sure how it helps performance and reduces memory usage.
So which method is the best , or is there a better way?
I think you are worrying about the wrong thing. Pick the one that's best for your project with regards to development or maintainability. Remember that Views are all part of ONE activity which would be visible to the user at any time, per the Android activity lifecycle. Its the framework's responsibility to clean up non-visible activities if there is a need to garbage collect. If you are concerned about View performance, look into using Hierarchy Viewer which comes with the SDK to flatten your views.
The third way looks like a good candidate... the performance difference among all ways of doing it is not big. On the other hand, the maintainability difference it's. So, the third options allows a cleaner solution since you won't have boilerplate code, and will allow you to easily change the header in the future without having to modify the other views.
The second solution is nice, but it introduces unnecessary complexity. Are you going to use more than three activities with that header? Are you going to share that HeaderView or reuse it in other project? If no... then it's not worthy. Even worse, it will make you write Java code, which is less maintainable than a few lines of XML.
In my opinion I would go for the 3rd one although its make no difference in terms of memory but it will make the code more cleaner at-least for xml. I might be wrong but thats just my opinion
I ended up using step 2 and setting my header object to null in onPause and resetting it in onResume , that way the garbage collector could free up the resource. Thanks #Morrison Chang :-)
I've seen that some Android devs promote this form of declarative layout:
<TextView style="#style/my_textview_style" />
i.e. that pretty much all the attributes (including the ID) go into the style definition. It certainly makes for shorter layout files, but is it a step too far?
What would you recommend goes in the style definition, and what should stay in the layout, and why?
I've started doing Android dev this year, but have prior experience of development. Issues like this are so important, the "way" we use the tools, the habits, to be more efficient. I appreciate you sharing your views on what works for you, for clarity, for efficiency, for maintainability, for app reliability.
I've pondered this very question and it becomes much more pertinent when dealing with multiple device sizes and densities.
Putting too much information into the styles can limit their use, especially when dealing with landscape and portrait layouts. For example a landscape layout may in fact be wholly different in composition but require very similar styles.
In these cases it helps to use the . notation to ammend style differences, for example.
<MyPage>
<MyPage.portrait>
<MyPage.landscape>
See below for information on the above approach to creating styles.
http://developer.android.com/guide/topics/ui/themes.html
MyPage defines the common properties for your layout and you then override these values in the portrait and landscape extensions.
I..e you might have more right and left padding in landscape than portrait.
The problem i've found is that the themes and styles xml files get huge, especially if like me you have many activities, and if you address lots of creative changes then you can end up with lots of messed up definitions.
At this point you have to take stock, tidy up and re-factor.
My only advice is that you plan really well upfront. Define a naming system that accommodates your project, write it down and stick to it.
Possible style naming convention
<section>_<componentName>_<componentType>_<orientation>
home_leftPanel_btn_horizontal
home_leftPanel_listview
home_leftPanel_listview_horizontal
A similar approach to themes should be adopted.
I'm still working this out, so can't give fuller examples.
Pushing those things out into the style is a good practice if you plan on skinning your application differently. If you plan on releasing two versions with just a different look then by all means push those into a style. As you say it cleans up your layout files quite a bit.
Should you push IDs into styles. No because IDs are the hooks by which you're code will grab references to those objects. I can't see much of a point to always having your program externalize IDs. So I'd say that practice is going too far.
Now should you do this every time? Well I think that really depends on if you think you need the benefit this brings to reskin the application. Some people can't say no to a good idea, and try and do every good idea all the time. While that's admirable it's not productive. Experience is knowing what good ideas you need and what good ideas are just fluff for this application your are working on right now. To keep ourselves productive we need only the good ideas that make us move faster, and all other ideas are just art. How do I choose? Refactor, refactor, refactor. Do it fast, then refactor to clean it up based on the next requirements I'm working on. Do it fast, then refactor. Repeat until my boss smiles.