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.
Related
working on an app and The way I want to set it up is different than what I have ever done before. I want the main activity when launched into the app to exceed past the boundaries of the physical phone screen, and for the user to be able to swipe out to parts of the app that they can't originally see.
I am not sure what the terminology is or what methods or classes etc to use. Any info that could point me in the right direction would be great! Thanks!
Just some clarification:
I think what I'm trying to say is the second thing you talked about. Imagine if you place a iPhone for example in the middle of a piece of computer paper. What I want to achieve is to have the whole view the size of the paper, but only be able to see the size of the iPhone's screen at a time. So you can go up a little bit and see what was above the screen, or left or right
If you want more screens and be able to switch between them, use ViewPager.
If you want one large view bigger than screen, you can either combine ScrollView for vertical scrolling and HorizontalScrollView for horizontal scrolling, or make some custom View, which will be able to scroll (you have to implement it on your own) in both direction.
If you want to have just some views outside of the screen and bring them to visible area on some event, you can use RelativeLayout and set to its views proper margin.
If you want something else, add more information, how it should look and act like.
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 have a help screen that comes up before my android game starts. It's a ScrollView. While playtesting, I found that almost without fail the players would tap on the screen at various points until they accidentally moved the screen a bit. Then they realized it was scrollable.
This isn't a good experience. I want the scrollable edge of the screen to glow constantly so that it's obvious that you need to scroll. Simply showing the scrollbar doesn't help because it's so minimalist. Even if it's wider I'm not sure it would attract the eye enough to clue people into the need to scroll.
Is this possible to do or do I need to derive my own version of ScrollView? If the latter, what do I need to do to make the edge glow?
One way, theoretically, is to use:
yourScrollView.setOverScrollMode(ScrollView.OVER_SCROLL_ALWAYS); // android:overScrollMode="always" in XML
However, I've had no luck with this feature (at least with vertical ScrollViews). Instead, I would recommend adding an arrow down the side of your page, or some text that says "scroll down". This way, it will blend in nicely with your app.
Alternately, you could make the scrollbars more visible (perhaps bright pink!) by employing this tactic (the article is on ListViews, but it should work for a ScrollView too), in addition to always showing scrollbars.
I am starting a new application and I am willing to use the Dashboard pattern.
For example: The Google IO app uses it:
My issue is that the amount of buttons will be more than six.
I'm not sure if I should use vertical or horizontal scrolling.
Vertical scrolling could be done with a ScrollView or a GridView but I am not sure which would be the easier way to implement the horizontal version.
I was thinking of using an HorizontalScrollView but it doesn't have pagination. It should feel similar to the tweetdeck app.
How would you implement it?
My issue is that the amount of buttons will be more than six. I'm not sure if I should use vertical or horizontal scrolling.
IMHO, do neither. Reduce the number of buttons. Watch the 2010 Google I|O presentation on this design pattern -- the point behind the dashboard is to only surface a few items.
I would go with a vertical scroll. It is way more natural to scroll down to view more content of the same view.
A horizontal scroll kind of feels like you switch to another part of the application.
I have an app that uses a gridview with vertical scrolling but I dynamically adjust the number of rows in the gridview based on the width of the actual screen so that it in landscape or in a bigger display it uses more columns and avoid scrolling alltogether in most cases.
However in my case it is more of a search results display of categories and not a dashboard. I believe the whole point of a dashboard is to have only a small number of button (e.g. max six or so).
What you could do is dynamically interrogate the screen real estate and if there is not enough room just show e.g. 6 buttons of which one is a more/utils or whatever button. Sort of like the options menu does it.. but on a bigger screen display them all.
It would be interesting to scroll based on the orientation of the device, so you would scroll horizontally or vertically if the device is oriented that way. This would let you maximize the screen real estate.
This might be a "duh" question but I'm going to go ahead and ask it anyway.
I have an oversized (bigger than the screen) RelativeLayout, and I'm using swipes to start a TranslateAnimation from viewing one part of the layout to another. Say for instance the layout is two screen wide and two screens tall. After the nice animation to shift the screen, I was using View.scrollTo() to set the new position. This works fine going from the first screen (top left at 0,0) to one of the others. When I swipe to animate back to the first screen though, because the View.scrollTo() invalidated that part of the layout (I assume), that part of the layout is all black as I animate through it. I tried a couple things to get it to redraw itself after the scrollTo() but haven't had any luck, so I figured I'd ask here.
thanks!
joe d
I can't help with your specific problem since I've never tried working with a layout bigger than the screen, but there might be another way to achieve what you're trying to do. If you simply want to be able to finger-swipe from one View to another, without ever displaying part of one screen and part of another (i.e. you aren't smoothly panning around a large View but rather just jumping from one distinct section of the layout to another), then these tutorials might help, here and here. They show you how to use touch events and the ViewFlipper widget to change between Views using animations.