Font height

For some devices (fr 245/ fr 735, marq series, fenix 6 series) the FONT_NUMBER_MEDIUM "background" is bigger than the font "foreground" (the background is about 28px bigger) why?

[ok for all fenix 5, f935, f945, f645, D2, descent]

So the dc.getFontHeight() return the background height and not the text heigth (the foreground).

Different behaviour prevent developer to do generic code and affect maintenance.

0 jim_m_58 over 5 years ago

For many devices there is the extra whitespace above/below for FONT_NUMBER fonts, going as far back as the fenix 3 and through the fenix 6/va4/venu. Things like this are defined by the platform groups and not CIQ so won't change, and the way to handle it is runtime "smarts" or jungles.

0 Juggus over 5 years ago in reply to jim_m_58

Ok thank you.

Jungles... yes.. in theory but not always possible in all cases.

Decouple UI and business classes is good but not always possible especially for embebbed system where memory is limited. My app is a big one (memory side) and all ko count. Creating classes costes memory, doing specific code for devices make the maintenance harder and test longer. I was happy to find a way to locate text according to screen size and text height but finally I have to do specific code again.... well.... its developer life.

0 jim_m_58 over 5 years ago in reply to Juggus

When I started with CIQ I had a vivoactive and all my apps were just for that. As I started supporting other devices, what I wound up was a bunch of spaghetti code. As I did other things, I found a few tricks to make life easier, such as doing all the device specific logic in onLayout vs onUpdate, so that onUpdate just used pre-calculated x's and y's. There are other things that can help too, such as making use of TEXT_VCENTER, as with that, you can minimize the impact of the white space above and below number fonts.

And sometimes, you just have to bite the bullet and rewrite things. That's the case with the original CIQ apps I did years ago. All are on at least their second generation re-writes. I had an app called "crumbs" back in mid 2015 (va only) that became "hike" as crumbs was very touch screen orientated, and to be honest, my CIQ coding got better. When CIQ 2 came out, I branched off "Hike2" for the newer devices with more memory (this was long before jungles or even build file excudes). After build excludes came out and I started adding devices to Hike2 I made use of those, but after a bit, that because a pain, so I did a new re-write that is now called Hike2+.

When the f6 devices and those with larger displays (the va4/venu), porting hike2+ to them was a 1 character change. Not a line of code - just changing an indent offset and it worked on all supported devices. So what I'm saying is sometimes it's easier to re-write at least some code than to make existing code work with new devices and kind of "future proof" things, but that can take experience that you can only gain over time...

0 Juggus over 5 years ago in reply to jim_m_58

Yes with experiences we learn some tips. Jungle is a good feature for sure. Some things are now automatic for me since my screen layout is calulate from screen size percentage. To save memory I have renounced to language translation, for 3 reasons 1) Whatever the country, english words are used for crossfit 2) using Ui.resourceAsString in the code uses more memory than a simple string declared like "hello" 3) the more the string.xml has entry, the more it needs memory. I have earned 3 or 4 ko.

My app has 59 classes when it runs the memory peak is 118ko/124ko saving memory becomes touchy and need many times.