Espresso: How to test the style of a WebView element's contents - android

I am wondering if there is a way to assert on the style of a WebView element's contents in Espresso. I am aware of the ability to get the text of an element, however, I would like to do more testing. I haven't been able to find clear documentation on how to do things like getting the background-color or text-color of a button or the text-size using the onWebView.withElement logic. Is this even possible?
Consider this example:
Web.onWebView(withId(R.id.my_btn_id))
.withElement(findElement(Locator.ID,"_the_id_of_a_button"))
.check(webMatches({how to reference button text color}, "#0102333"));
Web.onWebView(withId(R.id.my_btn_id))
.withElement(findElement(Locator.ID,"_the_id_of_a_button"))
.check(webMatches({how to reference background color}, "#0302223"));
Web.onWebView(withId(R.id.my_btn_id))
.withElement(findElement(Locator.ID,"_the_id_of_a_button"))
.check(webMatches({how to reference text size}, "12px"));
Even getting the style value would help.
Note, I am aware of how to obtain these via evaluateJavascript. This is purely an Espresso question.

Related

Which Android widget should I use for a static text label?

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.

How to identify the text color and background in Calabash-Android

Is there any possible way to get the text color or background color of any particular text in Calabash-Android. I query in irb for same but doesn't get the required output. I think for IOS there is given methods to identify the color, but in Android it's limitation.
I have tried with text, id, index of particular text and apart form that I reached to github, forums pages but still scratching. does anybody got way in this scenario, if its kindly help.
Thanks in an advance
Vebhrocks
getTextColors is a method available for any textview. It should be useful when the entire textview has the same colour.
query("...", :getTextColors)
To get the background colour you could do something like query("...", :getBackground, :getColor)
If you need to do advanced computations, consider making a backdoor method.
I do, however, think this might be outside the scope of a UI test. Consider using a different approach of testing this instead of using a UI test framework. A simple unit test might suffice.

Set TextView style to strikethrough in XML only without using background

I'm trying to set a TextView's style to strikethrough for a smartwatch app. The ways to do this I've come across so far don't work:
1) Setting the background of the TextView to an image: This works, but only if the text is not wrapped, and I'm getting complaints from customers who have long items
2) Programatically setting the paint flag:
textview.setPaintFlags(textview.getPaintFlags() | Paint.STRIKE_THRU_TEXT_FLAG);
I can't do this, as I'm unable to get a reference to the TextView in code due to the way the smartwatch API works (you just send it the layout ID and then you have no control over it)
3) Using HTML tags in the string: Doesn't work, as I'm only allowed to send a string to the control, and it escapes the tags
4) Using a SpannableString: Doesn't work. If I send it using span.toString() then the tags are escaped, and if I use bundle.putCharSequence(span) instead then nothing is displayed.
It seems bizarre to me that you can set bold and italic in the XML, but nothing else. Can anyone suggest any other possible ideas?
When creating custom layouts with various effects we suggest to use showBitmap() instead showLayout(). You can inflate any layout and draw using Canvas into Bitmap. For more information, see the SampleControlExtension sample. Note, that the disadvantage of this approach will be, that you will need to use onTouch events instead onObjectClick events.

How do I fix Html.fromHtml link focus visibility problems (in ICS and Honeycomb)?

To get a TextView to display (and act friendly with) Html strings my code looks something like:
// itemHtml is a String of HTML defined above
TextView itemContent = (TextView) findViewById(R.id.itemContent);
itemContent.setText(Html.fromHtml(itemHtml));
itemContent.setMovementMethod(LinkMovementMethod.getInstance());
If the Html string has a link, TextView results in links that are clickable and focusable. When the user focuses on a specific link (e.g. by using the d-pad), the link text changes in some significant way to show that focus was obtained.
The problem is that when I test this same pattern using devices with a d-pad using Honeycomb (e.g. a Google TV) or Ice Cream Sandwich flavors of Android, the link in the text shows no noticeable indication that the link has focus.
I know it is getting focus, because when you then hit enter it does the specified action. You can even move around between various links in the text; you're just left guessing which link you're currently at, which results in a very bad user experience.
Is there something I'm doing wrong? Is there some way to fix this or work around this?
Edit: After going a bit nuts, I finally thought I found a solution. However, this solution only works for Honeycomb. ICS is still not solved!
As of API 11, Android has a new setting on TextViews for defining whether the text is selectable.
You can set it using setTextIsSelectable(true) on a TextView, or define it in the XML layout android:textIsSelectable="true"
It's probably best to define it in XML, so that keeping the app backwards-compatible is trivial. Just make sure you're targeting version >= 11, or you'll probably get an error.
The way HTML.fromHTML operates is by creating "spans" with varying effects throughout the various characters of the string. One workaround for this would be to use ClickableSpan coupled with another of the CharacterStyles to colorize the text as clickable. The previous span will allow you to register a callback, and this callback could be to broadcast an intent to view a url (which would open a browser).
The text colour state lists for Honeycomb+ might not set the focused state to a different colour, or you override the colour to be constant.
Check the colors + styles in your_android_sdk_directory/android-14/data/res/
Setting the text to android:autoLink="web" might also help?
The best way to do that is to add CSS styling to your html. I know Android supports :hover selector. So you might right something like this:
String myLink = "your link"
Html.fromHtml(myLink);
and find a way to include CSS data to it: (I'm not sure how but I think it's possible)
a :hover {
color: red;
}
UPDATE:
I think the answer of your question is there.

Android: view/ drawable custom styles possible?

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

Categories

Resources