Develop Reference

Android MPAndroidChart xasis values showing more than 1

I am using android java MPAndroidChart Library.
As you can see from photo, value of x axis showing more than one. I just want to show tuesday one time. How can I do it
image of chart

I find the solution
lets say your name of the list is myArray and answer is
barChart.getXAxis().setLabelCount(myArray.size());

You can set a count of label by force. This will result into one label only on your axis.
For example:
xAxis.setLabelCount(1, true)
From the documentation:
/**
* sets the number of label entries for the y-axis max = 25, min = 2, default: 6, be aware
* that this number is not
* fixed (if force == false) and can only be approximated.
*
* #param count the number of y-axis labels that should be displayed
* #param force if enabled, the set label count will be forced, meaning that the exact
* specified count of labels will
* be drawn and evenly distributed alongside the axis - this might cause labels
* to have uneven values
*/
public void setLabelCount(int count, boolean force) {
setLabelCount(count);
mForceLabels = force;
}
The other thing you can try is working more with granularity.
Like so:
axisLeft.granularity = 3F
From the docs:
/**
* Set a minimum interval for the axis when zooming in. The axis is not allowed to go below
* that limit. This can be used to avoid label duplicating when zooming in.
*
* #param granularity
*/
public void setGranularity(float granularity) {
mGranularity = granularity;
// set this to true if it was disabled, as it makes no sense to call this method with granularity disabled
mGranularityEnabled = true;
}

WorldWind Sphere Line Intersection Bug?

I'm seeing what appears to be contradictory behavior out of WorldWind's Sphere-Line intersection logic. I create a Sphere and Line and they intersect but then the intersection returns null (scan code for comment: // *** This is where it gets whacky).
Here is what's going on visually (the line is gray it's there but hard to see):
public class WWTest extends ApplicationTemplate {
public static class VisualizationFrame extends ApplicationTemplate.AppFrame {
public VisualizationFrame() {
super(new Dimension(1200, 1024));
final Globe globe = getWwd().getModel().getGlobe();
//Create a sphere at 0,0 on the surface of the Earth wtih a 60 NMi radius
final Vec4 sphereCenter = globe.computePointFromLocation(LatLon.ZERO);
final Sphere sphere = new Sphere(sphereCenter, 111120);
// Draw the sphere
final RenderableLayer sphereLayer = new RenderableLayer();
sphereLayer.addRenderable(sphere);
final RenderableLayer pathLayer = new RenderableLayer();
// Create a line at 10k feet (3048 meters) that starts outside the sphere at (2,-2) and proceeds into the sphere at (0.5, 0.5)
final Position lineStart = Position.fromDegrees(2, -2, 3048);
final Position lineEnds = Position.fromDegrees(0.5, 0.5, 3048);
final Path asPath = new Path(lineStart, lineEnds);
pathLayer.addRenderable(asPath);
// Now that we've visualized the line, let's do some intersection math
final Vec4 lineStartsAsVec = globe.computePointFromPosition(lineStart);
final Vec4 lineEndsAsVec = globe.computePointFromPosition(lineEnds);
final Line asLine = Line.fromSegment(lineStartsAsVec, lineEndsAsVec);
// *** This is where it gets whacky - true, but no intersection?
final boolean doesIntersect = sphere.intersects(asLine);
final Intersection[] intersection = sphere.intersect(asLine);
//outputs: Intersection found: null
System.out.println(doesIntersect ? "Intersection found: " + Arrays.toString(intersection) : "No intersection, Why Not!?!?");
insertBeforeCompass(getWwd(), sphereLayer);
insertBeforeCompass(getWwd(), pathLayer);
getWwd().getView().setEyePosition(Position.fromDegrees(0, 0, 500_000));
getLayerPanel().update(getWwd());
}
}
public static void main(String[] args) {
ApplicationTemplate.start("World Wind Sphere-Line Intersection", VisualizationFrame.class);
}
}
And here are the dependencies I declared to get WorldWind into my maven project (I also did try version '2.0.0-986', but that didn't seem to help):
<dependency>
<groupId>gov.nasa</groupId>
<artifactId>worldwind</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>gov.nasa</groupId>
<artifactId>worldwindx</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>org.jogamp.gluegen</groupId>
<artifactId>gluegen-rt-main</artifactId>
<version>2.2.4</version>
</dependency>
<dependency>
<groupId>org.jogamp.jogl</groupId>
<artifactId>jogl-all-main</artifactId>
<version>2.2.4</version>
</dependency>
To be completely thorough, here are the code imports:
import gov.nasa.worldwind.geom.Intersection;
import gov.nasa.worldwind.geom.LatLon;
import gov.nasa.worldwind.geom.Line;
import gov.nasa.worldwind.geom.Position;
import gov.nasa.worldwind.geom.Sphere;
import gov.nasa.worldwind.geom.Vec4;
import gov.nasa.worldwind.globes.Globe;
import gov.nasa.worldwind.layers.RenderableLayer;
import gov.nasa.worldwind.render.Path;
import gov.nasa.worldwindx.examples.ApplicationTemplate;
import static gov.nasa.worldwindx.examples.ApplicationTemplate.insertBeforeCompass;
import java.awt.Dimension;
import java.util.Arrays;

If you look at the implementation of Sphere#intersect() it is expecting the line in coordinates centered at the sphere's origin (not the Earth's) which is almost certainly a bug. You should be able to do:
final Vec4 pa = lineStartsAsVec.subtract3(sphereCenter);
final Vec4 pb = lineEndsAsVec.subtract3(sphereCenter);
final Line asLine2 = Line.fromSegment(pa, pb);
final Intersection[] intersection = sphere.intersect(asLine2);
Keep in mind that the intersections returned are still in Cartesian coordinates centered at the sphere's origin, so to transform them back to World Wind Cartesian you need to do:
final Vec4 intersectionPos = intersection[0].getIntersectionPoint().add3(sphereCenter);
The implementation also considers the line to be infinitely long so it will return two points, not one.
It would be pretty straight forward to implement your own version of intersect() that works in normal coordinates and takes into account the length of the line, see here.

If you look at the Worldwind source code, specifically the intersects() and intersect() methods of the Sphere class and step through them with your code as input, you see the following:
The method:
public boolean intersects(Line line)
returns true because the distance from the sphere centre to the line is less than the radius of the sphere, as expected.
For the method:
public final Intersection[] intersect(Line line)
it turns out that the discriminant of the quadratic is less than zero (i.e. there are no real roots to the quadratic equation - two distinct complex roots).
The WorldWind API reference is here.
The specific methods involved are:
/**
* Tests for intersection with a <code>Line</code>.
*
* #param line the <code>Line</code> with which to test for intersection
*
* #return true if <code>line</code> intersects or makes a tangent with the surface of this <code>Sphere</code>
*
* #throws IllegalArgumentException if <code>line</code> is null
*/
public boolean intersects(Line line)
{
if (line == null)
{
String msg = Logging.getMessage("nullValue.LineIsNull");
Logging.logger().severe(msg);
throw new IllegalArgumentException(msg);
}
return line.distanceTo(this.center) <= this.radius;
}
and:
/**
* Obtains the intersections of this sphere with a line. The returned array may be either null or of zero length if
* no intersections are discovered. It does not contain null elements and will have a size of 2 at most. Tangential
* intersections are marked as such. <code>line</code> is considered to have infinite length in both directions.
*
* #param line the <code>Line</code> with which to intersect this <code>Sphere</code>
*
* #return an array containing all the intersections of this <code>Sphere</code> and <code>line</code>
*
* #throws IllegalArgumentException if <code>line</code> is null
*/
public final Intersection[] intersect(Line line)
{
if (line == null)
{
String message = Logging.getMessage("nullValue.LineIsNull");
Logging.logger().severe(message);
throw new IllegalArgumentException(message);
}
double a = line.getDirection().getLengthSquared3();
double b = 2 * line.selfDot();
double c = line.getOrigin().getLengthSquared3() - this.radius * this.radius;
double discriminant = Sphere.discriminant(a, b, c);
if (discriminant < 0)
return null;
double discriminantRoot = Math.sqrt(discriminant);
if (discriminant == 0)
{
Vec4 p = line.getPointAt((-b - discriminantRoot) / (2 * a));
return new Intersection[] {new Intersection(p, true)};
}
else // (discriminant > 0)
{
Vec4 near = line.getPointAt((-b - discriminantRoot) / (2 * a));
Vec4 far = line.getPointAt((-b + discriminantRoot) / (2 * a));
return new Intersection[] {new Intersection(near, false), new Intersection(far, false)};
}
}
which uses:
/**
* Calculates a discriminant. A discriminant is useful to determine the number of roots to a quadratic equation. If
* the discriminant is less than zero, there are no roots. If it equals zero, there is one root. If it is greater
* than zero, there are two roots.
*
* #param a the coefficient of the second order pronumeral
* #param b the coefficient of the first order pronumeral
* #param c the constant parameter in the quadratic equation
*
* #return the discriminant "b squared minus 4ac"
*/
private static double discriminant(double a, double b, double c)
{
return b * b - 4 * a * c;
}
in this case your code fails the:
if (discriminant < 0)
test.
It looks like I've been a bit slow in answering this question, and in the meantime it has been pointed out by Chris K that this is due to the intersect() method expecting the line coordinates to be centered at the origin of the sphere and not of Earth.
As Chris K said, this seems to be a bug and should probably be logged with the maintainers of this source code.

Is it possible to create documentation comments on the right instead on top?

Documentation can sometimes reduce the readability of code.
Instead of
/**
* The X axis.
*/
int x;
/**
* The Y axis.
*/
int y;
/**
* The Z axis.
*/
int z;
I'd rather prefer to have
int x; /** The X axis */
int y; /** The Y axis */
int z; /** The Z axis */
Is there a way in Java to have the comments on the right of e. g. a variable declaration? I've seen it work in C by using the "<" character, but haven't seen it in Java yet. Java is already in Version 8 and I'm wondering why it still isn't possible. Or is it?

Doc Comments work only once. They could be anywhere in the code and many times but only first one is extracted by Javadoc tool. The rest is simple ignored.

Mapping logical coordinates to graphical fails when scaling

I encountered a slight problem with my game's rendering system when I tried to scale certain objects. I think it must be the way I map objects with logical coordinates to graphical ones on the screen.
Renderable
/**
* Retrieve the image representing the object that should be rendered.
* #return The image sprite representing the object.
*/
public Texture getSprite();
/**
* Retrieve the x-coordinate where the object should be rendered.
* #return The x-coordinate of the object.
*/
public float getScreenX();
/**
* Retrieve the y-coordinate where the object should be rendered.
* #return The y-coordinate of the object.
*/
public float getScreenY();
Texture
......
......
/**
* Retrieve the width of the texture.
* #return The width of the texture.
*/
public int getWidth();
/**
* Retrieve the height of the texture.
* #return The height of the texture.
*/
public int getHeight();
......
......
This system works perfectly when I draw stuff like interfaces etc, which have no logical coordinates in my game world.
Let's take a look at an object that have logical coordinates and see how I map the coordinates to graphical ones and thus causing a problem when I scale the texture when drawing.
Tile
#Override
public float getScreenX() {
return x * width;
}
#Override
public float getScreenY() {
return y * height;
}
Let's say the size of the texture for any tile is 16*16 but for some reason I want to draw it at 32*32. This will cause a problem since the tile's graphical x- and y-coordinate messes up.
Note: I know that I can fix this by allowing the user to set a scale when loading the image into the system but I want it to be more flexible.
TL;DR: How can I accomplish a better mapping between logical coordinates in the game world to graphical ones while still being able to scale when I want to? There should be a better way to map instead of letting the logical objects be in charge of their graphical coordinates.

Javadoc multiple variables on single line

I have a class like the following...
class A{
/**
* Blah blah
*/
Type1 var;
/**
* What do I do here?
*/
Type2 var11, var12;
}
How can I javadoc var11, and var12 if they are both on the same line?
I am curious to see if this is possible, I know I can put them both on an individual line and javadoc from there.

I was curious so I tried it out
/**
* data stuff
*/
int x , y ;
The resulting javadoc repeated the same doc comments for both x and y.
I imagine this behavior would be useful if two fields were essentially the same with minor differences.
class Circle
{
....
/**
* center coordinates
* The x/y coordinate of the center of this circle.
*/
int x , y ;

unfortunately there is no way to differentiate single line declaration of multiple variables :(
It may be useful to note however that the benefit of this does allow for a single javadoc to provide documentation for categorical variables which may otherwise take unnecessary lines.
/**
* custom colors (MUST BE DISPOSED!)
*/
Color lightblue, someotherblue, lightred;
of course this can be combined with initialization as well
/**
* These are the spec's behind batch-box font size / Height / Width
*/
private int iFontHeight = 9, iboxheight = 58, iboxwidth = 125;