I was looking at my application (designed for 1.6) that uses the DatePicker controls on a HTC Desire the other day, and the owner of the phone showed me the native calendar program which uses much much nicer controls, i.e. the datepicker you can touch and scroll rather than having to repeatedly press the buttons to adjust days/months/year.
So my question is does anyone know if these sense controls can be automatically used in place of the stock datepicker controls? I would ideally like my app to run on older devices i.e. 1.6 but show the nicer UI elements if running on a device that has the sense UI.
Thanks
Well unfortunately it appears you can't. Maybe if you know the widget classes you can use them but as for packaging them up in your app so you can rely on them being present in every phone you install on.. not a good idea... as you can't guarantee they'll even work on all devices...
Related
I've been writing an new app for our company and came across an odd thing. On the test device (running 2.3.x) the alert dialog buttons will always be in the order of:
POSITIVE | NEGATIVE
Yet, when I tested the app on my personal cell (running 4.x) the alert dialog buttons were switched to:
NEGATIVE | POSITIVE
The code is obviously the same.
I don't really want to make different versions. But I could cater for later versions in code, and maybe (although its rubbish) swap the text of the positive and negative buttons... Which would work, I'm guessing, but it's a bit horrible!
The only problem I can foresee, is that our end-users aren't that tech-savvy and having multiple devices, using differing versions of the OS, could cause issues (which I could easily cater for, but would rather some kind of 'standard').
Is this something I can get around? Or is it best to leave as is and let the OS handle it (as I am doing now)? Also, are there any other small issues I'm going to run into. I.e. Can I guarantee that on 4+ devices that if I'm only using 2 buttons that they will remain in the above order.
What I'm hoping someone will post is a hidden flag that magically sets 4.x alert dialogs to 2.x style :) I'm pushing my luck, I know!
Cheers. Any help is greatly appreciated.
It's an interesting piece of lunacy from Google (see issue 24138) but, as of ICS, this is how it's supposed to be. Definitely best to let the OS choose the ordering.
If you wish to have it the same for all versions, you could potentially check which version of Android is being run, and change the negative/positive buttons yourself. I don't recommend it, and people will expect it to like it is on their device, don't shoehorn everyone into having the exact same flow.
I want to add black padding (a thick black border) to the android screen such that every app is displayed with the padding around it. I know how to do this for my app but how do I do this such that when my app is running in background the display is padded?
I don't believe this is possible unless you're willing to create and run a custom ROM.
Thankfully, this is not possible for the average non-ROM third party Android developer.
The screen on mobile devices is actually very limited, and when programming for the mobile environment, you have to learn to get away from the windows metaphor used by traditional desktop PCs.
On the other hand, may be your app could pretend it is running in the background, but still stay in the foreground with its transparency enabled. And perhaps if you can't do something, may be you can find a way to fake that something for your users.
Also, note that the default home launcher is capable of doing something similar to what you want, but only for widgets. And if being able to run widgets is sufficient for you, perhaps you could write your own launcher application that can embed widgets.
We’re porting to Android some interactive iOS apps used to teach young children with learning disabilities. We have hit a major usability issue, because we can't figure out how to disable physical or on-screen navigation buttons (Home and Recent Apps).
Before anyone says “you don’t want to do that”, we fully understand why you would always want these buttons enabled for an able-bodied adult, but these children pose a unique set of accessibility issues. Specifically:
Their fine motor control may be poor - they may inadvertently touch a different area of the screen to the area they intend, or accidentally use more than one finger at once.
They may have weak muscle tone and poor physical strength – so e.g. the bottom of the palm of their hand may drop and touch the screen while trying to just use a finger.
They struggle to achieve and easily become disheartened or disruptive if they fail.
For instance, a typical 5 year old child with Down syndrome will accidentally drop out of the app they are using as a result of inadvertently touching the Home button: when this happens repeatedly, and the adult teacher or parent has to go back into the app for them repeatedly, the child loses interest and focus. Another typical scenario is a young child with Autism, who may freak out completely and need physically restraining if this happens while using their favourite app. Also, many disabled children will try to poke any other button they can find, in search of a response. In any of these situations, a potentially valuable educational session may have to be completely abandoned.
We're aware of SYSTEM_UI_FLAG_HIDE_NAVIGATION and SYSTEM_UI_FLAG_LOW_PROFILE, but these only reduce the visibility of the on-screen buttons until the child touches some other part of the screen, and then they re-appear in a way that’s more distracting than if they were visible all the time.
On iOS there is the “Guided Access” feature that solves this problem trivially. Can we emulate anything similar on Android?
On iOS there is the “Guided Access” feature that solves this problem trivially.
Guided access appears to be a device setting, not something that developers enable unilaterally themselves, thank heavens.
Can we emulate anything similar on Android?
There is no similar device setting in stock Android.
You can download the Android source code, modify it as you see fit, build the results into a ROM mod, and install that ROM mod on devices as you see fit.
Or, you can perhaps work with a device manufacturer creating tablets aimed at children to see if either they have already added this capability to their devices, or would be willing to work with you to add such a capability in a future iteration of their devices.
Is there any way in Android to determine whether a device is running Sense UI? I'm working on an app that is working fine with vanilla Android, but Sense UI is messing with layouts and sizes. I'd like to be able to see whether the device is running Sense UI and so I can take appropriate action.
There is nothing built into Android that indicates what sorts of modifications like Sense are running on the device. You would either need to use PackageManager to look for HTC Sense components or use the Build class to determine what model device you are on. In either case, you would need to keep updating that "sniffing" logic as Sense is changed and is rolled out to new devices.
but Sense UI is messing with layouts
and sizes
If you have a reproducible test case with source code that demonstrates these problems, I would be interested in seeing it.
There are only two scenarios I can think of that would fit your description:
App widgets may display differently on the HTC Sense home screen, just as they may display differently on other home screens. Ideally, there would be no modification, but since you are running in another app's process, I can't rule it out.
If you rely on android.R resources, those might have been modified by HTC as part of creating Sense, though you can always grab the standard ones from your SDK and ship them with your app.
I have two buttons that both have onTouchListeners and perform an action when pressed down. Why do they not work if you try to click both at the same time? I'm building for Android 1.6. I don't have a real device to test on, and you can't test clicking two things at the same time in the emulator. Thanks for any help.
I'm no expert, but my guess would be the following,
All gui-interaction is done through the UI-thread. Unless you do some special treatment of the buttons, you'll end up processing "click 1" with the UI-thread, while the user does "click 2" (at a time when the UI-thread is busy somewhere else). That is, the UI will not be responsive during the second click.
Multitouch was only introduced in Android 2.x, so on 1.6 you're out of luck - not possible. Even with 2.x the default UI behavior is to be singletouch only for such events (ie button press).
I suppose it is possible to somehow extend the container view of those buttons to become multitouch friendly and actually pass the correct events to the buttons, but that would be quite hackish.
You can read more about multitouch here. And on page 3 you can see why the multitouch fails on the GUI: first touch event is ACTION_DOWN which is handled like it should be, and the second one is ACTION_POINTER_DOWN which the UI doesn't know how to handle.
As Roosma already mention, multitouch is available from 2.x version.
According downloading statistics from my app published at android market (already downloaded more then 16k persons) it looks like there are only a few dozens people that using Android 1.6 on their devices. So i think you should mouve to version 2.1 at least.
I hope it helps :)