I currently have an android application that utilises the native android views for the UI (e.g. imageviews/buttons etc)
Although this app is not a game, nor requires any heavy graphics or OpenGL, I would like to incorporate a little physics-related interaction. Nothing too significant but maybe display minor collisions/bounces, deceleration/acceleration or possibly friction.
Is this possible to simulate either within the android framework or using an external physics library like jbox2d without having to utilize an entire game engine (like andengine, libgx etc).
P.S. this is for API 15+
Thanks all.
As long as you can set/update the position of the UI elements every frame (e.g. with View.setTranslationX()), you can do it.
Animating the UI by hand would mean keeping a mapping between the UI elements and the physical (e.g. jbox2d) bodies that correspond to them. Then you update the respective positions of the UI elements to what the simulated bodies have each frame (such as body.getPosition()).
In event-driven apps, something like a Timer object is useful for scheduling the physics updates.
The easiest way (not that flexible) is using ViewPropertyAnimator.
With it you can animate properties even in parallel. Maybe you want to change a view margin from the parent left. You can change that margin there, setting up the time to move and else. Some examples on this blog
ValueAnimator is other alternative, which uses the AccelerateDecelerateInterpolator by default and you have to provide the code that changes the property you need. This official guide may suffice to get them working.
what you want is quite impossible - your options are:
you may fake stuff like bounces with animations
you can implement a whole new ui lib
you use openGL what i would do
I think this can be achieved, at least at some point.
You have access to a pretty complete Animations API. This last, together with some view bounds, distance, and probably device orientation calculations, can be used to simulate almost all the cases you mentioned.
You can create Accelerate/Decelerate, form change... and almost whatever animation you want.
How you can achieve what you are asking for:
Having different animations, one after another, creating and applying them dynamically depending on the view item state. And by state, I mean the "physical state": falling, collisioning, in touch with another view, and so on...
Related
I have a base layout that holds several views. I need to translate them along the x axis. Basically there are 2 types of translations happening the one that follows the finger all the way and the one that stops after certain threshold which gives a nice parallax-like effect.
So is it better to put the group of views that share same translation logic inside another container and translate the container or translate each view individually?
I know this might sound weird but Google always recommends to use flat view hierarchy because nested layouts are expensive to redraw, so does it mean that keeping just one layer of nesting and translating each view by hand is better?
Also this translation is applied to all the views in the RecyclerView, not just one.
I think you should keep a flat layout as Google recommends, and translate each view individually. I would create a custom view were you can set a threshold. And once set, you can simply pass the x position of the finger to them all, and they'll decide if they should move or not.
How to implement it requires more input or requirements before giving any suggestion. Besides performance problem, code maintainable should be considered too.
Base on my experience. With high-end phone and high API level (about >= 21), they have better hardware, effective way to manage memory and background task. The problem expensive to redraw you mentioned seems not too important with some simple animation. In this situation, code maintainability has higher priority, I will decide to have an extra FrameLayout container, wrap the View which have the same animation because you have less code => less logic. 0 or 2 FrameLayout have no noticeable difference in performance in this case
About low-end devices, if you want to target lower API users, performance becomes a top priority. Now both cases you mentioned have the effect on performance, one requires more memory to store more View and one requires more CPU to run animation. It's time for a trade-off. In your case when you have 2 translate animations run on any item in RecyclerView, I prefer to create 2 separate animations run on 2 View. This way I can save a bunch of extra containers => save memory, the animation is not run for all of the items so it only affects the CPU for a small amount of time during animation.
So to sum up, You have a different approach for each case, choose a top-priority for the case you choose, improve it, sacrifice the others that have less effect on the overall problem. No solution is 100% perfect, trade-off situation always happens when coding
I'm making a board for Android. I use .png images for the board (background) and checker pieces. Basically, it's a game where the graphics are updated upon touch events. It's a school-assignment so I have to use View implementations. For the graphics I've considered two options:
Making a whole "BoardView" class (that extends View) and draw all the graphic components directly on the canvas using onDraw(canvas).
Using ImageView objects to represent each checker piece and the board and putting them on a Layout.
My intuition tells me to use the first method. But my thoughts are that I want to use the pre-implemented TranslateAnimation when a checker is moved. From my understandings; this forces me to use the second method, since I can't animate a Drawable.
Now, to the question: what method is best for me? And if the second; which Layout is preferred to use? I want to be able to overlap the checkers over the board image and compare the ImageView objects' positions to each other to determine where to put the checkers on the board.
Regarding to your simple requirement, I think you can adopt method 2.
Trust me, I have done this kind of stuff years ago, on a legacy linux platform. For these kind of simple game applications, you really do not need to bother with all the frame drawing stuff. Just stick with the existing UI widgets.
This is because the visible elements are all very simple, like cards, static images, blocks etc. You don't need to perform pixel drawing. I have tried to make tetris, mine sweep, and card match games. I even create simple visual effects for it using existing animation facility. That is very easy to do so.
And, of cause, as a software programmer, to write a game using the typical frame by frame approach is much more professional. But it depends on the requirements. Why not using less code to create more value?
I have some game pawns on a screen inside of a RelativeLayout. When the user clicks the pawn I would like then to be able to drag it under there finger. I have the MotionEvent captured but can't seem to find how to adjust the orion of the pawn.
I've seen posts saying to adjust the margin but that seems questionable. I still want to do hit tests for the pawns after they've been moved and don't understand how to work with the margins in that case.
thanks!
I would recommend not using a Relative Layout at all.
A Canvas is a much better option
Or if you really want to use a layout, possibly an AbsoluteLayout is a better option
Using a layout for a game may prove unsatisfactory as you proceed. I can recommend using the free and open source game engine AndeEngine for making 2D games. The problems you have with collision detection and x,y positioning are trivially easy to implement with it. I've made 2 games and a visualization view within an app with is so far.
Check it out here:http://www.andengine.org/
You can download the demo app to your android device and see its out-of-the-box capabilities. (They include Sprites, sound, animation and more.)
This one game I made with it.
https://market.android.com/details?id=com.plonzogame&hl=en
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 need to synchronise two AnimationDrawables (using frame animations setup in xml). The developer article on AnimationDrawable speaks of no such thing, so I would like to know if it's even possible, and if not, how I could get the same effect using a different object perhaps? The two drawable objects are the same size and have the same number of frames, with the same duration between each frame.
I ended up merging the animations together manually then played that one animation instead. It appears that it isn't possible since there is inevitable delay at some point (thread switching, etc).
For anyone else wishing to do this, I advise you take the slow way and redraw the animations you wish to combine and then play the one animation.