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
I'm trying to figure out how difficult it will be to design the UI of my app in React Native. One of the main UI components I want is a sort of deck of cards that can be scrolled through (vertically) and selected (to display more details for the card).
A good example of this is the app switcher in plain Android
(See here: https://www1-lw.xda-cdn.com/files/2015/04/android-lollipop-recents-carousel-100526174-large.idge_.png).
I just want to know:
Is this feasible in React Native without a TON of effort?
If anyone has an idea about a general approach to this problem
Note: this should work on Android and iOS (the specific versions don't matter much - they can be fairly recent).
Yeah, it is fairly simple. My first approach would be to render the items on top of each other, and use each one as a panResponder controlling the scroll of the entire deck on vertical movement. Using some math to position each item individually, you can make sure they move in a similar way (When on the top, they scroll very slowly, and as they approach the center, they scroll much faster). Making sure only to render around 6-7 items at a time (the ones that are visible), you shouldn't have many performance issues.
I would definitely recommend, if you don't have much experience with Animated and PanResponder, to practice some simpler examples until you get the hang of it.
This isn't hard. If you are familiar with these, it'll take you maybe a couple days max to accomplish this.
I'm creating an app that needs to display a table, with say, 30 columns and 30 rows. I want the user to be able to use swiping to move around the table/spreadsheet. The idea is that probably the entire table will not be visible on the screen, and if it is, it will hardly be readable, so there will have to be some max-columns-on-screen value. Each cell in the table must be capable of being a different color than the rest.
So far, I've looked into TableLayout. This doesn't seem to support different colors or swiping... actually, it does support different colors via .xml, but this isn't changeable at run time, and seems like it would be very messy anyway.
WebView looks to be an option, as I am proficient with HTML/CSS but can't find many resources about creating HTML and CSS content on the fly with android - only loading it; although I can imagine writing a file with the data and then loading it, and deleting the file. Not sure if any of this is good performance wise.
What direction should I head, before I start heading in the wrong direction? :-)
Yes, it is possible (and not difficult) to support different colors and gesture in the tablelayout rows.
I think it is always a wiser choice implementing the native components, once it has a better performance and it has a better layout adjust to different android versions.
Either method can solve the problem, so it's a judgment call based on your goals and requirements.
On the plus side for Android native views:
They are pre-compiled and easier to parse than HTML, so they will load faster, scroll more quickly, and require less memory.
If you intend to write a lot of Android apps you will need to learn them.
If you took this route, a typical approach to draw multiple columns would be a ViewPager with sliding tabs. See for example the Google Play Store app.
It's not the case that coloring native views dynamically is impossible or messy; it's not hard at all but it takes time to learn how, which brings me to the plus side for HTML/webview:
A programmer with expertise in HTML will solve problems faster by just using HTML.
Layouts designed in HTML for an Android web view can be re-used on other platforms.
Again, it's not really hard to load dynamic HTML into a web view. There are a few tricks you will need to learn but that's it.
I'm quite new to the world of Android development, and I'm relatively comfortable working with Adapters and GridViews. However, I'm looking to build something a little more advanced with GridViews that seems to be proving quite difficult without using third-party libraries (impossible from what I've read). Even using a third-party library like Etsy StaggeredGridView (https://github.com/etsy/AndroidStaggeredGrid) I can't seem to get it right. The best I can get is having rows that bleed into other rows, Pinterest-style, but what I'd like is something along these lines:
Where every nth cell actually has the width of two cells and offsets the grid.
So what I'd like some direction on is:
How could I accomplish this repeating pattern using a GridView/ Adapter combo?
Or failing that, how could I do this more efficiently than nesting a bunch of LinearLayouts inside a ScrollView and doing some really messy logic?
You can't. GridView has no way of merging columns like that. You can try using a GridLayout or TabletLayout to obtain that look. However neither support an adapter. You're best bet is to look for 3rd party libraries.
If there isn't going to be a lot of scrollable content, I'd go with (Grid/Table)Layout. You may take a small hit with memory consumption but you'll save yourself a lot of time in implementing your own custom solution. Which just may be your only choice if no 3rd party library exists.
One possibility would be to looking into RecycleView. It's a new view coming out with Android L that will also be in the support library. It's basically a more advanced version of a ListView that allows you to build customizable layouts that scroll and recycle their content. From the looks of it, it appears it would allow you to build an easy solution for your case.
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.