Now I understand. That makes sense.
Hmm. This sounds like a missing property upgrader in YoungAndroidFormUpgrader.
2 Likes
Can this set the ElementColor property to the same color as BackgrounColor? And will it only do this the first time the project is loaded into a new version of AppInventor?
I found an entry for ListView but only updating the version number.
if (srcCompVersion < 8) {
// Added HintText property, performance optimization
srcCompVersion = 8;
}
I have a preliminary correction:
if (srcCompVersion < 8) {
// Added HintText property, performance optimization
if (componentProperties.containsKey("BackgroundColor")) {
String color = ((ClientJsonString)componentProperties.get("BackgroundColor")).getString();
componentProperties.put("ElementColor", new ClientJsonString(color));
}
srcCompVersion = 8;
}
I'll compile the sources and check if it works.
Sigh. I'm sure that's exactly what it is. I definitely missed this difference.
Designer property statements are only emitted when the value is set to something other than the default. The problem here is that if we set a new property (ElementColor) to a non-default value, everyone has to upgrade their companion to a version that has that property available. Without a new iOS version yet that is a no-go since it would break everyone on iOS even if they don't intend to use that feature (as well as everyone using 2.72u or earlier on Android).
So we can't use the code he showed? So what's the solution? Because in order to keep the background color in old projects either ElementColor has to have a background color or be transparent.
This code works, I tested it. But from what I understand it may cause an error in companion for ios, because the ios version does not support this property? This will also cause an error if someone uses an older version of companion for android. But if we have an app inventor update, we should also use the new version of companion. Usually, the information that we are using the wrong version of companion was displayed, but recently there were reports that this did not happen.
If we can't use this, then I guess the only solution is to change the default color in ElementColor to transparent?
We could have gone a different way from the beginning and not created a new property. The BackgroundColor property could have been the color for the element, and the actual background could have been left transparent. Then the Listview would have taken the color of something that was under the ListView and there you could set the background color under the elements.
Does the ElementColor property do anything different from the BackgroundColor property in the ListView?
This is basically impossible to solve cleanly. Our general rule of thumb is that we should be able to support at least 2 back for any companion since not everyone can upgrade lockstep with the latest features of AI2. I think the minimal pathway for pain is the following:
- Adjust the ElementColor property default to be transparent and update the default setting in the constructor of ListView accordingly.
- Write an upgrader that if the ElementColor property is present and it is None (transparent), remove the setting.
We will then need to do an emergency release of the companion to the play store with the updated code.
Why is this the best solution?
- It prevents the ElementColor property from being emitted unless the user has changed it to something other than transparent, or hasn't yet touched it. This allows older Android companions and the iOS companion, which don't have ElementColor, to still work.
- Only users who have touched ElementColor and set it to something other than Black (current default) or None (future default) will be affected. If they have the 2.73+ companion on Android they will be unaffected. They can switch back to Transparent if they want the old behavior.
The proposed solution creates a designer entry for the ElementColor property for any project where BackgroundColor is not the default. This will immediately make the project fail to load on any companion other than 2.73 (both Android and iOS) whereas they'd otherwise work without the proposed change.
ElemenColor sets the color of the elements, i.e. the CardView. BackgroundColor sets the color for the RecyclerView, i.e. what is under the CardView.
Ok, I will prepare 3 fixes during the weekend:
- ElementColor,
- fix the way of setting the background color for CardView because now it is not possible to set a transparent color, because it is not possible to turn off the shadow for CardView,
- add new properties to Mock for ListView so that they are visible to the designer
I have taken care of the ElementColor issue and changing the card elevation to address the shadow for the time being.
1 Like
Very quick fix.
Thanks all.
I think I’ll stick to trying to understand ‘blocks’.
Btw - the impact of the blacking of listview elements created a startling 2001:A Space Odyssey effect within my listing of some 80 items.
Place your project here, or screenshots showing what you mean. We are not spacemen.
Why if the default color is transparent the designer is set to None, and if the default color is another color the designer shows Default? At first I thought something was not working properly.
Patryk
Here are some images - hope it works.
In Space Odyssey a perfect mysterious monolith appeared, in my app when doing a listing of players a perfect monolith appeared.
That’s all I meant, twas a joke.
2 Likes
Earlier you wrote about some problems, I thought you meant them. Did you fix everything that was needed and now it's ok?
1 Like
I’ve made adjustments and the width now ok. I don’t know what caused those issues - I tend to blame myself.
The apps are working now as intended after making the colour and width adjs.
If only I knew how to stop fiddling & adjusting……..
Anyway, solving challenges is very enjoyable
Thanks