Is there a way to hide these numbers? Im guessing there must be an attribute which once set to 'false' should to it.
Also, i've tried to use custom drawables for the the up/down arrow, but those seem to overlay on top of the numbers (ie,the numbers are still visible)
Note: I could make custom pickers where I use a textView in between two imageViews, but the default timePicker allows one to swipe up and scroll through numbers (so would prefer using the default)
Edit: Apparently the NumberPicker has different children in different versions of android(the emulator shows the up/bottom arrows, while on my Samsung Tab they return a nullpointerexception). Wow!
Instead of using a time picker you could try and use a number picker instead, this means that you can specifically set what you want to be in the picker.
Is there a way to hide these numbers?
No, sorry.
Im guessing there must be an attribute which once set to 'false' should to it.
Only if you fork TimePicker and add such an attribute yourself.
Related
I just want a simple non-editable text label but there doesn't seem to be a widget explicitly for it. The closest thing seems to be a android.widget.TextView. But the documentation says a "TextView is a complete text editor". That seems like overkill for a simple label. I don't want to bloat my application. Is there a more appropriate widget?
Or am I approaching this the wrong way? For example, let's say I'm building a settings screen, is there a layout I should choose which gives me labels for the properties so I don't have to specify widgets for the labels?
Is there a more appropriate widget?
No.
I don't want to bloat my application.
You won't, unless you put a ton of text in it. While TextView has a lot of code, your process will already have access to that code, whether you use TextView or not. The only "bloat" would come from the actual heap space used by the TextView object itself (and objects that it holds).
For example, let's say I'm building a settings screen, is there a layout I should choose which gives me labels for the properties so I don't have to specify widgets for the labels?
Typically, we would use a PreferenceFragment, backed by a preference XML resource, instead of having any layout or widgets.
But, if you wanted to roll your own for some reason, use TextView for the labels.
Is there a way to remove the NumberPicker UP/DOWN arrows?
I googled but I wasn't able to find any method.. I have 2 devices one with android 4.2.2 and one with 4.0.3, in the first one the NumberPicker is scrollable and has no arrows while in the second one the NumberPicker isn't scrollable and has the up/down arrows
Quoted from the android documentation class overview:
In your older device you get this one.
If the current theme is derived from Theme the widget presents the current value as an editable input field with an increment button above and a decrement button below. Long pressing the buttons allows for a quick change of the current value. Tapping on the input field allows to type in a desired value.
Whereas what you desire is this flavour of the widget:
If the current theme is derived from Theme_Holo or Theme_Holo_Light the widget presents the current value as an editable input field with a lesser value above and a greater value below. Tapping on the lesser or greater value selects it by animating the number axis up or down to make the chosen value current. Flinging up or down allows for multiple increments or decrements of the current value. Long pressing on the lesser and greater values also allows for a quick change of the current value. Tapping on the current value allows to type in a desired value.
This would seem to be from a compatibility issue due to android version. Check what minimum version of android your Holo derived themes use in your app. It may be that the theme your older 4.* device is not accessing the same theme, but one that shares many similarities.
I think you should create your own number picker and inflate it.
You can follow this tutorial on inflating elements .
I'm implementing an EditText that is used to obtain an rtsp URI from the user. Though it's not a huge issue functionally, I would like to disable the default behavior of the on screen keyboard where the state of the caps key is enabled for the first character of every sentence. From what I've gathered, this cannot be done in the XML via android:inputType flags. Any pointers as to how to do this programatically would be helpful.
I'd like to include the code, but the nature of the project prevents me from doing so. But I can say that nothing fancy is being done here. The EditText itself has no other input flags in use, and the only IME option in place is the flag to disable the Extract UI in landscape. The layout is implemented via XML, not programatically, so there are no custom classes or extensions in the mix either.
EDIT: The android:capitalize constant inherited from TextView isn't working. I'm specifically targetting 2.2 on a Galaxy Tab, so I don't know if this has something to do with Samsung's OS tweaks, or if it has something to do with the capitalize constant being deprecated.
EDIT 2: Swype is the culprit for not allowing the use of the capitalize constant. Does anyone know if there is a way to make Swype play nice without having to inform the end user to disable Swype?
You can use the inherited android:capitalize attribute from TextView. It accepts none (no caps, which is what you want), sentences (capitalizes the first word of each sentence), words (capitalizes the first letter of every word), and character (all caps).
Putting this in the XML for the EditText worked to stop Swype 2.17.59.15552.t100 from forcing capitals:
android:inputType="text|textEmailAddress"
Since EditText is subclass of TextView, you should be able to use the TextView:capitalize configuration to change the capitalization scheme of the view. It looks like you might only be able to set none in xml.
My application has a simple 'About' box.
It has a few clickable TextViews (email addresses, phone nos, addresses) all contained within a relative layout within a ScrollView (To accommodate low res screens).
The device I am testing with (Motorola Charm O.S ver 2.1 update 1) has a regular QWERTY keyboard. The problem I am facing is with the use of the arrow keys.
I want the cursor to move predictably from one clickable field to the next and this is where I need help. On the fields that don't need focus I have set the android:cursorVisible="false".I tried using the android:nextFocus* properties but still don't get the desired behavior.
The cursor gets stuck in the first field and overall the behavior is a bit unpredictable. Any ideas on how to get this done. Right now trapping the keys using code seems to be the only option.
TextView.setMovementMethod(LinkMovementMethod.getInstance())
The documentation is a little terse but it's basically what you are looking for.
What I'd like to do is change the state (really, the background) of an EditText to reflect validity of its contents. E.g. if the user enters 999 where 999 is contextually invalid, the EditText should have a red border in place of the default orange border, likewise once the text is valid it should have a green border.
Methods I've explored:
Changing the style of the EditText programmatically via something like editor.setStyle(R.styles.SomeID). Seems to be impossible within android.
Adding custom states (state_valid, state_invalid) in R.attr, associating them with red/ green 9-patches, then calling drawable.setState() with one of these states. This worked in the sense that the state could be read back via getState(), but the border did not change colour.
Setting the background resource directly upon detection of (in)validity. This works ok, causing the correct visual effect, but seems a little hokey, and allows only one state (e.g. I have to manually check for whether the EditText is pressed, enabled etc).
Given limited UI real-estate I am hesitant to introduce a separate UI element to visually feedback the text's validity to the user, hence my desire to display it in the EditText itself.
So.. is this something that's even feasible? It seems like a fairly common use case, so has anyone achieved what I'm trying to do in a straightforward and elegant manner?
I would recommend changing the text color to indicate validity, rather than changing the color of the focus ring by any of the techniques you describe (of which only #3 seems practical).
Another possibility is to try setCompoundDrawablesWithIntrinsicBounds() to modify an icon on the left or right side of the EditText contents to indicate validity. I remember discussing this technique with somebody a few months back and forget if they got it working or not.
And, of course, another option is to not allow invalid input, via a custom input filter or listener or something.
Well, I'd just extend the EditText class and build the desired functionality on top ( using the third approach you are suggesting, because it works :-) ). Doing this, you have to walk the way only once, and are open to change your implementation once you know the best way ( I would have personally solved it also using the third approach, seems fine to me ).
i think a call to invalidateDrawable(yourDrawable) would work with approach number 2.
i didn't try .. but it make sense