I want to add a small type selector, which will give the user three options (good, so-so and bad).
Quickness and simplicity are the main goals.
Something like this would be great:
What type of widget should I use? (I'm using android studio)
I didn't downvote, but the reason might be that you are asking for a iOS-ish pattern, not really present in the android guidelines nor ever promoted by Google.
The common way of achieving what you want in a neat, but framework-accepted way, is using RadioButtons inside a horizontal RadioGroup. I believe there's no need to tell you how, as there are dozens of questions here and it is a pretty straightforward task.
If you really want to stick with that pattern, you could use some external library, like this.
I'm fairly new to Android and I'm working on an application in which one particular section involves a more advanced UI interface than what you would normally create with the stock UI components. I've read through most of the SDK tutorials and I get the basics but I can't see how to implement something like this. I'm not looking for any code, just some advice on what technologies I should be reading about to achieve this.
Here is a mockup:
So basically at the top there is a thumbnail strip that the user can flip through. Clicking on a thumbnail will perform some action. I'm pretty sure there's a stock control for this.
Underneath that I need to be able to create a composite image that can be pinch zoomed and panned and has hotspots that can be clicked (tapped) on. For example, an image of the solar system, in which the background would be static, but the planets need to be placed at runtime and need to be clickable, and the whole thing needs to be pan/zoomable. Support for very minimal animation (eg slow planet rotation) would be a plus, but not necessary. I'm at a loss on what I would achieve this with.
Finally, there are three pull-out panes that contain other content, such as images, menu items, and other media. Basically these just need to be containers in which I can place any other UI content.
I've done some basic Activities so far with simple forms, so I understand the basic workflow of Android, but I'm just not sure what to look at to achieve something like this. Is this a good candidate for a SurfaceView? Is there something else I should look at? I have been a bit afraid to get involved with OpenGL, since I don't really have a 3D background, and I still want to be able to use native components (buttons, listboxes, etc) without having to re-implement them in OpenGL.
Have a look at this for the slides:
http://developer.android.com/training/animation/screen-slide.html
as for the thumbnails you can use a linear layout, with some imageviews and buttons.
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 programming an android game that has a screen, which has a ScrollView that contains almost everything on the screen. I need to have image elements that move around, can be clicked on (but also be transparent to clicks in certain situations) that have multiple layers and animations.
Should I use layered Imagebuttons? there can potentially be doezens of them on the screen at once, and i don't know if there are memory concerns about having 200 imagebuttons on a screen.
Do I need to use a canvas? I have seen canvases in many examples, but i don't know if they are the best option.
Is there some other class or way of doing this that is better?
any help you can provide would be much appreciated.
You'd be best served by an Android game library. Check also e3roid.
I'm thinking about writing a pretty basic game, which mostly involves sliding images around on the screen when tapped. So tap an image and it slides to one side. Doesn't seem like Android Animations will help me here since those don't actually move the images, just makes it appear moved.
So even though this seems like pretty basic functionality, it seems like I have to write a game loop,etc and implement my own code to handle the "animation" (including some acceleration/deceleration), etc. Not hugely hard or anything, but just seems like overkill. Also using a 3rd party game engine also seems like overkill, just in the time it would take to learn that, and so on.
Am I off base here?
If anyone has any suggestions that might get me pointed in the right direction (links, etc) that would be great. Is there a good way to use Android Animation functionality in this case that I am missing?
If you are developing for Honeycomb, it may be as easy with animations. With Honeycomb, there is a whole new strategy to animation. Check out the blog. The premises is that any property or value can be animated, and that includes the view's actual position (and not just look like it moved).
I have built a couple of games using AndEngine (http://andengine.org) I would recommend it for making games for android. And since it is all written in java, it is relativiely easy to integrate it with layouts and other activities.