I was wondering what will be the best solution or method to implement motion graphics animations in an android application .
Check out this website.
https://uxplanet.org/bringing-mobile-apps-to-life-through-motion-9472d259b58e
I want to implement same type of animations.
How can I do that?
What is the best industry standard to do this?
Should I be using After Effects animations and render them into android application or can I achieve this using Open GLES ? Which will be the fast and efficient way ?
Thanks
Design is no doubt an integral part of any app. Hence, design must also be taken in consideration along with the functionalities of the app. Motion Graphics in Android can be implemented in many ways. Android itself provides a rich set of powerful APIs to implement animations to various UI elements. For animations, Android has the 'PropertyAnimation', 'ViewAnimation' and the 'DrawableAnimation'. The Property Animation is a powerful system which can be used to achieve complex animations for both View and nonView objects. The view and drawable animations are a bit simpler systems to achieve simpler animations.
For drawing graphics in Android, you can use the Android Canvas or the OpenGL ES. OpenGL is an extremely powerful tool for manipulating and displaying high-end animated 3D graphics and can use hardware accelerated GPU. Please look into the Android docs for exact codes for implementation.
Now considering After Effects animations, they are really neat and perfectly fit the design aspects of the app. However the animations rendered by After Effects tend to be large in size and end up making the final app big in size. Personally, I have used AE rendered animations for my splashscreen and only a few other animations. Finally, it depends on your coding abilities since implementing complex animations using Android systems would be hard, whereas AE animations would make the app size large.
Hope this answers your question.
Related
I am making an Android app that requires a wave-like animation like this:
https://github.com/Cleveroad/WaveInApp/blob/master/images/demo_.gif?raw=true
As far as performance, would it be better to use this library (https://github.com/Cleveroad/WaveInApp) that is OpenGL based to have this animation, or use a .GIF (or some sort of series of images) in my App? It might seem obvious that OpenGL computations to create those waves would be more expensive on resources, but I know displaying a series of images in succession would be expensive too, so I would like to make sure. This app is being developed in Xamarin.Android if it makes a difference.
Most likely OpenGL will be way faster. Almost all of Android's views are built on top of OpenGL because it can use hardware for drawing operations which is more efficient than doing it in software. GIFS would be animated in software so would be slower.
I want to make a "2d game" using graphics from the ressources for the characters.
Now I'm asking myself what is the best solution.
I was searching a lot in the net finding the two different options.
A) Creating a custom view, adding it to the layout showing a AnimationDrawable or
B) Using the SurfaceView directly painting on it
Whereas a) is usually called slow and unperformant for games I tried to find a solution for b).
But so far all tutorials are only made with one image moving around on the surfaceView or animating geometric shapes (which isn't really what I had in mind).
Finding tutorials for "how to draw AnimationDrawable on SurfaceView" are very rare.
So I thought I might load all animation frames of my character into an array drawing each call the right one on the SurfaceView. But that sounds like a lot of overhead to me. Should I abandon the SurfaceView?
Has anyone a good idea what would be the best way to animate - lets say 10 characters + "background" on my screen?
You have (at least) three options:
Draw on SurfaceView surface with a Canvas. This will use software rendering and be relatively slow.
Instead of a SurfaceView, draw on a custom View with a Canvas. This will be hardware accelerated, with some limitations.
Draw on SurfaceView surface with OpenGL ES. This will be hardware accelerated, but you have to figure out how GLES works.
You should also consider (4) use an open-source 2D game engine and don't worry about what it's actually doing.
If you want an example, Android Breakout is a simple but complete 2D game written for GLES and GLSurfaceView. A more evolved set of EGL/GLES helpers can be found in Grafika, which uses GLSurfaceView, SurfaceView, and TextureView to accomplish various things. It also demonstrates the use of the hardware scaler to improve efficiency on larger displays.
Long description of the Android graphics architecture is available here.
Okay, I'm not sure this is the best option but I found a tutorial for using "Sprite Sheets".
http://www.edu4java.com/en/androidgame/androidgame4.html
So far this seems to be a good solution. OpenGL seemed a bit too much to me but perhaps I'm not good at Shader Language etc.
So if anyone finds a better solution, please let me know.
I want to implement a news ticker in my application, with vertical and horizontal scrolling, as well as some alpha animations.
I need the animation to be unaffected by the rest of the application (GPU/hardware accelerated). Especially since the application will be run on a Google TV box, and the user is expected to be using D-Pad navigation which can cause animation to become choppy.
These appear to be my options (I need to support Honeycomb and above):
Use the Android Animation classes
Will the performance of this approach ever match using OpenGL?
Is hardware acceleration possible, and reliable?
Easiest to work with.
OpenGL ES 2
There appears to be a limit to the texture size of 2048. If I have a headline longer than that
RenderScript
The documentation is sparse here.
In your opinion, what is the best solution? What other solutions are there?
One pattern that's common is to enable hardware acceleration, animate, then disable it. However, on the Intel based GoogleTV boxes there is a problem with text when you turn on Hardware Acceleration. I haven't tried it on an ARM based Google TV yet.
I am by no means an OpenGL ES expert, but I am a huge fan and have seen some wonderful things done using it for Google TV. That said, I think your understanding of OpenGL ES Textures is incorrect. The size of the texture should have little bearing on the length of a headline. I currently have an intern working on a bunch of OpenGL ES examples that we hope to publish by the end of August.
There is excellent sample code for working with RenderScript, even if the documentation is sparse. However some developers haven't been able to integrate RenderScript w/ d-pad navigation.
My suggestion is to try your worst case senario using OpenGL ES as a very short program and see how it works. It's likely to be the best solution.
I can imagine why your seeing choppiness on some GoogleTV animations, StateLists firing when D-Pading, but it's not an insolvable issue.
I am a fairly "newb" Android developer, and I would like one of my first projects to be a live wallpaper, however I am conflicted on whether I should be focusing on Canvas or OpenGL for it. Being new to this I know I should master Canvas first since it is easier to use, but I prefer to learn from real world projects that I have an interest in, even if it's a little backwards at times.
I have used both before in very basic ways, and I understand the general concepts to them, but I am not sure how they transfer over to the realm of live wallpapers. I figure that the full blown speed of OpenGL isn't required on a live wallpaper, since running it at max FPS would just run down the battery more than it necessary, but at the same time I am worried that using Canvas would cause lags and stutters when doing things like changing home screens.
I have been leaning towards using OpenGL ES 2.0, both to keep performance optimal and because my initial ideas for the wallpaper involve a lot of layering that I am not sure Canvas is capable of, but I'd like a more experienced developers opinion on whether or not all of the extra work involved in using OpenGL (especially in relation to live wallpapers, from what I've read) is worth it.
If you can get away with just drawing to a canvas (e.g. cube example in SDK), that's much less work. Because of the simplicity of the animation (no bitmaps), the cube is able to achieve a high frame rate without difficulty.
If you want to use OpenGL, you will need to use a supplemental package, such as GLWallpaperService, AndEngine, or RenderScript.
http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live-wallpapers
http://www.andengine.org/forums/tutorials/live-wallpaper-template-t258.html
Browse the Android source code to see how the stock wallpapers (e.g. Grass, Galaxy) are implemented using RenderScript. This link may work, but no guarantees: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.1.1_r1/com/android/wallpaper/ (then scroll down to the wallpapers)
Moonblink has discontinued his project, but if you're really keen, you can try researching his work (Substrate) starting here: http://code.google.com/p/moonblink/source/browse/wiki/Setup.wiki
I ended up using OpenGL as halfway through the project, canvas drawing proved to be too slow for what I was trying to achieve. Using OpenGL caused a massive performance boost. Unfortunately I had to refactor my code, so I would reccomend using OpenGL from the start. Dirty rendering is supported by OpenGL as well as the wallpaperservice's structure doesn't rely on the way you render things so you would still be able to create a wallpaper that doesn't drain the battery. Actually a well programmed wallpaper doesn't render when it's hidden. As the wallpapers shipped with android don't follow that pattern, live wallpapers now have the bad name of being battery suckers. Really a shame..
I want to create a simulation game and a main component of this simulation will be a 2D map (topographical/navigation map), which shall have different layers (objects are moving on the map, using of labels, you get it)
The question for me is now, shall I use OpenGL to accomplish this or is that not necessary? I have no special requirements apart of that the scrolling and zooming shall be smooth. The target platform are only Android tablets (so Android OS 3.0+).
Edit: To precise my question:
platform independence is not important for me
I'd like to go with the easiest way concerning implementation efforts
If and only if you're really targeting Honeycomb specifically, then don't bother with OpenGL... and I say that as a reasonably experienced OpenGL programmer who's done some cool things with it on Android.
My reasoning is that, starting with Honeycomb, the normal Canvas-based APIs are hardware-accelerated too. Typically the only real reason for using OpenGL was greatly increaased performance, but that is no longer the case.
Or so the theory goes... I've yet to see actual Honeycomb hardware and run comparative tests. What I do know is that the Honeycomb emulator shows triangular tearing everywhere, strongly suggesting the whole desktop is now going through the GL pipeline.
If you have solid experience with OpenGL go with it. If not try some performance tests before you really decide if you invest time to learn it or if you use the good old simple 2D canvas drawing...
I'm not an expert on OpenGL + android (or any other mobile devices), but I think you will get better results (more FPSs, better drawing and animation options, etc) using OpenGL.
If you're used to non-OpenGL android development and are new to OpenGL it would be easier develop the game without using OpenGL. But before you choose this option, be aware that it should be a better option to use OpenGL if you aim to achieve beautiful/good performance graphics!
In short, if you master "regular" android development and prefer to build something good enough in a short time, stay "regular". Otherwise, I advice you to go for OpenGL.