Default text color changed from black to grey in the Android Companion and Android compiled (but not in the iOS Companion)

Questions about Thunkable
1

Hey all

I have built an app which uses tons of labels which I created without changing their default black color. Since a few days, the same labels default text color now appears grey when viewing the app in the Android Companion without me changing anything; the font’s text color is still undefined as it always was. Interestingly enough, the same app in the iOS companion looks as before with the labels text color being correct (black).

Is anyone else experiencing the same? Needless to say, there is no way I am going to select every single label in my app and set its color to black to “fix” this issue.

Thanks
K

2

Hi,

Do I understand that the color difference is barely visible? I opened my project and see that the text in one Label looks darker than in others.

Yes, the default color is gray and this is clearly visible if the color of the other Label is set to black.

Interestingly, the default color for Text Input differs from the default color for Label

3

Not barely but signifiant. The grey color has an RGB value of 117,117,117 while the black is 0,0,0. If you don’t think this is much of an issue check this for comparison:

ColorBug

I am sure about the colors as I snapped screenshots and used the color picker tool to get the exact RGB values. In any case, the facts that on iOS it appears as expected and that even on Android the text input color is still black and that the issue appears in labels point to the fact that this is a bug.

I guess it is time for me to open a bug report.

K

4

You may think of this as a bug, but this is a moot point, because in programming it is customary to initialize everything. If the programmer decided to leave a default value, it can be considered a programmer’s error.

You can ask me, does it mean that all property values need to be initialized yourself? Yes, if the reliability of the application is in the first place. Or are you ready to rely on the developers to initialize everything correctly for you? Unfortunately, this approach in early versions of Thunkable X caused the app to crash.

5

Here is a list of 64 uninitialized parameters (bottom of this message) just for the “Label” element. So according to your logic:

a. we have to initialize 64 parameters when we create a label in order to avoid “moot points” and god knows how many dozens of parameters for each other elements
b. the text color could have become pink, red or yellow following the same “moot point” logic
c. it is perfectly fine to have a different experience on iOS and on Android when developing using a cross-platform tool (Thunkable)
d. having the same experience one day and all of a sudden a different experience between iOS and Android makes sense but the other way around is nonsense

Am I getting this right? So even if we set those 64 parameters once per element in a project and then clone that element to avoid this travesty, this makes more sense to you than:

a. avoiding to mess up with the user space
b. using change management to inform users about upcoming changes which might impact their projects
c. setting the previously undefined value programatically to match the same value when defined for all projects in the back end to minimize the end user impact

So according to your logic, “moot points” make more sense than a, b and c, am I getting this right? Moot points? I am not looking for an answer, I am just thinking out loud here… all those questions are rhetorical…

K

List of uninitialized parameters for the label element:

  • Number Of Lines
  • Color
  • BackgroundColor
  • Font Style
  • Font Weight
  • Text Align
  • Border width
  • Border radius
  • Border color
  • Border style
  • Font family
  • Text Shadow Offset Width
  • Text Shadow Offset Height
  • Text Shadow Radius
  • Text Offset Color
  • Letter Spacing
  • Line Heigt
  • Text Align Vertical
  • Text Decoration Line
  • Text Decoration Style
  • Text Decoration Color
  • Writing Direction
  • Width
  • Min width
  • Max width
  • Height
  • Min height
  • Max height
  • Aspect Ratio
  • Positioning
  • Overflow
  • flexGrow
  • flexShrink
  • flexBasis
  • flexDirection
  • justifyContent
  • alignitems
  • alignself
  • aligncontent
  • ZIndex
  • Edge offset top
  • Edge offset bottom
  • Edge offset left
  • Edge offset right
  • Direction
  • BorderColors Top
  • BorderColors Bottom
  • BorderColors Left
  • BorderColors Right
  • Border Radii Top Left
  • Border Radii Top Right
  • Border Radii Bottom Left
  • Border Radii Bottom Right
  • ShadowColor
  • showOpacity
  • shadowRadius
  • shadowOffset Width
  • shadowOffset Height
  • Elevation
  • Opacity
  • Perspective
  • Backfacevisibility
6

Bug issue opened:

7

I am updating the description of this issue as it occurs in compiled apps as well, not just in the companion.

8

Here is a list of 64 uninitialized parameters (bottom of this message) just for the “Label” element. So according to your logic:

Let’s speak correctly. If these parameters were uninitialized, then the applications would not work at all. It is correct to say that these parameters are initialized with default values (I have not checked each value, but we will assume that they are all initialized).

Who determines what the default values should be? Software developers (in our case, developers of Android, Thunkable X, and all the technologies that are used to run the platform). This leads to a simple conclusion: if you have not changed the default value of the parameter, then you agree that the values set by the software developers will be used. Simply put, is there some part of your app that you don’t control and you think that Android software developers and everyone else should provide the parameter values that you need? Don’t you think that some developer might change something in the default values?

a. we have to initialize 64 parameters when we create a label in order to avoid “moot points” and god knows how many dozens of parameters for each other elements

You decide for yourself. If you trust the software developers, then you use it. If you have any doubts, choose another software.

b. the text color could have become pink, red or yellow following the same “moot point” logic

One day, a web designer I know asked me to look at his website. I opened it on my own monitor and this web developer almost fainted, because he saw a gray background of the page, instead of the white one for which the entire site design was created. This site has been in the public domain for several years and its development cost several tens of thousands of dollars. What was the problem? In that this web designer left the default page background value, assuming. that all users work with the system white color. For convenience, I changed the color to gray in the system and this single parameter broke all the work for it.

c. it is perfectly fine to have a different experience on iOS and on Android when developing using a cross-platform tool (Thunkable)

Some may agree with this, and some may disagree. Personally, I prefer the approach used in Framevork 7, when mobile apps look as similar as possible on different platforms.

d. having the same experience one day and all of a sudden a different experience between iOS and Android makes sense but the other way around is nonsense

This is the app developer’s choice. Some people prefer hard-core development, while others prefer cross-platform development.

What about the user? In most cases, users use what they are given without individual settings. If the user decides that the new version is too inconvenient, they will simply choose a different app.

So according to your logic, “moot points” make more sense than a, b and c, am I getting this right? Moot points? I am not looking for an answer, I am just thinking out loud here… all those questions are rhetorical…

My logic is based on what is important to you specifically. You need simplicity and the ability to easily develop for iOS and Android. That’s why you chose Thunkable X. But for a person who is responsible for developing a program for managing the international space station complex, there is no question of entering initial values for 64 parameters, because to get the most reliable program, he must make sure that all tens of thousands of parameters are set as they should be, and not as someone or somewhere initialized it earlier. I think you understand that in many areas, trying to use default values can lead to big problems. This applies to the field of military equipment, medicine, the financial system, etc.

Yes, it is inconvenient and difficult to perform group operations on objects and properties in Thunkable X. And no one will manually override the default parameter values. You have been using Thunkable X for a long time, and I think that by this time you should understand its advantages, not its limitations, the scope of use, and what can happen after the next update.