I'm a little confused over how key events (back key, volume keys) relate to Views in android.
Take for example the problem I currently have:
Working OK
Create Layout (for example, Relative layout)
Add View to Layout (A GL SurfaceView)
Run app and wait for everything to load (and for GLSurfaceView to be created)
Press home key
Re-launch app
Press back to exit
Not Working OK
Create Layout (for example, Relative layout)
Add View to Layout
Run app and press home key before GLSurfaceView is fully create/displayed
Re-launch app quickly again before GLSurfaceView is fully create/displayed
Wait for SurfaceView to be displayed
Although touch events work Keys no longer work and app can't be exited
why is this? Is there anyway to get focus back to this view? (if 'focus' is the correct terminology in this example).
I've tried
myGLView.requestFocus();
I've also tried various other methods but nothing seems to work - surely there must be a quick and easy way to make sure key events work with the currently visible GLSurfaceView?
Related
I have a main menu inside my unity game and for some reason when i build the game for android to run it on my phone the buttons does not work, but it's not disabled.
My scene objects:
My event system object:
Three things I can suggest:
First, make sure that on your button object, raycast target is deselected. At times, this is destabilizing the text of the button, hence making the button itself invalid.
Second, check to see if the EventSystem is working. From what I'm seeing on your screen, you might have disabled it or accidentally deleted its script while working on the scene objects. You can re-create it if necessary through GameObject>UI>EventSystem.
If these don't work, you can try the steps shown here:
https://answers.unity.com/questions/1115464/ispointerovergameobject-not-working-with-touch-inp.html
This is directly related to button objects not working with touch input devices. Hope this helps!
I'm experimenting with ways to do classical mobile game paradigm: a selector of levels, followed by a game screen.
I fully understand that there are plenty of ways to do that, but i was wondering about what goes wrong when i try this particular one (for learning purposes):
I have an activity, which holds references to my own GLSurfaceView child. On the activity start it loads a default 'level' and perfectly plays it. I can see Render thread started.
I implemented an OptionsMenu item, which after activation inflates a GridView with proper adapter, which allows user to select a level; and sets this inflated Layout to Activity by using setContentView. This is when GLThread dies.
Now i also implemented the OnClick's of that menu so that after click it loads a level in the game engine (works fine, btw) and brings back GLSurfaceView by using setContentView with saved (in 1.) reference.
And that's how i get a blank screen. Everything works fine, menu still works, i can go back to level selector, but in debugger i can see Render Thread doesn't exist.
Please, could someone explain to me what exactly goes wrong here? I'm totally not sure about this OpenGL intrinsic.
I do not understand the differences between when a user locks the screen (using the top screen lock button) and immediately returns to the application vs. when the user presses the home button and then immediately returns to the application.
It seems that all the same calls are being made. From my observations:
Called when home button or screen lock are pressed: onPause -> onStop
Called when application is pressed after home button or screen lock is re-pressed: onRestart -> onStart -> onResume
My individual problem:
This is particularly causing me greif because I am recreating a SurfaceView and a GLSurfaceView to a FrameLayout upon onResume, however, depending on the button pressed, the ordering of the elements is getting changed. I have the following code in my onResume:
cameraPreviewArea = (FrameLayout) findViewById(id.camera_preview);
cameraPreviewArea.addView(glView, glLayout);
cameraPreviewArea.addView(camprevSurfaceView, new LayoutParams(LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT));
This has the effect of displaying my glSurfaceView on top in the following situations: the first time the app has launched, and when the app is being resumed from being screen-locked and then screen-unlocked. However, upon pressing the home button, and then reopening the application, the SurfaceView is being placed ON TOP of the glSurfaceView!
If I switch the addView calls as follows, the opposite situations will occur. I could fix this with some boolean flag, but it it unclear where I would set the boolean because of my uncertainty as to the difference between a screen lock/unlock and the home button. Also, I do not want to solve the problem in this manner anyway because it seems hacky and lacks any real understanding of the problem.
Thank you in advance!
In general, there is no reason you should need to constantly add and remove views from the hierarchy of your Activity, and removing this code will make your application more consistent.
Since both of the views you are interested in are SurfaceView components, if there is some action that you need to take when the window becomes visible or hidden, you can take advantage of the SurfaceHolder.Callback to monitor the onSurfaceCreated() and onSurfaceDestroyed() methods.
This specific situation - using two surfaceViews and specifying their Z order within a window - does not seem to currently be supported by Android. This thread over at the android developer group shares the following information:
Multiple active overlapping surface views, of any sort, are not
currently supported by the framework. You may get them to work, but
it is mostly due to luck -- the view hierarchy does not define the
Z-ordering of those surfaces, nor try to ensure they are Z-ordered in
any particular way, so this may change for whatever reason.
Well... there you go!
...But for anyone attempting this I found a workaround: make your camera preview size a tiny 1x1 square. This will allow you to display both simultaneously (because a camera preview must be visible in order for the preview to continue) and ignore the pesky SurfaceView issues that the cameraPreview presents you with. I believe there is a better solution using strictly one GLSurfaceView, but it is not compatible below 3.0.
I have designed a menu that consists of a few buttons in several different LinearLayouts all placed over an animated GLSurfaceView within a FrameLayout. When the user clicks a button in the interface, I set the current layout's visibility to GONE before making the next layout VISIBLE When the user selects a level, then game play starts and all layouts are GONE (apart from a control bar on the right of the screen, but that is not contained inside the FrameLayout)
On most phones the menu works like a charm, but I did a quick test on an Xperia Ray only to find that I couldn't go anywhere because the buttons wouldn't click. I have Log.d tags set up in most of my onClick Listeners, and in this case they aren't showing in the Logcat so it doesn't seem like the Listeners are firing at all. I also noticed that the GLSurfaceView wasn't returning anything from it's own TouchEventListener. Even though the functions triggered by tapping the GLSurfaceView are disabled while on the top menu, I normally still get a message in the Logcat.
I thought it could be something to do with the way I have used the FrameLayout. The documentation says it should only have one child, but another article I read on android developers demonstrated captioning images by displaying text over ImageViews inside a FrameLayout.
On a final note, I'll also say that I've tested in the emulators and I found that both android v2.3 and android v4 display the same behaviour as the ray. Currently those are the only ones I am sure of, aside from android v2.2 which runs my app perfectly. I am hesitant to trust the results of testing on the emulators.
I am personally stumped seeing as there is no error message to go on, but can anybody suggest a solution?
I found the solution.
Turns out that I had a stray ScrollView hanging around in my layout that was both above my root layout in z-order and visible by default. Instead of toggling the visibility of this view, I was doing so for it's child layout. Oops.
On most devices I have tested on, the stray ScrollView has not effected the functionality of my app, probably because the empty layout was allowing buttons behind it to be clicked. However it turns out that some devices, such as the Xperia Ray, are a little more strict on whether clicks can be passed down through layouts (possibly a performance decision).
The ScrollView was a required part of the layout so I couldn't just remove it. Instead I gave the the android:visibilty attribute to the ScrollView so that it would be GONE until it is needed by the interface and it won't block the user from clicking buttons.
I am writing a PhoneGap app on Android. I am trying to stay pure HTML+CSS+JS, without calling specific PhoneGap APIs. So the app is somewhat an embedded web page, more or less.
The page has some "buttons" on it, which are actually table cells with some CSS attributes (among which cursor: pointer) and an onClick function.
I have noticed that when I touch a button, it "flashes" for a second or so, then its corresponding action is performed. By the way, I don't like this very much, since it causes a delay in the UI.
Some of the "buttons" activate a menu. I handle the menu by making visible a semi-opaque black div that covers the whole screen, and above it a centered div containing a table containing the menu items. (the black div and the centered div are hidden, normally).
The problem is that when I touch a menu item, it does not flash; one of the underlying buttons flashes instead (that is, one of those that at the moment are covered by the semi-opaque black div, and are supposed to be inactive). Nevertheless, the correct action is performed, in other words the onClick function of the menu item gets called, not the one of the flashing button .
So my question is two-fold:
1) Is there a simple way to make the right item flash (I mean the menu item instead of the underlying, semi-covered button)?
2) Is there a simple way to totally disable button flashing, so that the UI would speed-up and problem 1 be solved too?
Many thanks
You should be using the touch events, which are supported on Android WebKit. This will prevent the select + touch behaviour that you're seeing on your HTML elements that the onClick event causes.
Android versions past Android 1.5 support touch events such as touchstart and touchend. I recommend using them, and reading Apple's documentation (yes, I know it's weird, but Google's Web App documentation is still poor with respect to touchevents.)