I was wondering if it was possible for a SurfaceView to hold multiple ImageView. Each ImageView should be able to move independently. Imagine a table of cards, where each card is to be moved. The cards (ImageViews) are to be added to the surfaceview dynamically. Any ideas? Tried researching it, but to no avail. Thanks!
A SurfaceView is a View, not a ViewGroup. Therefore, it cannot hold any ImageView at all :)
As Romain's answer hints at, you seem to have a fundamental misunderstanding of what SurfaceView is. Take a look at the docs. It's a View for drawing on, not to hold other Views (be they ImageViews or otherwise). You can draw images (including bitmaps) on it, but that's different from holding ImageViews. If you're looking to have a game with a bunch of cards, you probably want to find a tutorial on drawing with SurfaceViews. This might be somewhere to start.
Related
I'm looking for a way to display views (like buttons, checkboxes, images etc) in a container, which might be bigger than the actual screen size.
A ScrollView within a HorizontalScrollView is no option, since you're only able to scroll one direction at once, not diagonal.
I have yet to find a simple solution to this problem. A zoom function would be nice to have, but that's not as important as the ability to scroll diagonal.
Are there any components out there able to do things like these? Doesn't even have to be for free.
I have created a relative layout with couple of buttons at the bottom of the screen. The reast of the screen is blank. I want to place/drag images where user touches the screen. I am between 2 options. These images have animation so I was going to use animationdrawable
1- Use the activity OnTouchEvent to make sure the click is within empty area and start placing/moving images around
2- Create a surfaceview in this area and implements its touch events and deal with a surface view.
What do you think?
Thank you
Well, both of those ways should work and i think it is optional choise.
Here i think i would go on the onTouchListener because that all of your view is writen with xml, using surfaceView now will make the code complicate.
I think you should take it aldo because it is writen for you. This will make your life way easier.
You are using drawable, stored as integer in R and making surfaceView will be difficult because you will need to use the SurfaceView, bitmaps inside him and the xml.
To get the press you will use onThouchListiner anyway, stleast when you do it, you will make your life way easier
I would like to know what is the difference between SurfaceView and ImageView and their usage scenarios. Both seem to be the same. Kindly direct me if there are proper links which I had probably missed.
Some advantages and differences of a surface view:
Better rendering mechanism. threads can update the surface's content without using a handler. This helps for better performance in games and too much animation.
So if you need to update GUI rapidly or if the rendering takes too much time and affects user experience then Surfaceview is advisable instead of imageview.
Surfaceviews cannot be transparent, they can only appear behind other elements in the view hierarchy.
Surfaceview has dedicated buffer, too. So it costs more resources than imageview and other views.
Here is a reference links which you could refer to understand better.
Difference between SurfaceView and View?
Hope this clears some doubt.
Basically the difference lies on how both the views are being processed internally.
Surface View, has more rendering options. The view implicitly can render the images or animations using the graphics hardware. It doesn't need any third party support ( or makes less use of ) to make the animation work.
Preferably used when you want too many animations to be used. The View renders them automatically to the screen size. Ex: gaming applications.
Image View, is preferably when you want to display more of static images. The View render the images to any layout size. But when you have any animations on the page, the View takes support of GUI related conversions.
I would like to make a simple Android game where a large background image is displayed and some other images are displayed in specific locations over it, where the other images may be clickable.
Here's a quick sample image of what I'm talking about:
The user should be able to tap the soccer player or the moose (ah, the classic "soccer player moose problem"!)
How should I render this screen (which layouts and views?) so the user can interact with it and it will scale properly on different devices?
I would use a RelativeLayout.
You can set the you background image to the layout (fill_parent for height and width).
You can then put your ImageViews, containing your moose and soccer player down on the layout relative to the top or sides of the sceen, or relative to each other (making sure to specify "dp" units for everything). Set the backgrounds of your ImageViews to be transparent, and there won't be a bounding box problem (and/or you can also set your ImageViews alignment to be relative to each other, ensuring they don't overlap).
I think this is the simplest way to do this - it is then super easy to attach onClickListener to your ImageViews in your Activity, and you are done.
This type of layout will work the same on all devices and screen sizes.
There are some small gotcha's with RelativeLayouts, but they are pretty simple once you get into them, and provide fast rendering (since the view hierarchy is usually shallow). Good Luck.
ImageView for the clickable elements seems like a fine choice to me. For the background I would just set your image as the background of the parent layout i.e. RelativeLayout
SurfaceView for the whole thing (with your field as a background) and regular *ImageView*s for added elements. You can easily recover the click coordinates from the SurfaceView and thus know what element has been touched.
SurfaceView might offer you additional possibilities anyway.
For most images, I'd use an ImageView for each one, like FoamyGuy said.
If they're close enough for overlapping bounding boxes to be an issue, you can still use an ImageView for each, but with a variation of this answer, testing alpha for each ImageView in range.
I would agree with both FoamyGuy and Booger that if your only goal is to place static images onto the screen that do something when you click them, RelativeLayout and ImageViews all the way.
But...
If you are looking to randomly spawn multiple images onto the screen in intervals and have them move around for the player to interact with while explosions are going off and maidens are being kidnapped, you should look into SurfaceView, Canvas, Drawable, TouchEvents, and FrameBuffers.
I hope I'm not too vague with this question. For some reason I've developed an inordinate fear of being ambiguous with my SO questions :-)
I need to make a design decision and, having just recently started in my Android efforts, I thought I might ask about its potential dangers among those who've been in the trenches for awhile.
I'd like to build a gallery within a gallery. The outer widget views will scroll horizontally, while the inner views--being galleries themselves--will scroll vertically.
Has this been tried/crashed/burned in the past? If so I'll rethink my UI, but I wanted to ask in advance before I spend a lot of time chasing the wrong dog.
Thanks,
Jeff
The gallery widget cannot scroll vertically. There's no way to change orientation, it can only be horizontal. You can build it custom, something like attaching image views to list views and such, or you can use something like a wheel scroller, like this one, called android wheel, and do some tweaking to make it look and work the way you want. These two SO posts might help as well, for the vertical aspect.
Lazy load of images in ListView
Vertical gallery in android