2017년 8월 18일 금요일

Line/Radar graphs on canvas *Update* Donut/Pie graphs


Hello, i want to share this simple project to draw graphs on canvas. the main benefit is the customization that you can do on this graphs and the low weight.

feel free to use or improve

UPDATE 5-2-16

added Pie and Donut charts (page 3 and 4), these graphs responds to touch (get canvas pixel color)













Nice work!

--

Multi 'rate' sliders


Working on a new little app and I needed a way to set a value (battery capacity) that has a fairly large range (almost 2 magnitudes of order or 100-10,000). While big steps of 500 are appropriate at the high end I need a much finer resolution at the low end - like in steps of 10.  I could have substituted a spinner and programmed specific values but this was not optimal because of the unknown number of value possibilities.  ie. with a spinner or listpicker you have to either know all the possible values, or program list management. A spinner or listview/picker with over 50 possible values doesn't really work.  So here's my solution.

Three sliders with three different Min/Max pairs. In the example below sldBatterysizeSmall is min 50 max 420, sldBatterysize is min 300 max 2600 and slBatterysizeLarge is min 2000 max 10,000. For clarity I collapsed the set label.text but each uses easy math to set the text from min - max rounded to 10, 50, and 500 respectively. Having 3 sliders with 3 unique .PositionChanged events makes everything quite tidy.  The fun part is that the sliders sit next to each other in an arrangement and only one is visible at a time.  Controls makes them automatically switch as required. Effectively I've tripled the width of the screen for the purpose of the slider.
With a mouse using the emulator it operates a bit strangely if you do not let up the mouse button when the slider you're dragging is set to invisible. Even though it's invisible you are still dragging it, so things look really 'off'. In fact it's possible to Un Hide two of the sliders at once. On a touch screen device, however, it's quite natural to lift your finger when the slide jumps left or right and 'regrab' it. Thus the operation seems pretty natural.  You do have to take care to set the overlapping in such a way that each of your required settings is possible. You don't want your users frustrated trying to set something between the sliders. 

I s'pose it would be even easier to make a logarithmic or exponential rate slider but for multiple ranges with different rounding precision requirements this might be just the ticket. I attempted to do this by changing the min-max of a slider dynamically. That does not work.

--
Yup. The steps or resolution of the slider is handled in setting the label text with rounding (not shown in my pic). With three, or more, sliders I can extend the range of the control without taking up more screen space or reducing the number if steps (unless I want to).

--
How about a multi-turn logarithmic knob linked to a label?
Set up a square canvas with a big ball in the middle and a
rotating sprite (line) atop it that will spin around the ball center
as you drag it.

As you turn the knob, multiply or divide the label value by some
constant factor per degree of rotation.

The Format as Decimal block can be used for precision management,
depending on order of magnitude.

--
ha.. now you have me researching UX and UI design. The drawing and animation opens up lots of possibilities for behaviour and limitless design. 

--
Here is a way to have one dial use two different scales of values.
The scale is selected by clicking either of the scale buttons at the top.


--
You really got me thinking with that one Scott. Couldn't put it down until I came up with an iPod style infinite wheel control.  It's not appropriate for the app where I'm using the slider above in but it gives ultimate control of speed, resolution, and an infinite range. It does chew up a chunk of screen space and of course it has to be a square.  Gonna post it in a new topic. 

--
High five!

--

Angry Balls V2 Documentation


Abe Getzler


This is a simulation of ball collision in the case where the cue ball hits a stationary  target ball.


(The project name came from my initial attempt to launch the cue ball
from a slingshot.  I gave up on that mechanic, but kept the cute name.)


The cue stick, cue ball, and target ball can all be dragged around to
set up shots.


This is a partial result.  It only works for collisions against stationary balls.
That's why I called it V2.




Screen shot

Designer


The screen components include a canvas with a cue stick, cue ball, and target ball, plus controls.  The controls include a speed slider, and four buttons:  Reset, Shoot, Pause/Resume, and Options (speed).  For debugging, there’s a List Picker to show a log of calculations.


The draggable cue stick, cue ball and target ball let you set up shots



The cue stick always points to the center of the cue ball when dragged:
Its graphic is a 2 by 100 bar, given a 4 by 100 size to make it easier to grab.




We keep track of all our balls at initialization time…


Resetting the board…


The four buttons: Reset, Shoot, Pause/Resume, Options …
The Options button reveals a speed slider.


Pause/Resume


The Pause/Resume button is used to Pause and Resume alternately, depending on its Text.  
To Pause, it collects the balls’ speeds, saves them in a list with their components, and sets their speeds to zero.  
To Resume, it goes through that list of saved balls and speeds, and resets the balls’ speeds from their saved values.


The Shoot procedure sets the pool cue in motion towards the cue ball.


When the cue stick hits the cue ball, transfer its speed and direction to the cue ball …


We make the pool cue invisible and disable it so it doesn’t interact with other balls.
This also helps to hide the pool cue stabbing thru the cue ball, though you can catch a glimpse of that happening if you are quick.


To avoid a cannibalism effect, we keep a list of balls that are in the midst of a collision.  This will be used to stop multiple CollidedWith blocks from handling the same collision.


When the collision is over, remove the balls from the colliding balls list …




When balls hit the edges of the canvas, have them bounce off the walls.


There’s a bug here - when a ball hits a corner it sticks to the corner.  If there were a “DepartedEdge” block I might be able to deal with it.  It’s no big deal for a little demo like this.


When the pool cue hits the cue ball, we give the cue ball the speed and heading of the pool cue, then remove the pool cue from action.




Ball Collisions


Collision of balls is handled by a procedure that accepts as arguments the two colliding balls’ components.  For this simplified case we deal only with a cue ball hitting a stationary target ball.


We will ignore collisions with balls that are already colliding, as recorded in the colliding_balls list.
We add the two colliding balls to the colliding_balls list, and leave it to the NoLongerColliding blocks to “uncollide” them from that list.


First half of the bounce procedure




We send the target ball off in the direction of a line from the cue ball to the target ball.  This is done the easy way, by using the Ball.PointTowards block to point the target ball towards the cue ball, then reversing the target ball’s heading by subtracting 180 degrees from it.


Normalizing directions to avoid anomalies


The expression of directions as degrees is problematic, because there is always a place on the dial where there will be a discontinuity, the same way the International Date Line can cause air travelers in the Pacific to gain or lose a day by crossing this imaginary longitudinal line.  


We will choose between two different normalization schemes to express our angles, to keep the discontinuity behind the cue ball so it doesn’t mess up our bounce calculations.

Normal180 will bring an angle into the range -180 to 180. This good for directions heading to the right of the canvas.
Normal360 will bring an angle into the range 0 to 360.  This good for directions heading to the left of the canvas.


We add or subtract 360 degrees to our input angles to bring them into our desired ranges.
We will package up the choice between these schemes in a single normalization procedure:


Second half of the bounce procedure




The angle of incidence is defined as the angle between the incoming cue ball direction and the outgoing target ball direction.


We then transfer some speed from the cue ball to the target ball, taking care to conserve energy and momentum in the x and y directions. For a frictionless spinless collision with a stationary ball of equal mass and size, the speeds are proportional to the sine and cosine of the angle of incidence.  ((sin(theta))^2 + (cos(theta))^2 = 1)


The cue ball heads off at right angles to the target ball heading in this special case, heading off to the left or right (+/- 90 degrees) depending on which side of the target ball it hit, as measured by the sign of the angle of incidence.


To avoid a negative speed for the cue ball, we take its abs() value.
Intermediate angles are logged at three stages of this process for debugging.


Feel free to copy this with attribution.


Source code …
angry_balls_v2.aia
This doc …