I come from a non-GUI and lower level programming environment. I have solid experience in OOP programming and algorithms, but the projects I worked on did not have any impressive user interfaces, hence my post here.
I want to understand how the graphics are updated in a mobile app.
For instance, let's take the basic example of a classic wall clock, with second, minute and hour arms. The Wall Clock app will move the seconds arm each second, likewise the hours arm each 60 mins, and minutes arm every 60 secs, problem I have is that I just cant wrap my head around creating these moving parts in an efficient way.
Am I supposed to save images of all possible combinations of second,minute and hour and just morph the 3 and display the appropriate time each second? Or is it a better idea to have the background image as a non dynamic entity, and have only the "seconds, minutes and hours" arms rotate? If this is the case, when I package my application, I will have to also include 60 + 60 + 12 = 132 images (60 images for seconds, 12 images for hours and 60 images for minutes), is this correct? If it is, this seems awfully inefficient...
Just to kind of give you an idea of what I am having problem understanding, consider another example that requires updating the graphics each time microphone hears varying noise levels: Assume that I want to create an app that measures the sound levels in an environment and it shows the dB measured from the microphone on a volume bar. If there is a song playing near the microphone with varying noise, the sound level indicator will move up and down. I understand how to update the noise values to the command prompt, serial window, or a TextView box, but I don't get how to update this info graphically.
I may be wrong, but think I must have a volume bar image that is just empty(as if the noise is at zero) and in the program, I fill this volume bar according to the dB levels acquired from the microphone, but then how can I fill the volume bar in real time depending on the noise level seen by the microphone?
These questions I have are not just Android specific, I'm sure the same approach to updating a Wall Clock app is also used in Windows application development, so I feel like if I have a good understanding of GUI development irrespective of the environment, I may be able to tackle these silly questions with ease; perhaps you can also direct me to a good book on GUI development in Java or C/C++.
For your clock example: you would not generate images for every position a clock could be in. Your app would be HUGE! You would instead make images for: the face of the clock, the minute hand, the hour hand, and the second hand. You could then take the time and calculate the angle of each hand of the clock from some standard point on the clock (this could be any point you want). You could then rotate each image to that calculated amount. This would make the clock appear to have its hands pointing at the right time.
I don't know very much about audio bars, but it would work in a similar way. Make a formula to calculate where/how large the bar should be. Then draw a bar stretched to what the formula dictates.
GUI and custom drawing can be achieved in many different ways, each have varying efficiency.
How to draw?
For example, if you want to show a cartoon character walking, in most cases you need to store each frame as image and redraw it, probably on every tick or second.
But for wall clock, you don't actually need to
Store so many images for every possibility because you can put single arrow image and rotate it
Store any image at all if you can draw it procedurally by defining its shape
Suppose you have a canvas on easel that you can draw whatever you want on it. You can choose which order you want to draw. For your wall clock example, you can first draw your background (numbers / hours) and start adding minute hand and hour hand on top it. This is called z-order.
Operating system libraries gives you widgets that you can interact with it. Canvas (picture box) is one of them and you can to draw whatever you want that you to build your custom widgets and of course Android has this too.
Android has Views and each view provides an method that you can implement your custom drawing logic:
// Implement this to do your drawing.
// Parameters
// canvas the canvas on which the background will be drawn
protected void onDraw (Canvas canvas){}
A very crude wallclock can be implemented with just using:
canvas.drawLine(float startX, float startY, float stopX, float stopY, Paint paint)
Beyond this, we can basically apply OOP concepts in GUI programming too. For instance, you can define every thing you want to draw as an object that implements a common drawing method. This is widely used on 3D game programming as usualy 3D rendering engine manages every object and asks them to draw themselves if "camera" sees them.
When to draw?
Normally this is up to operating system. It draws elements whenever it is required. However, for game like applications and for custom animations you might need to manage this by yourself.
On most operation systems, you can use seperate threads, a timer, an infinite loop or a notification event to force redraw your screen. You can achieve this redrawing with postInvalidate method on Android.
But not every environment is easy. For example, your application might need to redraw itself 30 times every second and depending the operation system and environment, you might need to acquire locks to display your UI updates correctly and might need to make your thread sleep to achieve desired framerate without keeping CPU busy. (This is used in SDL library.)
Android has an animation class to tackle common tasks.
Thing to remember
Reusing widgets that OS gives you is a good idea. You can implement a dB meter by just using a progressbar.
I'm looking to create a drum machine in ActionScript 3 (as an Adobe AIR Android app), which will keep to a user defined tempo (BPM).
I am struggling to find a way to keep the project in time, I have, at the moment, made it so that 5 different sounds are represented in rows of 8 squares, and the user can click each square to choose when to play that sound (hope this makes sense).
At the moment I am using Timer to keep the project in time, which is very laggy and inconsistent.
using timer is a bad idea for this, there I said it...
The issue is that the timer has a drift and fires several milliseconds later.
Try a simple test where you have a timer that executes every 500ms, and then compare the getTimer() count. What I have found in my experiments that the timer is continually off and it looks like it doesn't self correct. I've tried using a self-correcting timer, that changes the firing time based on the getTimer() difference since last run, but it's still not reliable. and anytime your processor's load picks up, the timer will be off anyway.
The correct way of dealing with this is to use byteArray data as a source for the sound. Based on the calculation of sampling resolution you can populate the stream with the data in advance, and the sound will play on time, pretty much guaranteed. I haven't gone as far as to create something that does this myself. But there are several libraries that you can utilize that can help you with this.
My top two decremented libraries are SiON and tonfall
you can see a sample of SiON here http://wonderfl.net/c/qf4b
and tonfall example at http://tonematrix.audiotool.com/
While I haven't tried them on android, I think either should work
More specifically, is there a way to check the frame rate of an animation?
I am asking this because I would like to let the user know if his device is too slow for an app for which the smoothness of animation is critical.
I've always used the classical approach of yanking the time at the beginning of the render process and the end and then find the differences. Is that not enough for you case?
Frame rate is going to be highly dependent on what your are rendering and your code will presumably be calling the render methods so a timer seems the most direct and correct approach.
I have an Android app that uses the LocationListener to determine the speed the car is going. Currently I show the speed by updating a TextView to show when the speed changes. I am now trying to use images of digital looking numbers to show the speed to make it look more like the dash of a car. I show 3 different ImageViews next to each other and when the speed changes I change the image to the correct number using the setImageResource like this:
speedImg.setImageResource(R.drawable.dig_1);
When I try the app it works fine for a few minutes but then eventually the phone becomes non-responsive and none of the phone buttons work and eventually Android gives me the option to force close. I can only test it in the car so I am not able to debug.
Is there another way I should be changing the image to make it more efficient? I have also thought about reducing how often the listener gets called but didn't know how many meters to set it to still get an accurate speed of the car.
Most probably you're doing some long-running operation in main UI thread. You could give StrictMode a try to detect such things.
I have a game out on Android, and it runs in a single thread. Performs the work in run() and the draws in onDraw(). Pretty simple.
However, on a Droid it runs much faster than on a G1.
What is a best practice for ensuring that the game runs at the same speed regardless of the device?
This is typically controlled by the combination of using a "game loop" ( http://gamedesign.wikicomplete.info/game-loop ) where the code loops around and draws frames with a timed interval. When using different devices, frames may take longer to draw so this is typically dealt with by either dynamically adjusting the "level of detail" (LOD) and/or using "frame skipping" whereby you don't draw a frame every loop. In fact there's another question that demos a basic algorithm for this:
Allegro 5 game: game loop that runs at constant speed?
-Oisin
Running faster is usually a good thing! The best way for ensuring the game runs correctly on any device is to base your updates on the time passed since last update. This keeps the game feeling consistent when running on a faster device.
Otherwise you could add a sleep call on the faster device - but why not run smoother when you can.