Bug 7345 - textAppearance not working correctly with style resource
Summary: textAppearance not working correctly with style resource
Status: RESOLVED FEATURE
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 4.2.x
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-09-20 11:56 UTC by Goncalo Oliveira
Modified: 2012-10-02 11:32 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FEATURE

Description Goncalo Oliveira 2012-09-20 11:56:45 UTC
Considering the following style

  <style name="myTextAppearance" parent="@android:style/TextAppearance">
    <item name="android:textSize">18sp</item>
    <item name="android:textColor">#b8b8b8</item>
  </style>

which is spawned for different screen sizes (normal, large and extra large) - with different text sizes.

I set in the axml the textAppearance as @style/myTextAppearance so that the correct style is used based on the screen size.

It works well in general for activities. I say in general because I have one situation where it's not true for all elements, but I still don't know the reason.
Though, when using Fragments or when using inflated views with adapters (derived from BaseAdapter) this is not working at all, the style is not applied.

As a workaround I'm setting the style by hand in code. There used to be a bug with this where setting style in axml and in code had a different outcome, though, that was fixed in 4.2.4.
Comment 1 Goncalo Oliveira 2012-09-21 11:59:29 UTC
After some digging I finally found what's meddling with this.
I was trying to create a side app to replicate this, but wasn't getting any success, until now.

It has to do with themes, as Bryan Moulton was suggesting.
The facts are

[Activity( Label = "Second Activity", Theme = "@style/Theme.Frotcom" )]
public class SecondActivity : FragmentActivity

Then one of the fragments (frag 3) has the following properties
textAppearance = @style/textWeirdo
textColor = @color/theme_red

The result is that the fragment does not set the textAppearance. textColor is set correctly.

If I remove the Theme value from the activity attribute everything works correctly.
Comment 3 Goncalo Oliveira 2012-09-26 10:53:19 UTC
Just an additional comment. It does not work well in general for activities.

I didn't notice this because I already had a code workaround in most places. Though, does not seem to be working in any case. This might be relevant because there was a bug earlier (can't find it though) with this problem and it was fixed for 4.2.4 - meaning, 4.2.5/6 went back.
Comment 4 Atsushi Eno 2012-10-01 06:33:48 UTC
Since RestSharp dll isn't included I built it from their github master (https://github.com/restsharp/RestSharp r054adce) and it resulted in build errors. Could you please attach valid dll or update your code?

	Fragments/Fragment1.cs(62,13): error CS0103: The name `RestClientHelper' does not exist in the current context
	Fragments/Fragment1.cs(63,13): error CS0103: The name `RestClientHelper' does not exist in the current context
	Fragments/Fragment1.cs(64,13): error CS0103: The name `RestClientHelper' does not exist in the current context
	Fragments/Fragment1.cs(94,13): error CS0103: The name `RestClientHelper' does not exist in the current context
Comment 5 Goncalo Oliveira 2012-10-01 12:53:06 UTC
Sorry, that code isn't really relevant. I'll re-upload the project with that reference removed.
Comment 7 Atsushi Eno 2012-10-02 04:32:45 UTC
I don't think your code will result in whatever you want. It looks to me the expected result.
When it specifies Theme.Frotcom, the text in the third Fragment is drawn as textSize = 14sp as Theme.Frotcom specifies and textColor = red as Fragment3.axml indicates. textAppearance is considered only when there is no style specified.

This is TextView source:
https://github.com/OESF/OHA-Android-4.0.4_r1.0/blob/master/frameworks/base/core/java/android/widget/TextView.java

Here is how TextView retrieves textAppearance. It is from style:
https://github.com/OESF/OHA-Android-4.0.4_r1.0/blob/master/frameworks/base/core/java/android/widget/TextView.java#L486

If there is textSize in textAppearance, then it retrieves textSize from it:
https://github.com/OESF/OHA-Android-4.0.4_r1.0/blob/master/frameworks/base/core/java/android/widget/TextView.java#L518

and that textSize is set to its private mTextPaint.
https://github.com/OESF/OHA-Android-4.0.4_r1.0/blob/master/frameworks/base/core/java/android/widget/TextView.java#L1064

which is used by TextView's getTextSize():
https://github.com/OESF/OHA-Android-4.0.4_r1.0/blob/master/frameworks/base/core/java/android/widget/TextView.java#L2154

Some attributes e.g. android:textColor still seem to reference textAppearance at run time:
https://github.com/OESF/OHA-Android-4.0.4_r1.0/blob/master/frameworks/base/core/java/android/widget/TextView.java#L8706

but this is not true to textSize.

----

On MfA side, the AndroidManifest.xml we generate contains:

    <activity android:label="Second Activity" android:theme="@style/Theme.Frotcom" android:name="fmobile.crashtestdummy.SecondActivity" />

(You can check this by seeing obj/Debug/android/AndroidManifest.xml)

If the relevant style is missing then aapt results in an error like this:
Error: No resource found that matches the given name (at 'textAppearance' with value '@style/textWeirdo__').

and if the resource is missing in the final apk it should just crash due to ID mismatch.

----

Hence I believe the result is whatever expected.

I'm not very familiar with the styling, so I might be overlooking things. You likely know better, so if you have convincing explanation on the expected behavior, please reopen and share it :)
Comment 8 Goncalo Oliveira 2012-10-02 05:36:35 UTC
I still don't agree with the behavior. If I don't have a theme, text size and color is set using the style, if I do have a theme it's ignored.
If I have the need to use different text sizes in the same activity, I can't use styles for that, I just have to set sizes directly. This forces me to have at least one layout for each screen size. And if at some point I need to reevaluate the sizes, I need to change it in every layout and not in a single style. That or by coding. Does not seem like a fair design-code separation.

Setting a style in textAppearance should override the theme.
Comment 9 Goncalo Oliveira 2012-10-02 05:52:59 UTC
Also,

If I'm not reading this wrong (I might), text size is retrieved from attributes after the theme is read, so it should overwrite.

https://github.com/OESF/OHA-Android-4.0.4_r1.0/blob/master/frameworks/base/core/java/android/widget/TextView.java#L785

later

https://github.com/OESF/OHA-Android-4.0.4_r1.0/blob/master/frameworks/base/core/java/android/widget/TextView.java#L1064
Comment 10 Atsushi Eno 2012-10-02 06:35:07 UTC
Hello Goncalo,

Note that regardless of whether you agree or disagree with the *Android's* behavior of the styling, Mono for Android is all about invoking Android's feature that cannot change its behavior. You might want to file a bug to Android instead:
http://code.google.com/p/android/issues/list

As for L785, note that it retrieves the attribute from TextView, not from textAppearance. Hence I believe this is not what you actually coded.
Comment 11 Goncalo Oliveira 2012-10-02 10:41:55 UTC
To clear this up, I installed Eclipsed and ADT plugin. I created a new project from scratch with an activity. I added a theme to styles to remove the window title and added a style to change the size and color.

  <style name="AppTheme" parent="android:Theme">
    <item name="android:windowNoTitle">true</item>
  </style>

  <style name="textWeirdo" parent="@android:style/TextAppearance">
    <item name="android:textSize">34sp</item>
    <item name="android:textColor">#CFCA42</item>
  </style>

The activity layout only has a TextView where textAppearance = textWeirdo. I also set the activity theme to AppTheme.

Build, run, works.

I had just updated to the most recent version (4.2.7 beta), so I created a new app from scratch to clear up the issues.

The same thing, xml style file, activity with same layout.

Works.

So, the textAppearance style does override the theme, as it was supposed to. 
I added a FragmentActivity with a fragment in to see if it worked also. It did.


Confused, I went back to the previous app and I noticed that I had a textSize in the theme and in the current I only have the windowNoTitle. So I added the textSize to the styles file in Eclipse and ran the app again - Didn't work. So it is confirmed that this is an Android issue, or simply just as it is. If I change the theme to include a textSize, it overlaps any textAppearance style. Though, if I change the textColor, everything still works.

I'll be posting an issue on Google as suggested, as I still don't agree that this should be the solution. Theme is set on a higher level of the visual tree, so it should be overriden.

Thanks for the help.
Comment 12 Atsushi Eno 2012-10-02 11:32:12 UTC
Oh wow, that's indeed a mess. Thanks for sharing your exploring. I am still afraid that it's kind of difficult to get fixed as to change the _existing_ behavior (unless they ignore compatibility).
As for textColor, I think it still retrieves the values from textAppearance (I mentioned that in my comment #7) so it would still work as you expect.