I was messing around with libvlcsharp on Xamarin and the (fairly) new MediaPlayerElement UI on Android. For devices such as Android TV, there is no touch interface so you have to use something like a remote control.
For this case, I end up capturing keypresses in DispatchKeyEvent and send them to my app via MessagingCenter. I was wondering whether MediaPlayerElement can support non-touch devices automatically OR if not, what the best approach would be to handling keypresses in the app. I would have to "highlight" various controls of the MediaPlayerElement and then be able to select them when "DpadCenter" is pressed.
My questions are:
Does MediaPlayerElement already support non touch gestures? This site here seems to suggest it might with the comment that you can turn them off.
If it doesn't support them (and you have to roll your own), is there a programmatic way to highlight (e.g. change the background color) of the individual controls/buttons (such as pause or play) and invoke them?
Does MediaPlayerElement already support non touch gestures? This site here seems to suggest it might with the comment that you can turn them off.
If it doesn't support them (and you have to roll your own), is there a programmatic way to highlight (e.g. change the background color) of the individual controls/buttons (such as pause or play) and invoke them
You can override functionality for any control, so you should be able to hook your DpadCenter event and modify the behavior you expect of the player element.
It is on the roadmap to provide better docs for this https://code.videolan.org/videolan/LibVLCSharp/-/issues/309
For customization of the control, a similar answer was created a while ago: How to create LibVLCSharp custom playback controls in Xamarin Forms?
Do share what you build with it :-) We don't have any Android TV sample for this.
Related
Is it possible to change the behavior of native keyboard to float-able? I want to move the android keyboard to center of the screen. Is it possible? Or else I need to create a custom keyboard? I read this answer. But here no detailed explanation for why we can not move the position. I want to know the clear reason for why we can not change the position?
First- there is no "native keyboard" in Android. There's a default keyboard, which can differ by OEM. There's no one single keyboard app that you can assume is installed on all, or even a majority, of systems.
Secondly, very few keyboards support a floating mode. Its a pain in the neck to do, Android is written with the assumption that the keyboard will be a rectangle laid out below the app. You have to jump through a lot of hoops to do floating, using APIs that aren't well documented. Most keyboards don't do it. (What you need to do is play with a semi-documented feature called insets, telling the framework that you're keyboard has 0 permanent height but full screen temporary height and restrict the touchable inset to just the area you plan to take up so that other touches fall through. And since these features are all non-documented or poorly documented, really only the people who have studied them in depth will figure out how to do it).
Third, there's no API to force even those keyboards that do support it into floating mode. Android itself has no concept of a floating keyboard, so it can't tell a keyboard to float.
Basically, the keyboard API in Android on both sides is really bad. The original company that wrote Android didn't ever really think people would come up with all the great ideas for input that they have- they just thought it would be people supporting new languages and graphical skins. So they didn't make a great API. And for whatever reason, they haven't really improved the API all that much, or brought common concepts like that into the OS. Unless they decide to spend serious engineering effort on improving it, I woldn't foresee things like that changing.
We have an application which captures gestures (currently using the onTouch event callback, works great). Sadly, when turning on accessibility features on (such as explore-by-touch), only some of the fingers are recognized by our application. We of course have reasons to believe this is not due to a bug in our code. To us, the visually-impaired and blind populations are very important, and the gestures are even more important for them.
How can gestures be captured when accessibility features are enabled?
I haven't done this myself (disclaimer), but from the "Handling custom touch events" section in the Accessibility docs it looks like you'll need to implement a "virtual view hierarchy" by overriding getAccessibilityNodeProvider (assuming you have some custom views, or you're overriding onTouch in built in views, which has a similar net effect).
There is a good deal of info on the docs on that, and that works back to Android 1.6 via the support library. I'd look into all that first and get very familiar with detecting when the accessibility stuff is enabled and when it isn't, and react accordingly when it is.
I'm making a voice transcriptionist software and it would be nice if I could copy the UI and UI style that shows up when you use your voice to type on Android?
Here's how it looks if you don't know what I mean: pic of it here
What are my options in doing so? Does Google provide any kind of API or is there a way that I could steal this nice looking screen for my app? The point is that I don't want to use Google's voice search... I want to record the audio and send it off for humans to transcribe, but I like the UI a lot and would like to use a similar UI in my app.
I'm writing my first Android game, and though the game itself is working well, I'm not too sure about some of the Android integration aspects of it. Specifically:
Should I provide an in-game volume control?
Should I hide the status bar?
Is the Menu button generally used to pause the game, or should I provide an on-screen control for this?
etc.
Basically I just want my game to do everything the "standard" way. I don't want to frustrate users. Is there some resource (official or not) that lists recommendations for such things? Alternatively, can anyone give me a few important guidelines?
There are no official guidelines how to do this, but some 'Android common sense' would be advisable.
As usual, there is more than one way to do anything, but most of the apps seem to follow the following principles:
full screen games (especially ones in landscape mode) seem to hide the status bar most of the time
you should override the menu button, so it does not get pressed accidentally, but provide a quick way to leave the game
back button usually pauses the app
you do not need in-game volume control since all of existing android devices include a volume rocker, but make turning the volume off available as soon as the game (splash screen) starts, preferably give the person a few moments to turn it off before the music start (a 'would you like to turn the music down?' dialog would be nice)
an (as usually on android) don't count on anything and specify special game requirements (trackpad support, min screen size, ...) in the manifest file
hopefully you can find some more resources online
I am thinking of using Flex4/Air for developing an Android app. I want the app to have hover to play like ability. I mean if a video thumbnail is selected from alist of videos but not clicked it should play a 5 second clip just like in bing.com/videos. I am assuming this is the closest we come to "hover" in Android devices - please correct me if ths is not the case.
Does Flex4/Air have this capability? Otherwise can we implement hover-to-play ability on Android devices?
Appreciate any help/pointers.
Does Flash Builder 4.5 have this capability? No! I think you meant to ask does Flex 4.5 have this capability, but the question would be best stated: "does AIR for Android have this capability? If so, how can I access it in Flex?"
When developing code for mobile devices, I would take great care when implementing functionality based on a "hover" approach. However, you can take a look at these touch events:
TOUCH_OVER
TOUCH_ROLL_OVER
I thought a Long Press / Long Touch event may be what you need, but I couldn't find any documented one supported by AIR's touch API.