I realize this is a highly custom implementation, but im porting a app over from IOS to Android that has these photos in a listview that the user needs to be able to fluidly whipe off in one fluid motion. The only thing I could find on github anywhere close to this was this: https://github.com/winsontan520/Android-WScratchView/tree/branch_image_overlay
but,this uses a surfaceview and when implemented in my listview its EXTREMLY laggy. I did a bit more research looking for something along the lines of a photoshop eraser and came across some stuff using canvas to accomplish something similar with a single drawing area , but im not quite sure if what I want to do is possible in Android and if spending the next day or two learning canvas would be a worthwhile investment or if im barking up the wrong tree. Is this the way to go to accomplish my goal?
SurfaceView is actually a Canvas implementation that has some native improvements like duble buffering, vsync and such. But using it in a ListView is an overkill.
I say take your chance with a custom view. Just override the onDraw(Canvas canvas) and draw whatever you want. Learning canvas is pretty easy if you have some basic graphics knowledge.
As an another implementation idea, If you don't need all of your Views inside the ListView interacable when scrolling, you can use static images in ListView and when user touched one of them you replace static image with SurfaceView and go on. This way you only need one SurfaceView.
Also did you used the ViewHolder pattern ( http://developer.android.com/training/improving-layouts/smooth-scrolling.html ) when implementing the ListView? Might help with the performance but I'm not sure if it can be implementable in your case.
Related
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?
Im experienced iOS dev but new to Android dev and asking some newbie questions here...
I have to make a app where I have a background image and I then place some other images on top of that, and also onto those images I have to place different "glow" images that flicker (opacity on/off), and I need good control on positioning all those images. Now there is not some high performance goal here, and its not many objects, its not really a game.
What is the best approach for this? Can I use ImageView's for this or will it be better to use a Surface and custom draw in a thread?
And please, what ever you suggest, can you give a link to a good tutorial on the approach (ImageView or custom draw), I need all the help I can on this project with its crazy deadline.
Thank you
Søren
In my experience:
if its mostly static you should stick to XML and stuff like ImageViews etc
if its simple animations, the predefined android classes are fine and somewhat easy to use
if you want real custom then drawing with canvas is the way to go
You can extend View and override the onDraw method or create a SurfaceView which has better performance but is not that easy to use.
(sorry i dont have any tutorial links)
I'm trying to create a simple Pegs game. I have drawn the 15-hole board using canvas. I have been programming a while, but games are new to me and I'm stuck on what to do when it comes to handling the pegs. I want to only use the touch screen, but it seems like it is really difficult to touch the pegs and actually select them individually. I plan on just drawing everything programmatically. What is best way on handling this? Using buttons as place holders and changing the button image? Any help would be greatly appreciated.
To be very brief, you have to keep track of the things you draw on the canvas.
I wrote some tutorials for making and moving selectable shapes on the canvas. They should help a lot.
On android it might be a little different than using mousedown, but it should give you a very good starting place.
I don't know if this will help, but you might want to write your own onTouch()function. Check it out
I'm just starting to get the hang of animations, tweened animations that is.
I have made several imageviews with pictures rotating and moving, and its all very fun, but I don't know what the best approach for doing multiple animations is.
For example I created a LinearLayout and stuck some ImageViews in it and wrote this:
RotateAnimation imgrotate = new RotateAnimation(0,360,
RotateAnimation.RELATIVE_TO_SELF,0.5f,
RotateAnimation.RELATIVE_TO_SELF,0.5f);
rotate.setDuration(2000);
someview.setAnimation(imgrotate);
someview.startAnimation(imgrotate);
for each imageview. So they all spin. But now I want to step it up a gear. But reaidng other sources on the net it seems some people use canvas to do animations. What is the best way?
There is no best way. You should use the simplest and most straightforward approach that gets the job done.
Canvas' are often used because developers want more specific control over how their objects are displayed on the canvas. For example, how an object gets displayed when it interacts with other objects or the user.
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.