I'm creating an application that relies heavily on property animations for Android 3.0. I have it working, but there are significant slowdowns in certain parts. I believe that multi-threading the UI would help a lot. Naturally, you can't really do that with Android's design. What I was wondering was, is it possible to use render my View objects in a SurfaceView and use the property animation framework that's already in place? I've seen examples on drawing objects using the Canvas class, but I don't want to re-implement all the animations when it's all right there. I haven't seen anyone use any of the Andriod animation (frame, tween, property) in a SurfaceView.
Android animations don't work in a SurfaceView, you have to do them manually with a secondary thread. It's not so hard, but you will need to rewrite almost everything.
If you use a lot of animations (like in a game) then you should really consider switching to a SurfaceView because it's way faster (and is the only way to get smooth animations in this case, since you probably hit the limit of these built-in animations, which have a lot of overhead). If you don't switch now, it will be even harder later...
I can provide you some samples if you decide to go this way.
Related
this question is more for looking advices
I've developed an almost full user interface in pure c++ and opengl es 2, currently I'm developing that the click/touch events be propagate as in HTML, I can't remember why I decided do a UI in opengl, but now I realize that I'm reinventing the wheel.
so currently I have many "elements", buttons, containers, scrolls, pictures, animated pictures, borders, text, drag-drop's, I can set easily where I want each element, set sounds, and I really don't know how fast and effective it is right now, but I've maked all the fast and memory effective that I can, and I planning to use multi-threading in the future. And my goal is to approach a system like html.
And now that I'm looking for how to implement my UI in native Android (java), I realized that I was in the correct way, all the properties and methods all the structure I'm implementing in c++ and opengl is almost the same as in android, even I think my implementation is easier to use the images and sounds because I've automatized all and I can put it in the assets folder, and in the code only put the name of the file and the program returns it, with and effective memory managment.
the current elements are elements that I need for a game interface, so if I need other kind of element I'd have to write it, but right now, I have all elements that I need, I think so.
maybe my code in c++ is faster than java.
but even with all this, I know I have a lot to do to have a full UI, so can you give some advices or experience, advantages, disadvantages, it worth to continue with the UI, or better learn (beacuse I just know a llitle bit of UI Android) UI Android, modify all my game for use the new arquitecture/system, What do you think?
This may be a duplicate question, but none of the questions I found were exactly what I had in mind.
A friend and I want to create an App that lets the user play around with 3D objects on the screen. My friend is creating the objects and the animations in Blender or Maya. Therefore, the possible animations will be preset (not being programmatically animated). I have no experience in 3D programming and I naively suggested that he render the animations in Blender and send me all the frames. I would then play the appropriate animation by quickly running through all the frames. Each animation would leave the object in its original position so that it would be ready for the next animation.
Now that I've been thinking about it, that's a lot of images that I have to store in order to make this work. For every object, I would need to have all its frames for all of its animations, which maybe overkill.
Is there another way to play animations in an Android app? I considered just saving the animations as videos and playing them, but that would look horrible for our purpose.
I'd suggest min3D
Take a look at the animated troll example they have.
There are a lot of 3D libraries for Android. I would recommend AndEngine. Alternatively, you can just use the native OpenGL compatibility. Instead, ask him to send you the actual 3D files. Then you can use a library to render them.
EDIT: I just found this link. It'll probably help you. In my opinion, you should go through it and learn the whole package instead of just glancing a bit for this one little project; it'll help in the future.
Yes, there is a way you can manupulate the models you created in Blender. here is an example which uses Open GL in android to animate a 3D model created in Blender Check This Video Out. However it animates the object programatically, frame animation is indeed not worth if you wanna create animations that are long as you will run out of memory quick.
I'm new in Android development and I have been making a tutorial for a game example which tells that using a layout file is not necessary because of the flexibility need on game development. However I've seen on Android docs that using a layout file is always the best way for Android development.
I'm sorry if my doubt looks obvious or kind of weird, but I'm really newbie and I'd really appreciate if you guys give me some help.
Most Android Games will use a Surface, Canvas, or GL Surface view to render all content to the screen. This element is likely to be fullscreen as well.
And so all drawing of UI and buttons and game elements are drawn directy to the surface, bypassing the use of Android's many UI views.
There is no reason you game cannot use android UI views in addition to using a surface for drawing the game action itself.
And of course you will likely use layouts as well when integrating things such as Admob ads or user dialogs within you game. So in practice you will use both.
But a standard utility application built in android will use layouts almost exclusively.
As a final aside, it is not necessary to use layouts. Every view type can be created either through XML layouts and inflating the views, or by instantiating a view in java code. the main reason for using layout files is because they are fast to build easy to use for a large category of interface design. But he choice to use them or not is your own.
A layout is used for arranging views. If you're not using any views (i.e. you do all the drawing yourself), then there's no point in using a layout.
For game development you are better off not using a layout file. The tutorial you are following is right. You will probably want to draw directly to a GL Surface View.
Personally, I forgo a lot of the features of the Android framework when doing game development. I use one Activity to bootstrap the game and get it running, and I draw to one GLSurfaceView. A lot of Android game dev tutorials follow this approach, and so are probably going to be a lot more useful to you than tutorials for more traditional Android apps.
I'm thinking about writing a pretty basic game, which mostly involves sliding images around on the screen when tapped. So tap an image and it slides to one side. Doesn't seem like Android Animations will help me here since those don't actually move the images, just makes it appear moved.
So even though this seems like pretty basic functionality, it seems like I have to write a game loop,etc and implement my own code to handle the "animation" (including some acceleration/deceleration), etc. Not hugely hard or anything, but just seems like overkill. Also using a 3rd party game engine also seems like overkill, just in the time it would take to learn that, and so on.
Am I off base here?
If anyone has any suggestions that might get me pointed in the right direction (links, etc) that would be great. Is there a good way to use Android Animation functionality in this case that I am missing?
If you are developing for Honeycomb, it may be as easy with animations. With Honeycomb, there is a whole new strategy to animation. Check out the blog. The premises is that any property or value can be animated, and that includes the view's actual position (and not just look like it moved).
I have built a couple of games using AndEngine (http://andengine.org) I would recommend it for making games for android. And since it is all written in java, it is relativiely easy to integrate it with layouts and other activities.
What considerations should one be mindful of when constructing a GLSurfaceView-centric UI?
This is for a game and the bulk of the UI will be an intro screen (start, options, about, exit) and a level selector screen. I've put a lot of time into the rendering/animation for the game using OpenGL, and I'm no graphic artist, so taking the OGL UI route seems to make sense to me. But I'm an Android novice and need some outside input. Thanks for reading.
There is nothing wrong with that, especially for a game. The only problem is that you will have to do everything yourself. Most games seem to be doing this.
Due to the ease from which one activity can start another, I would say it is worthwhile to abstract your options and level selection from the game itself. If you're unfamiliar with starting activities and/or passing information between activities, there are plently of good tutorials and examples to help. You could try the ubiquitous Notepad tutorial if you haven't already ( http://developer.android.com/resources/tutorials/notepad/index.html ).
The advantages of this method would be to leave your OpenGL/game Activity less cluttered, and that you would be able to use tried-and-true Android UI elements instead of building your own from scratch.