I am writing a DAW-style app and need to implement the side-scrolling timeline common in such programs. In other words it should appear to the user as though they are scrolling through a very large bitmap, several of them actually for the different tracks, seamlessly. Obviously I will have memory issues if I do it with a single very large horizontally-scrolling View, but that needs to be the effect the user sees. Right now I have a custom View for each track and drawing the wave into its Canvas.
I have thought of constructing three Views, left, active and right, and simply swapping out new data when the left or right one is scrolled to in time to be ready for the next screenfull. I think something along these lines is going to be the final solution, but I am not sure what would be the best way to implement it. Should I run a service in the background that watches for and updates the offscreen views, would that be the best way to accomplish this? I haven't used services before. Or is there a more direct way of doing it, attaching some code to the view to execute automatically?
Any suggestions would be appreciated.
Related
I'm working on an app where I must have on a part of the screen an animated music staff. That's:
5 static lines
A dozen of music notes (each one is basically an oval and a line)
A few additional symbols (clefs)
I must have a precise control of the size of each element, and have to smoothly animate position and alpha of the notes and clefs so the notes are moving right to left (disappearing when on the left of the screen, and appearing when on the right, hence the alpha). I also have to change sometimes the color of the notes.
I think I can't use standard "Animations" class, as it's an endless animation with the speed and the notes depending on real time factors.
So what is/are the best way(s) to do that and to achieve a smooth animation?
Different Views? (VectorDrawables?) Single SurfaceView where I manually draw each shape at each frame? (or TextureView?)
(Note: minimum API is set to 15)
Thank you for helping me choosing the right technique.
So you're wrong about the Animations class being infinite. It doesn't need to be. However EVERYTHING in Android will depend on real life factors- Android is not a RTOS (real time OS), there is no guarantee of execution time.
However, if you absolutely need total control, I would just jump to total control- hook the Choreographer so you get a call every 1/60th of a second, and each frame invalidate your view(s) that need to change and redraw them. If the phone is running slow for some reasons like other apps you may drop a frame or run slightly slower than 1/60th of a second, but this is as close as you can get (and what Animation classes use behind the scenes).
With animators you can animate smoothly around 5 different views on average phone. So in your case (with dozen of notes and so on) it will have around 10fps. So slightly better will be SurfaceView and handdrawing all that you want. Maybe GLSurfaceView worth considering.
In order to test this I recommend you to create some test app first, where will be 10 views flying around, and look at performance.
I don't know how to explain this.
But take Android desktop as an example.
When you move your finger, you move the whole desktop, until a point that you're on the next desktop. So as you can see, if you move the screen, for about 51% to the right, when you leave your finger off the screen, it will go to the right screen, and if you just moved the screen 40ish percent, it will be back on the same screen.
How is this pattern called?
Some sort of "predicting" users movements.
Maybe you are talking about the Location Within pattern:
Problem:
You must describe the location within a series of screens which
contain alternate views, or which continue the display of a set of
content.
Solution:
When several screens of similar or continuous information are
presented with an organic access method, an indicator is usually
required so the user understands their position within the system.
Other sources might call such a thing "carousel" or "slideshow".
Updated answer:
After reading more carefully, "Location Within" might only reference the page position indicators that show which screen is currently in view. Perhaps just the Slideshow or Film Strip patterns describe more exactly what you mean.
As FoamyGuy pointed out in a comment, ViewPager is the way to implement "slideshows" in Android.
Additionally, ViewPagerIndicator provides flexible options to display the page position indicators ("Location Within" pattern)
Say I'd like to make a memory/pairs game. I have currently made a draft that works on a Canvas, and cards are drawn into a grid.
This works for my current basic version, but I'd like show do an animation (when the card is turned, it will flip around and scale to higher size; or when the match is found, the cards would rotate around and then go back.
I can't imagine doing this on Canvas, I'd have to make a lot of timers and do the animation by hand, it seems overly complex for this simple task.
I think I could could subclass View for a control that would display a card, and then react to touch events for that control. It would also make drawing scaling of the images done by Android itself, and, most importantly, I could use Tween Animation for some effects.
My question is - would it be OK to use a View for each card in the game (I could have 5x6 or 4x5 cards), and arrange them in a GridView? Are there some pitfalls with this approach? Or should I continue with completely custom-drawn Canvas?
For such a simple game you should be fine using a collection of Views. As you mention using Views rather than trying to do it manually you get access to a lot of nice Animation functionality for free.
It also makes implement the user interface a lot simpler as you can just add onClickListeners to each view to capture user touches. If you're drawing it all manually to a Canvas then you'd have to interpret the touches yourself and decide which card was touched etc. While this isn't too hard, then I think subclassing View is a better model and will most likely result in cleaner code.
As you are only going to have 30 cards, then I can't imagine you having performance issues either - if you were thinking 100+, then maybe you'd have an issue, but I think you're fine. Also, if I understand your game correctly, the majority of your cards won't be animating most of the time so that's yet another reason not to worry - if you ever run into performance issues with the animations you can easily save off all the unanimated Views onto a Bitmap (Canvas) for the duration of the animation.
I'm working on a game that in some ways is similar to Tetris (imagine a 2D array of colored squares that sometimes move around)
I am trying to animate the individual squares so they will smoothly slide down from coordinate to the next. Since I wanted to use Android's built-in tweening feature, the animation has to apply to the whole View (rather than parts of it). This doesn't work well for me because I only want some of the colored squares to slide down, and the rest of them to stay still.
The (theoretical) solution I came up with to resolve this is to make 2 Views, layered directly on top of each other. The top view is for animating squares when they need to move, and the bottom layer is for the static squares. The animation-layer is transparent until I am ready to animate something. I then simply turn on the colored square in the animation-layer, tween it to the new location, and turn it back off when done. In the same time span, the static-layer just turns squares on and off at the right time to make the whole thing look seamless to the end user.
The proposed solution is just a theory, since I haven't been able to make it work correctly yet. Since I have been having trouble, I was wondering if this is even the best way to solve the problem? Perhaps there is a more elegant solution that I am over looking? Anyone know of a better way?
If you just want to animate a single element check out the namespace android.view.animation.Animation. You can also use Drawable shapes and draw them directly. Finally, if you want a simulation then you will have to look into threading. Basically you will create a timer to update the canvas for you based on an interval. There are some other view canvases you can use as well like the GLView canvas.
I'm fairly new to the Android platform and was wondering if I could get some advice for my current head scratcher:
I'm making an app which in one view will need an image, which can be scrolled on one axis, with a load of selectable points over the top of it. Each point needs to be positionable on the x and y (unlikely to change once the app is running, but I'll need to fine tune the positions whilst I'm developing it).
I'd like to be able to let the user select each point and have a graphic drawn on the point the user has selected or just draw a graphic on one/more points without user intervention.
I though for the selectable points I could extend the checkbox with a custom image for the selected state - does that sounds right, or is there a better way of doing this? Is there any thing I can read up on doing this, I can't seem to find anything on the net about replacing the default images?
I was going to use the absolute layout, but see that it's been depreciated and I can't find anything to replace it.
Can anyone give me some code or advice on where to read up on what I need to do?
Thank you in advance
This really feels like something you should be doing with the Canvas and 2D graphics, rather than trying to twist the widget framework to fit.