Develop Reference

Android UI Designing - is using android studio UI editor enough?

I've been learning Android for the past few days and I'm getting increasingly confused about one particular topic - the design of the UI.
I'm currently using Constraint Layout, as selected by default in Android Studio.
I wonder how can I make the UI screen-size independent? Some people say guidelines (if so - where to insert them? What to do with them? What is their purpose? How is it different than just placing a button there?), some people say that good constraints are enough, some people say that I should use Relative Layout and make separate UIs for different screen sizes. I also have problems with understanding the whole concept of dp, it's kinda hard to wrap my head around it. What's the difference between using percentage values and using dp? Is dp screen-dependent?
Not to mention that I find it hard to understand the whole concept of resolution, etc.
What should I start with?

Start with a proper tutorial on android.
I would suggest to go through the Udacity basic nanodegree program. https://www.udacity.com/course/android-basics-nanodegree-by-google--nd803 Also my friend Google is your best teacher only you have to have the passion for it

Best practices: Layouts on Android (Programmatic vs XML)

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.

Create a Custom Android App UI

I am not familiar with creating android apps by any means. However my company is looking to have an app build up. First they would like to have someone design a custom UI for it. However most apps I use at least all generally have the same core UI look/feel which is something we would like to avoid. I have seen apps though that don't even remotely look like the rest. So I am wondering if theres any place to find out what the basic canvas of an android app looks like . Is there any PSD's anywhere for this? Not one hundred percent sure what I am looking for other than concepts at the moment, but we want to know that our concepts are at the least plausible. So if anyone knows any good resources Id be interested to know.

Not PSDs, but you should take a look at the newly launched Android Design site, especially the Building Blocks section to understand what is available out of the box for you. Pretty much all of the controls you can style pretty extensively if you're willing to put the work into it, but have varying degrees of built-in configurable styling flexibility.
Note that while there's something to be said for ingenuity and being able to stand out from the crowd, there's also the flip side of comfort and usability for the user that comes with a familiar look and feel. If you're looking to come up with your own custom controls, etc. and you're not even familiar with creating Android apps, I hope your company is willing to budget a lot of time for the steep learning curve (the learning curve of Android is not so bad, but adding a lot of custom UI on top of that is not trivial for a first project).

Prettifying my Android App? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I've been "Googling" for a while now but I am coming up empty on any decent tutorials on how to "prettify"my android app.
Currently, my android app is fully functional but all it is is a bunch of buttons,text on several views.
What options or techniques exist to make it look beautiful, other than changing the font type, size or colour. Also changing the background colour or image isn't exactly a job done.
I appreciate any guidance on this!
Update
I am not looking for a designer. I just want know how else is someone supposed to design beautiful android apps - surely its just not the XML? Is it just about making a great background and fitting everything around that?

I know the pain you're going through - I'm still coding my app but I'm also on my third design iteration. UI design is definitely out of my comfort zone but then again, it's good to push yourself into other areas, now and again, if only to appreciate the skills which the pros have. That said, check out the new Android UI patterns here and you should definitely consider things like a colour scheme, fonts and overall look-and-feel. There's another good article here by Reto Meier about his approach. Good luck.

Although it is sacrilege of the highest degree, you could sneak a peek (sic) at the UI guidelines for iPhone.
In general, there are two approaches to making a good looking UI.
The first approach is to specialise. Pick a particular resolution, set your font sizes in stone, use precisely positioned images for rounded corners etc.
The second approach is to generalise. Make sure that your layout looks 'okay' on most of the screen sizes. Make sure it still looks good when the user changes the font sizes (etc). Try to keep the graphical elements away from the text elements (e.g. you might put a graphical border around the edges of your app - whereas the specialist would have a graphic filling the whole background with 'holes' for the text to go in)
Thirdly ( generalisations are made to be broken :D ) you can make your app skinnable. It is hard for one person to come up with a design that everyone likes. But if you allow the user control over the ui elements (especially colours and contrasts) they can personalise it and achieve something that is better for them than anything you could come up with. Everyone else on the planet might hate the colour scheme they pick, but they feel that it is perfect.
Fourthly ( sorry ) you can try customising the controls. On the iPhone (for instance) the built in buttons that come with the API are incredibly ugly on anything other than a white or light grey background (their shadow is wrong) - but you have no control over the appearance of the button! You can't even change its colour. So in order to have buttons that don't suck, you pretty much have to roll your own custom control. I highly recommend looking at the Donut Games iPhone apps - they have a 'big round bouncy button' that they re-use a lot.
Don't clutter your app.
Make sure your controls are a fair distance apart. Find someone with 'fat fingers' to user test it for you (use a frozen sausage if you don't have any friends).
Keep in mind that a touch UI is fundamentally different from a mouse and keyboard UI. For starters the tip of a mouse is 1x1, the tip of a finger (according to Apple HIG (and again, apologies for mentioning Apple)) is 40x40 on the old (non-retina) displays. Presumably it is 80x80 on the new one. That means a finger is somewhere between 1600 and 6400 times less accurate than a mouse. One implication of this is that no control should be smaller than 40x40. If you were making a boardgame for instance, that would imply that (on older iPhones) that a chessboard is about the smallest your squares/hexes should get (8 across at 40 pixels is 320 pixels, the same as the phone width).
You can see this effect (a control being too small) with the default Apple info button (the i in a white circle) - it is something like 18x17 pixels, and sometimes can be quite hard to hit (sometimes you get it first go, it creates an inconsistent feel to the app). Cunning developers stick a 40x40 invisible 'panel' behind the button and delegate the clicks that go through to that back to the button.
Don't use small controls!

I don't know if this helps you as much as it helped me but I really got a lot out of this Google IO 2010 Video on UI-Design-Patterns:
http://www.google.com/events/io/2010/sessions/android-ui-design-patterns.html
If you don't have an hour to spend, just read over the slides of the presentation:
http://dl.google.com/googleio/2010/android-android-ui-design-patterns.pdf
I would definitely recommend to watch the video session though!!!
Good luck and have fun!

From experience, a good Software Engineer is not necessarily a good UI Designer. They require two different skill sets, I recomend subcontracting the design to a good UI designer. Even if all they do is a mock up and then you go back and implement their design idea.

One cannot learn desing because it is an art. For this one has to believe in onself and let it happen. There is nothing more important for desing than a positive attitude and of course, in this case, some good Photoshop and Fireworks skills...
But essentially it is an ability to visualise that matters and this is why so many games on android market just don't look good, for rare are people who are good programmers and graphics artists at the same time... yet everything can be achieved given proper attention.
Basically, my answer is: if you want to do it yourself, then you must forget that you are a programmer and believe that you are an artist, desinger and producer. Only then, from that new perspective, you can create what is needed for your product.

Should I put all Android view attributes into the style?

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.