Develop Reference

What is the best approach for drawing and animating images on Android

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)

What type of layout and the user interface would be best for a n*n puzzle game android?

1) I am developing an android application for a puzzle that will involve n*n matrix displayed to the user. There will be objects(images) in each of these cells. Whenever the user clicks on the any cell the object of that cell should exchange position with one of the valid nearby cells.
2) When the object exchanges position, the movement should be shown to the user - the image slowly moving from its original place to another place.
If the animation above is very difficult to implement, please leave it. But I would like to know the answer for the question 1). Which layout would be the best for such a puzzle, which will involve constant re positioning of the child elements(cells).

If it's game - SurfaceView is your way. It's good idea, because you can draw from different threads and it's comfortable. If you want to create not simple game, use engine as example AndEngine. So you can use GLSurfaceView - openGL is very fast but it's not simple. And last way use simple view, but my opinion - it can be game like XO, barley-break and other not fast simple game.
upd:
If I create this game as in your case, I will use SurfaceView w/o any layouts. But I think you can do it with help standart view w/o surface. If your question about layout, I think its not matter. For example GridLayout. As minimum it sounds logical.
Good luck!

You would have a greater control if you create a custom view using the View or the SurfaceView.

I am working on a similar n*n matrix game and I am using the AndEngine game engine. It allows me to load images and then place them in an n*n grid.

Right class to wrap many dynamically generated images in android?

There seems to be a lot of classes, which provide a surface to draw on:
View
Bitmap
Drawable
SurfaceView
My application generates many pictures dynamically, by using vector graphics.
What is the right class to use, if my aim is to save the pictures, so that they are ready to be drawn into an ImageView?

The answer is described here, in the first paragraph:
- use Views for drawing static items
- use SurfaceView for dynamic and performance sensitive apps, like games

display transparent view over existing views

In Android 2.2, I want to display a few sprites and clickable animations over an existing view. I just discovered that SurfaceView cannot be transparent
I tried overriding dispatchDraw() of a LinearLayout but that doesn't seem to be callable via a Runnable Thread.
I also tried to extend Canvas directly, but that quickly turned into a mess when trying to place it in my XML layout.
Do I have to use GLSurfaceView to have a drawing view whose background is transparent?
Optimally, I'd like to just have a Canvas on which I can draw Bitmap at various coordinates, instead of dealing with the details of GL (unless GL is the only way I can do transparency).

Silly Rabbit. Just use Views and move them around wherever you want within a FrameLayout. SurfaceView is not designed for what you're trying to do.

I'm going to try Switching from Canvas to OpenGL and toss in parts of TranslucentGLSurfaceView.
I'm still open to selecting an answer that doesn't require OpenGL, just for the sake of it solving my original question.

GridView with images vs custom drawn Canvas for Android memory game

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.