I've been working on a drum machine app, and the latency between the time you press the button and the time the sound plays is unbearable. I have seen some people use multitouch and gridviews, and make several buttons able to be pressed at the same time, but I honestly have no knowledge of those. How could I set up multitouch or gridviews to reduce the latency?
I would guess the multitouchable buttons are a very custom implementation. You won't ever be able to touch two ordinary buttons simultaneosly, since they are made for single touch and are based on focus gain etc.
Here's my idea behind a multitouchable implementation:
You create a very custom view which will draw all buttons you need. This view should override onTouchEvent and react on multitouch. I never tried that, but this is the only option I can think of.
Related
Is there any way of disabling / enabling the touch events in a certain activity
without disabling certain buttons. like if the phone is "frozen" on a certain activity page for limited time?
I need that the user wont be able to go back on page, slide out or any other events.
Is it possible? (I'm using android studio, java)
Thanks in advance!
Any answer would help :)
It's possible.
Actually there is no special function to make it.
To make it, you can make a full screen button with transparent background.
And you will define a function of the button.
Of course, it will be an empty function.
Well, you can do nothing on the screen.
and then you can hide or visible the button according to your necessary.
I'm developing an app for iOS and Android using Corona SDK and have problems with managing native textFields in Android.
I'm trying to achieve the following effects:
tapping on textfield will animate its sliding with keyboard so it will be always on top of it while moving up.
Tapping on back button will dismiss the keyboard and slide textfield back with it
My problems are:
To know the height of the keyboard in order to know where to stop moving the textfield.
To catch back button tap in order to eliminate the textfield
What I am doing:
I've looked over the Internet to find out how to check keyboard height on Android. All solutions assume we have Activities.
We have registered onKey listener to catch back press in corona code, but it is not fired if keyboard shown.
Ok so I made this Draw & Guess Online game and I used Native TextFields as well. What I did is just set my device resolution to lets say 600x1024. Then I just tested on a few different devices, and just eyeballed where the keyboard was located. I'm afraid this is what your going to have to do. Just use a for loop to make around 10 small rectangles and print the pixel values next to each of them. Then take your test devices, and see where the keyboard lyes on each device. Then just animate them up.
There is no easy way to do it in Corona unfortunately. Also people could have custom keyboards which would make your life even more difficult. All I can recommend is to over estimate and release.
I basically need to find out if there is a way to capture movements or keystrokes of a game such as "Angry Birds" etc using the touch screen of an Android and save them to a file on the device.
I'm sure these phones have security issues and don't want native "keystroke logging", but if it's a layer that sits over the other game, it should be ok
Please let me is there any way to achieve the same. Your help would be appreciated. Thanks In Advance
You can cover the screen using a System Overlay, as shown in this answer.
However, keep in mind that either you can consume all the touch events, or you can let them through. You cannot first take the touch events, and then pass them onto the app or View below you.
Additionally, if the device has on screen system navigation buttons (home, back and recent apps) the overlay will not cover these.
I know this may not be an appropriate question, but I want to know how a touch enabled OS like
android detects a button in an app and calls the appropriate handler? When programming an app we just give the alignment information of a particular button. So, how android keeps the mapping between a button and screen position? I think this is kindof dynamic because if you change the screen orientation or use zoom or something like that the button positions are changed dynamically. So, android must look at the touch position and decide whether a button is there or not and call the appropriate handler. How this all things put together?
I appreciate any reply.
I'm making a game in Android and I'm trying to add a set of menu screens. Each screen takes up the whole display and has various transitions available to other screens. As a rough summary, the menu screens are:
Start screen
Difficult select screen
Game screen.
Pause screen.
Game over screen.
And there are several different ways you can transition between screen:
1 -> 2
2 -> 3
3 -> 4 (pause game)
4 -> 1 (exit game)
4 -> 3 (resume game)
3 -> 5 (game ends)
Obviously, I need some stored state when moving between screens, such as the difficulty level select when starting a game and what the player's score is when the game over screen is shown.
Can anyone give me some advice for the easiest way to implement the above screens and transitions in Android? All the create/destroy/pause/resume methods make me nervous about writing brittle code if I'm not careful.
I'm not fond of using an Activity for each screen. It seems too heavy weight, having to pass data around using intents seems like a real pain and each screen isn't a useful module by itself. As the "back" button doesn't always go back to the previous screen either, my menu layout doesn't seem to fit the activity model well.
At the moment, I'm representing each screen as an XML layout file and
I have one activity. I set the different buttons on each layout to call setContentView to update the screen the main activity is showing (e.g. the pause button changes the layout to the pause screen). The activity holds onto all the state needed (e.g. the current difficulty level and the game high score), which makes it easy to share data between screens. This seems roughly similar to the LunarLander sample, except I'm using multiple screens.
Does what I have at the moment sound OK or am I not doing things the typical Android way? Is there a class I can use (e.g. something like ViewFlipper) that could make my life easier?
By the way, my game screen is implemented as a SurfaceView that stores the game state. I need the state in this view to persist between calls to setContentView (e.g. to resume from paused). Is the right idea to create the game view when the activity starts, keep a reference to it and then use this reference with setContentView whenever I want the game screen to appear?
This question has been asked a lot. Did you read these other posts?
Android: What is better - multiple activities or switching views manually?. This link in particular talks about the Android Design Guidelines which "don't mention switching Views at all; it's centered around an Activity-as-View design."
Android - Should I use multiple activities or multiple content views
Android app with multiple activities
How to pass the values from one activity to previous activity
I'm not sure what you mean by the back button not always going back to the right screen correctly. I've got a game with a similar structure to yours, and the back button always takes the user correctly up the chain of activities.
Furthermore, using the onResume, onPause etc is somewhat necessary. What happens to your application if the phone rings? (Yes I know, some people still do strange things like using their phone to receive calls! :P) The OS tries to call the onPause method in your activity, but if that isn't implemented then your application won't act as expected. Another useful thing with onResume is it lets you update your tables as soon as the user returns to the view. For example, your player has just completed a level and is then brought back to the select difficulty screen. If you simply recover the previous screen from memory, it might not have been updated to take into account that a the level was just completed. However, if you put some code in onResume to handle that, then that will always be executed before the player sees the screen.
Lastly, you say transferring data around activities is a pain with intents - yes, that's probably true. But I usually find transferring any kind of complex data a pain, no matter how you do it. Are intents really that much worse, or is it just that things aren't as easy as you'd hoped? I don't mean any offense with that; I also often find things which intuitively seem easy to be rather frustrating to implement in code.