Using relativelayout with absolute positions - android

I know I can use margins to do that but I am getting some problems when objects are near edge of the screen. In this case android tries to fit all contents of view into screen which is something I don't want. For example if I give 200 width to a view and 100px of this is outside the screen it fits it to
100 px.
How can I avoid this?
Also why AbsoluteLayout is deprecated? I am currently working with it and it works but I wonder if people will throw stones at me

Without seeing your actual layout, it sounds like you want to have content that is offscreen. If you would like the user to be able to see that content, you could use a scroll view. That way, when you start your activity, your stuff will show up as you've laid out, with any overflow offscreen, and then the user can scroll over to it as desired.
<HorizontalScrollView
android:layout_width="match_parent"
android:layout_height="match_parent">
<LinearLayout
android:layout_width="wrap_content"
android:layout_height="match_parent"
android:orientation="horizontal">
<!--your stuff here -->
</LinearLayout>
</HorizontalScrollView>
Otherwise, if it's an image, there are various cropping and alignment options that could cover what you want.

Use RelativeLayout. Then just perform a simple check when adding View to RelativeLayout. For instance remember the last lastX & lastY location of added View and then check whether lastX + newView.width() <= RelativeLayout.width(). True -> add it, False -> set Y coordinate of newView to something like lastY + HEIGHT + BOTTOM_MARGIN and lastX back to 0

In the end I just added some negative paddings to my relative layout. Thanks to these paddings, views does not try to fit themselves into screen

Related

How do I make a Button so that when I put part of it out of bounds the program doesn't just cut the parts of it that aren't inbound

How do I make a Button so that when I put part of it out of bounds the program doesn't just cut the parts of it that aren't inbound. What I mean is this.This is a rotating view, the rectangles are rotating around the circle, but since I put 2 of the buttons partially out of bound their parts get cut off. Is there a quick fix for this?
(If programmatical fix is necessary I am writing in Kotlin)
The reason this is happening is because the RelativeLayout in which you're adding these four Views (buttons), has the width of screen's width. You need to increase its width to contain both the left and right buttons completely. Then, when you rotate the RelativeLayout, the buttons will be visible.
For testing purpose, try giving this width to RelativeLayout
<RelativeLayout
android:layout_width = "1000dp"
android:layout_height = "1000dp">
<!--Your buttons here-->
</RelativeLayout>
See if this works out. If it does, then you'll have to calculate the width of RelativeLayout programmatically.

Scaling and overlapping ImageViews

I am a bit of an android noob, and have been struggling with this problem for far too long.
What I'm aiming for:
Two ImageViews. The first will be the width of the screen, and drawn to match the proportions of its src image (so far so easy). The second ImageView needs to be scaled, so that its width is a fixed multiple (between 0 and 1) of the first image.
I will ultimately then need to be able to touch-drag the second smaller image around on top of the first, fixed image, although this part is not the point of this question.
This will all generally be done programmatically, as the src images and the scale multiple are not known until runtime.
What I've tried: I can overlay two ImageViews in a RelativeLayout, using alignParentTop and so on. This works fine, but I can't see how to scale the images in this case.
I can alternatively scale the two ImageViews using a LinearLayout, by setting their layout_weights to 1 and the scale multiple respectively. In this case I can't get the images overlapping however (not strictly true - I have managed this with negative margins, but it is a very hacky solution and will make it almost impossible to implement the movement of the top image later).
So my question is: is there a way to fix either of the two solutions I have tried to implement? Or is there perhaps a better way to approach the problem?
(I'm not necessarily looking for an answer in code, just the approach I should take)
Well with what I understand,
You can use a Constraint Layout
Place 1st ImageView on your desired place
with constraints to your parent
Place Second ImageView on your desired place
with constraints to the parent (NOT WITH ANY OTHER CHILD VIEW)
The Approach is if you put a SubView In ConstraintLayout with Constraints to Parent, you can manipulate (Scale / translate) without any effect on other views.
to change the position of the View in runtime you can use
view.setTranslationX() and view.setTranslationY();
you can also create a view programmatically with Constraints to the parent
(my personal preference)
you can use this to overlay different Views in ConstraintLayout
<ImageView
android:id="imageID1"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:src="yourImageStable"
android:adjustViewBounds="true"
android:scaleType="fitCenter"
// put your own constraints-
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent">
</ImageView>
<ImageView
android:id="imageID2"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:src="yourImageUnStable"
android:adjustViewBounds="true"
android:scaleType="fitCenter"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent">
Note: This two constraint value will draw an ImageView from the Top-Left
corner of the Parent View (on Position x=0, y=0)
Remember: the View which you want to overlay should be written next to the other,
like here ImageID2 can overlay ImageID1.
</ImageView>

RelativeLayout align parent *side* + margin *side*

I've noticed a strange behavior in RelativeLayout when you align a view to the layout's side
(any side) and having a large margin in the same direction.
I have 2 RelativeLayouts that each contains a simple view. In one layout that view is align to the top and left, in the other to the bottom and right:
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<RelativeLayout
android:layout_width="150dp"
android:layout_height="150dp"
android:layout_marginTop="110dp"
android:layout_gravity="center"
android:background="#ff555555" >
<View
android:layout_width="50dp"
android:layout_height="50dp"
android:layout_alignParentTop="true"
android:layout_alignParentLeft="true"
android:background="#aa8711" />
</RelativeLayout>
<RelativeLayout
android:layout_width="150dp"
android:layout_height="150dp"
android:layout_marginBottom="110dp"
android:layout_gravity="center"
android:background="#ff555555" >
<View
android:layout_width="50dp"
android:layout_height="50dp"
android:layout_alignParentBottom="true"
android:layout_alignParentRight="true"
android:background="#998877" />
</RelativeLayout>
</FrameLayout>
It looks like this:
I added 130dp of margin in each direction of parent alignment. That means that the view should be only partially visible in the layout. This is what happens:
As you can see, the views are now smaller than the original size, as the get pushed on the "walls" of the layout. Next I tried to give a margin that is bigger than the layout, so I gave them 151dp of margin in the aligned directions. It looked like this:
The bottom-right aligned view now "breaks out" of the layout and is again the same size as it was originally. On the other hand, the top-left aligned view is too in its original size, but completely inside the layout instead of outside of it.
I've tried this individually and in every permutation of alignment and got the same results.
Question one: Can anyone explain this inconsistent behavior?
I tried the same thing, this time comparing the behavior to that of a FrameLayout.
Initial setup:
and after margins:
The FrameLayout keeps the view in its original size at all time and simply lets the view "exit" it. I tried to give a negative margin in the opposite direction of at least the size of the view that should be outside of the RelativeLayout and saw the same behavior as happens in the FrameLayout by default.
Question 2: Can anyone explain the difference in behavior and the opposite negative margin effect?
Why should it be only partially visible?
I added 130dp of margin in each direction of parent alignment. That
means that the view should be only partially visible in the layout
The box is getting smaller because preference is given to keeping it inside the parent layout at all costs, while still applying the margin. Since the smaller child view is 50dp, you have added a margin of 130dp, the total width it needs is 180dp but the parent view itself is only 150dp wide. That is 130dp + 50dp > 150dp - the child plus the margin cannot fit inside the parent.
This is "silly input" and the XML interpreter is doing its best to render something. The decision that it makes in the end is that it can alter the width of the child box and still respect the margin constraint. Or mathematically
130dp + 20dp == 150dp
Basically it shrinks the width of the inner box down from the assigned 50dp to 20dp so that it can fit inside the parent with its added margin. And if you look at the size of the square 20dp looks about right. It is 60% smaller.
This is clever behaviour by the interpreter because as screen sizes change and it runs into issues like this it should always preserve the margin constraint opposed to the width constraint.
In summary the interpreter is doing its best to fit the box, and its margin inside its parent, to do so it is making the box smaller. It is choosing to preserve the given margin, over the given width - probably because of the top-most parent layout.
When you say "this should be partially visible" I assume you think the child will render half inside the parent bounds, and half outside the parent bounds, similar to windows form development. This is not the case though because it will always try to keep children inside the bounds of parents in most layouts.
The choices that are made depend on the top-most parent layout too, some layouts may prefer to preserve the width of the child box rather than the margin, or even render the box outside of the parent's bounds.
In the second case:
so I gave them 151dp of margin in the aligned directions.
You are going beyond the point in which the interpreter can shrink the image. It cannot shrink the image to negative 1. That is
50dp + 151dp > 150dp
It can't meet this margin constraint you have given it so the behaviour is fairly unpredictable. At a guess I would say it knows it cannot keep both the images, along with their margins inside the parent. So it simply renders one inside and one outside.
Once again, this is silly input and the interpreter is doing its best to render what you want.
Can anyone explain the difference in behavior and the opposite negative margin effect?
A negative margin will do different things depending on the type of layout in its parent, and that it is aligned too. In a frame layout it will behave differently to a relative layout. Usually if you are looking at negative layouts you have chosen the wrong parent containers and you are trying to hack it to get it to look right.
I don't know what you are trying to do exactly but maybe you just need tweak your thought process a little and think of the poor interpreting trying to understand the XML you give it.
You wouldn't be the first person to be utterly confused by android's XML layouts. Nesting layouts inside layouts is always confusing and the behaviour changes depending on a number of things like margins, alignments, widths, etc. Most people I know simply muck around with it until it is right and try different container layout types to get the right design.
In short, avoid playing with margins (like flash or winforms) and play without layout types instead to get things where you want them.
hope that helps, sorry for tl;dr.

How to scale View / ViewGroup - animate layout in a proper way?

In a few words, I want to scale view - in the same way that Android Market does it, when you click the "More" button, on the for examplae 'Description'.
I figure it out, that the Android Market has the layout of following structure :
<FrameLayout
android:id="#+id/artists_frame"
android:layout_width="fill_parent"
android:layout_height="64dip"
android:layout_below="#id/something1"
android:layout_above="#id/something2"
>
<!-- Some view there, which height >> 64dip -->
</FrameLayout>
So, I've tried various Animations / LayoutAnimations on the FrameLayout (via view.setAnimation(), view.setLayoutAnimation() and ScaleAnimation), but the effect is always the same : the view animates, but it's real layout_height after scaling is still the same (so the position of the other views, that depend on the given FrameLayout, remain the same).
After that, I've thought - I change in the loop the layout_height of the given FrameLayout:
layoutParams = view.getLayoutParams()
layoutParams.height = scaleTo;
layout.setLayoutParams(layoutParams);
I've it got animating, market-like view, but the cost (performance!!!) is way to high...
So, the question is : Is there any other, proper way to scale (change e.g. height from 50dip to 200dip) the given View / ViewGroup so that the position of the views below the animating view also changes?
As Chet Haase says in this blog post: http://android-developers.blogspot.com/2011/02/animation-in-honeycomb.html
"...Finally, the previous animations changed the visual appearance of the target objects... but they didn't actually change the objects themselves..."
Since what your need is only visual, instead of changing the view's LayoutParameters I would animate the view in the bottom as well with a translate using android:fillAfter for both.

How to create two views in Android that use 50% height each, unless one is smaller?

Imagine a full Android device screen, I want it split in to two sections:
The upper half has text in it, which may be larger than the space available (or not) and so the text will scroll (i.e. TextView inside a ScrollView)
The lower half contains a MapView control.
Looking specifically at some scenarios:
If the text is small, I want the map to take up more space, i.e. more than 50%. So perhaps 20% text, 80% map.
If the text is larger, it only takes up a MAXIMUM of 50% of the screen space, and then scrolls. So 50% map, 50% text.
At the moment I've assigned weights to the two parts, and that isn't too bad, but if the text is small, the map doesn't expand to take the space, and the layout has a wasted gap that the map could usefully use.
I've tried loads of combinations but can't see how to make this happen. It seems to be a common experience for me that I know what I want, but can't see how to get the available views to deliver it. I'm hoping there's a nice easy way to do this.
Please feel free to make me look like a fool and point out the obvious attribute I've missed :-)
======================================================================
As far as I can see there's no way to do this just in declarative XML and it needs doing in the code. I set the text section height to wrap_content, weight to 0 (no resizing), and have the map set to weight=1 (i.e. take up the remaining space). I then check if the text section (in a ScrollView) is taking up too much space and if so, shrink it back. This code would need changing to support a different layout orientation.
private void fixLayoutProportions()
{
float maxPercentageOfScreenForText = 50/100;
LinearLayout container = (LinearLayout)findViewById(R.id.container);
ScrollView eventText = (ScrollView)findViewById(R.id.text_scroller);
int heightAvailable = container.getHeight();
int scrollerHeight = eventText.getHeight();
if ( scrollerHeight>(heightAvailable*maxPercentageOfScreenForText) ) // Text section using too much space
{
eventText.getLayoutParams().height = (int)(heightAvailable*maxPercentageOfScreenForText) ;
eventText.invalidate();
}
}
You can do it by putting everything into LinearLayout and changing following parameters:
the sum of weights for LienarLayout
weights for children
Did you try to measure your screen hight at run time:
Display display = ((WindowManager)
getSystemService(Context.WINDOW_SERVICE)).getDefaultDisplay();
int width = display.getHeight();
Then, set your top view max_height to width*0.5 and min_height to width*0.2. Your top view has to be control (like TextView) that has min_height and max_height properties. Also, set layout_weight to 0 or leave it empty.
On your bottom view set layout weight to 1.
The easiest way to do 50/50 is in XML is using LinearLayout weights. Basically put the two views into a single LinearLayout set the android:layout_weight on both child views to the same value, like setting both to .5, 1, or 42. You then set the layout_width to 0px or fill_parent/match_parent.
The smaller part gets more complicated. Luckily, you can turn off weighing in Java. One way is to wait until the windows get drawn (if they are pre-populated) and measure them. This can be done on I think it was called onWindowFocusChanged
I haven't tested this, but I'd try setting your ScrollView to have android:layout_weight="1" and your MapView to have android:layout_weight="0" and a android:minHeight="240dp". The hope is that minHeight will have precedence over layout_weight.
i think you have to set mapviews height as fill parent and set textviews height as wrap contetn and than for scrolling you have toset vertical scrool true for text view and as you nedded not more than 50% space textview you can set maxheight property of textview.
I am sorry if you find this trivial.
But I am suggesting it in case it did not strike you.
How about using relative layout and keeping the textview always on top of the map.
Make the gravity of the textview top, its width match_parent, its height wrap_content and its weight 1(same as that of thee map). That way your textview will change according to the size of the text, while not going above 50% because of the weight. As for the map, the user can pull the map down to see the hidden part under textview. It'll be as if there is no map under the textview(you know, unless you want to make the textview background transparent which i think would look cool :) ). I do not know about the map view. But I am assuming it'll be something like google maps on iphone, like you can vary size using multi-touch and scroll using single.
OK as I see its something like u are reserving at max half of ur screen to the TextView and if its more it has to scroll. I have a solution but for that you will have to fix the max no.l of lines for TextView, calculating which can be a pain :P but have a solution never the less.
main.xml file
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
>
<TextView
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:scrollbars="vertical"
android:maxLines="5"
android:id="#+id/tv1"
android:text="wsdvsv sjdgv jsdvn ksdjbn skjdb ksdnbk snbk snbjksn fkbj sfkbjn dfkjbndkjfbn kdjfnb kjdfnbkjdnfbk ndf bjkndf bndfjbn dfkbn jdfnbjdfnbjdfn bjdf nbkjdnf bkjdfnb kjdnfbkjdfn bkjndfbjndfjbndkjfbn dkfjbn kdjfnb kjdfnbkjdfnbjkd nfkjbndf"
/>
<TextView
android:layout_width="fill_parent"
android:layout_below="#id/tv1"
android:layout_height="wrap_content"
android:scrollbars="vertical"
android:maxLines="5"
android:text="Does it work ???"
/>
</RelativeLayout>
Java file:
package com.android;
import android.app.Activity;
import android.os.Bundle;
import android.text.method.ScrollingMovementMethod;
import android.widget.TextView;
public class TestActivity extends Activity {
/** Called when the activity is first created. */
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView tv = (TextView) findViewById(R.id.tv1);
tv.setMovementMethod(new ScrollingMovementMethod());
}
}
If the text is say only in 2 lines "Does it work?" will shift up automatically. But the only problem i see here is the max lines to 5 is you can an max value for u i guess this might work well :)
BR,
J
P.S. I haven't answered many questions before so i m not sure how to attach files :(

Categories

Resources