I'm developing an android game with the standard pattern of SurfaceView, SurfaceHolder, Canvas, etc. In this game I will be drawing multiple bitmaps on the canvas that I would like to know if they've been touched. I am aware that I can override onTouchEvent() for SurfaceView and could linearly walk through all my items to determine if the touch coordinates contains the area of one of my bitmaps, but I was wondering if I could make things easier on myself.
Here's my question:
Can I have classes which handle drawing my bitmaps on the screen descend from android.View, attach them to my SurfaceView and register click listeners on them so I don't have to go through the process of determining clicks myself? Will the click listeners be accurate if I am drawing the views (bitmaps) to the canvas myself?
Furthermore, would I suffer a performance hit from making all of my bitmaps android views by bogging down the android view hierarchy and making android do the work I didn't want to?
Thanks.
If you want to attach normal android views to SurfaceView then what is the point in using SurfaceView! You are given a SurfaceView so that you can draw on the surface yourself rather than having the android view system do it for you. So "you" have to keep track of your touches by yourself.
You can refer to AOSP Gallery2 code which is purely OpenGL based and incorporate its design on handling touches.
Related
I would like to display the score when user click on a button (make +1 fly to top of the screen) and I wonder if it is better to use a surfaceview or view?
See here for more information on the differences between SurfaceView and View.
For your case, View would probably be simpler and appropriate.
If your application does not require a significant amount of processing or frame-rate speed (perhaps for a chess game, a snake game, or another slowly-animated application), then you should consider creating a custom View component and drawing with a Canvas in View.onDraw(). The most convenient aspect of doing so is that the Android framework will provide you with a pre-defined Canvas to which you will place your drawing calls.
A SurfaceView, on the other hand, is not drawn on the main thread and instead takes place on a secondary thread:
The SurfaceView is a special subclass of View that offers a dedicated drawing surface within the View hierarchy. The aim is to offer this drawing surface to an application's secondary thread, so that the application isn't required to wait until the system's View hierarchy is ready to draw. Instead, a secondary thread that has reference to a SurfaceView can draw to its own Canvas at its own pace.
I think view fits this scenario better. You could translate a view to the top of the screen.
So far, I've only used SurfaceView for rendering background graphics. Of course you could do it using SurfaceView, but that would bring more complexity in terms of coding. You need to draw this "+1" and calculate its position from frame to frame.
Using a View, you could just apply an animation, set the duration, and that should do the trick.
I'm building an android game and this is more of just best practices and performance question.
For the bitmaps that I have that the user interacts with, should I place them in an imageView and set an onTouchListener for each of them individually or should I just draw them onto the canvas and use the custom view's onTouch method to obtain the x and y of the touch and see if it falls in the range of any of the bitmaps to detect a touch.
My custom view takes up the entire screen, and I don't know how if it is even possible to draw an imageview onto the screen using a canvas which is why as of now I just use the onTouch method.
Thanks for any insight.
Depending on how dynamic your bitmaps render will be, you should go for either GLSurfaceView or SurfaceView, for something simple as just bitmaps i would recommend you to use SurfaceView as "renderer" where you can get the canvas from and of course you can draw on the whole screen if your surfaceview match the screen size.
TouchListener should be completely separated handled on its own listener promoting encapsulation and reuse of code for future apps that you want to do. I've found this quiet helpful for the last games i've developed asingning a surface view as renderer and just creating Objects which takes the canvas as parameter and drawing them self into it, the only thing you have to take on count is the bitmap resource management, but if you are careful of releasing and creating them when is proper, you should have no problems...
Regards!
What is the best way to draw circles on a canvas that should have an alpha layer and change sizes? Should I use a View or a Surfaceview? The circles should also be clickable. And it should be smooth transitions when changing color size and position?
Should I put this in a runnable or use invlaidate in onDraw?
I would prefer that something like this also worked smoothly in low-end devices.
Any suggestions? I'm new to this kind of animations in Android.
If you are constantly drawing and taking user input at the same time, I would use a SurfaceView. However, if the only draw changes you plan on making to the circles happen when you touch them, then a simple View onDraw() override would probably do the trick. In the end it will just depend on what all is going on.
The point of the SurfaceView is to have that separate thread for drawing. If what you're doing could be in any way considered "game-like," then go for a SurfaceView; otherwise, stick with a View.
I say this because I'm currently working on a project with constant drawing using a View. The shapes that I'm drawing respond to touch and you can scroll through the View while it is still invalidating over and over. All this with a View and it still runs just fine on lower-end devices (I've only gone back to GingerBread, though).
Good luck!
I should also mention that in the project drawing in a View, almost everything has various alpha values and what not and runs fine.
I'm converting a project that I wrote in AIR a long time ago to native Android. In AIR, positioning views was fairly easy in x,y coordinate systems. With native Android though, I am trying to approach this in a correct way, but I'm unsure how to approach.
My view will consist of two circles in the background, with small objects within those circles that can roll around. There will be another view drawn on top of the circles to make it seem like there is glass over the circle, entrapping the small objects. The small objects are bound to the background circles.
I guess what I'm really asking is canvas drawing the best approach here, or is a view-based layout workable as well?
It sounds like your best option would be to use a SurfaceView. This is basically a hardware accelerated canvas. On of the benefits is that you can overlay standard widgets over top of it if you need to so you can mix and match custom and standard components. Here is a link to a website that walks you through getting a SurfaceView up and running
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.