3 ms·

Lmao, tbh all this is coming across as "Jr Engineer knows everything" syndrome. The fact your [1] link is a class that's not even used in the TextView class is

by flutas 2y ago

Lmao, tbh all this is coming across as "Jr Engineer knows everything" syndrome. The fact your [1] link is a class that's not even used in the TextView class isn't lost on me to start. They share an interface though, scary!1!! The fact your [0] link is to a copy of the TextView from 2017 is even funnier. > Just look at the sourcecode for TextView[0] if you want to see for yourself. 8,700 lines of code to show text on the screen? Well actually, TextView is actually a full blown text editor with the editing functionality turned off as a flag. Hmm yes, 8,700 lines to "just show text". No hyperbole detected there. Who cares about fonts, shadows, or any other visuals on or around the text, all we're showing is "just text". > Well actually, TextView is actually a full blown text editor with the editing functionality turned off as a flag. And? It's called code de-duplication. While realistically I think the better approach would have been to have TextEdit be the barebones display only and Editor add the editing functionality, sometimes code is so tightly coupled for reasons that you can't do that easily. This approach is much better than hitting cmd+c/cmd+v and copying the code into a new class. The funniest part to me is that your rant is about TextViews though. When that's been soft deprecated for 5 years already (replaced by Compose Text element).

fngjdflmdflg 2y ago
>The fact your [1] link is a class that's not even used in the TextView class The [1] link is only used by TextView. It is completely reliant on TextView and can't be used by other components. And yes, it is used, right here: https://android.googlesource.com/platform/frameworks/base/+/jb-mr0-release/core/java/android/widget/TextView.java#8333 https://android.googlesource.com/platform/frameworks/base/+/... mEditor is used over 400 times in TextView.java. Did you even read it before commenting? >The fact your [0] link is to a copy of the TextView from 2017 is even funnier. Why is that funny? Most of it has not changed. I linked to the up to date one in the second link. I searched "TextView source code" on Google to get the first one. It gets the point across and doesn't matter how old it is. >Hmm yes, 8,700 lines to "just show text". No hyperbole detected there. Who cares about fonts, shadows, or any other visuals on or around the text, all we're showing is "just text". I'm pretty sure a lot of that is handled by DynamicLayout, not TextView, although correct me if I'm wrong here. If if it isn't, it should be, and is indicative of poor software design. Shadows certainly should not be handled by TextView, I have no idea why anyone would think that. Take a look at Flutter's implementation. Text is just 1,400 lines, a large portion of which is documentation (another thing the Adnroid SDK sorely lacks,) and it just shows text to the user.[0] Somehow all the "tight coupling" issues have gone away here, and there is no need to throw a text editor into the code. How does Flutter edit text? It has a base EditableText class[1] that is then exposed by simpler widgets like TextField[2]. Now if I want to make my own custom editable text I can without having to recreate the whole thing. >And? It's called code de-duplication No. You don't get rid of separation of concerns to save a few bytes. If TextView cannot be made into a separate component that EditText uses then it should implement the functionality of TextView on its own. This is called the single-responsibility principle. A TextView should not be a texteditor. It can't get any simpler than that. Either refactor the text viewing components into something that can be shared by TextView and EditText, or separate them completely. >The funniest part to me is that your rant is about TextViews though. When that's been soft deprecated for 5 years already (replaced by Compose Text element). I wonder why this great piece of code was deprecated if it's so great? And yes, that's another great thing about the Andorid SDK. Everything is deprecated while its replacements are only supported on new devices. Then you end up having to do: if(onReallyOldDevice){ useDeprecatedMethod1() }else if (onOldDevice){ useDeprecatedMethod2() }else{ useSoonToBeDeprecatedMethod() } See eg. accessing file systems. [0] https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/widgets/text.dart https://github.com/flutter/flutter/blob/master/packages/flut... [1] https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/widgets/editable_text.dart https://github.com/flutter/flutter/blob/master/packages/flut... [2] https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/text_field.dart https://github.com/flutter/flutter/blob/master/packages/flut...
- flutas 2y ago
  > I wonder why this great piece of code was deprecated if it's so great? And yes, that's another great thing about the Andorid SDK. Everything is deprecated while its replacements are only supported on new devices. Again, same vibes. The reason you are seeing anything like this, is because you are looking at foundation code and expecting app code. This code is going to be used by apps to run on ALL devices. Best way I can try to describe it is just library code sits between the kernel and software, it has to support everything. Company X's latest XR/AI app doesn't. Software is constantly evolving for whatever the latest trend is be it VR, AI, or whatever, and eventually you move on from devices that don't get updated. But, so do users. Users by and far want the latest and greatest, shiniest thing. That means every company wants to support `thing`, even if it means dropping `oldThing`. Funnily enough I had to have a discussion at my job today about dropping support for FireOS 6 devices because of OS specific bugs that happen with Compose that cause a buggy UI. We can't make it work exactly as we want while providing a good experience, so we won't be providing an experience at all. The reason that's okay? Those devices have usage percentage that's practically nil, as they are older devices and not the "latest and greatest".
  - fngjdflmdflg 2y ago
    >Again, same vibes. Are you serious? The Android devs have been working to fix the deprecation and update issue for the last decade and a half. I think you are actually the junior dev here if you are defending it. They have been slowly moving from their custom fork of Linux back to mainline, separating device-level components (eg. Bluetooth) as separate modules, trying to force device vendors to support a baseline of features via GKI, trying to separate kernel updates from higher level system updates, and trying to increase SoC support duration from vendors like Qualcomm. The minuscule device support length on Android is a real issue that Google has spent tens of millions of dollars trying to fix (and only now are they even close to being able to start fixing it). A lot of it is due to political decisions that began at the beginning of Android's lifetime, when device vendors had much more control over the operating system. The fact that pointing that out as a flaw gives you "junior programmer vibes" is seriously concerning. Also, you failed to address even a single point I made in my post about TextView.
on_and_off 2y ago
"to just show text" is such a tell that you know nothing about UI. Displaying text is extremely complex. This is only 8000 lines because skiaa does the brunt of the job. Also, who gives a shit about TextView? Just use BasicText, we aren't in 2017 anymore.
- fngjdflmdflg 2y ago
  The actual layout algorithm is handled by DynamicLayout, not the textView. It really is just supposed to show some text. You can see it here.[0] Almost all the difficult aspects of showing the text, such as alignment, text direction, line spacing, line breaking, ect. as well as the actual rendering of the text are handled by StaticLayout/DynamicLayout. All TextView should be doing is basically just allowing you to add text programmatically and handling the selection handles. That should not entail having a text editor. >"to just show text" is such a tell that you know nothing about UI I have actually made my own TextView using just layout so I don't think this comment is warranted. [0] https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/widget/TextView.java;drc=6e44f0cd4f0b4de5118d605eac7c3f90003128d2;l=10947 https://cs.android.com/android/platform/superproject/main/+/...
  - flutas 2y ago
    > I have actually made my own TextView using just layout so I don't think this comment is warranted. Make sure you handle the following attributes and how they affect each other! > text, bufferType, hint, textColor, textColorHighlight, textColorHint, textAppearance, textColorLink, textFontWeight, textSize, textScaleX, fontFamily, typeface, textStyle, cursorVisible, maxLines, maxHeight, lines, height, minLines, minHeight, maxEms, maxWidth, ems, width, minEms, minWidth, gravity, scrollHorizontally, password, singleLine, selectAllOnFocus, includeFontPadding, maxLength, shadowColor, shadowDx, shadowDy, shadowRadius, autoLink, linksClickable, numeric, digits, phoneNumber, inputMethod, capitalize, autoText, editable, freezesText, ellipsize, drawableTop, drawableBottom, drawableRight, drawableLeft, drawableStart, drawableEnd, drawablePadding, drawableTint, drawableTintMode, lineSpacingExtra, lineSpacingMultiplier, justificationMode, marqueeRepeatLimit, inputType, imeOptions, privateImeOptions, imeActionLabel, imeActionId, editorExtras, elegantTextHeight, fallbackLineSpacing, letterSpacing, fontFeatureSettings, fontVariationSettings, breakStrategy, hyphenationFrequency, lineBreakStyle, lineBreakWordStyle, autoSizeTextType, autoSizeMinTextSize, autoSizeMaxTextSize, autoSizeStepGranularity, autoSizePresetSizes, textCursorDrawable, textSelectHandle, textSelectHandleLeft, textSelectHandleRight, allowUndo, enabled

by flutas 2y ago

fngjdflmdflg 2y ago

>The fact your [1] link is a class that's not even used in the TextView class The [1] link is only used by TextView. It is completely reliant on TextView and can't be used by other components. And yes, it is used, right here: https://android.googlesource.com/platform/frameworks/base/+/jb-mr0-release/core/java/android/widget/TextView.java#8333 https://android.googlesource.com/platform/frameworks/base/+/... mEditor is used over 400 times in TextView.java. Did you even read it before commenting? >The fact your [0] link is to a copy of the TextView from 2017 is even funnier. Why is that funny? Most of it has not changed. I linked to the up to date one in the second link. I searched "TextView source code" on Google to get the first one. It gets the point across and doesn't matter how old it is. >Hmm yes, 8,700 lines to "just show text". No hyperbole detected there. Who cares about fonts, shadows, or any other visuals on or around the text, all we're showing is "just text". I'm pretty sure a lot of that is handled by DynamicLayout, not TextView, although correct me if I'm wrong here. If if it isn't, it should be, and is indicative of poor software design. Shadows certainly should not be handled by TextView, I have no idea why anyone would think that. Take a look at Flutter's implementation. Text is just 1,400 lines, a large portion of which is documentation (another thing the Adnroid SDK sorely lacks,) and it just shows text to the user.[0] Somehow all the "tight coupling" issues have gone away here, and there is no need to throw a text editor into the code. How does Flutter edit text? It has a base EditableText class[1] that is then exposed by simpler widgets like TextField[2]. Now if I want to make my own custom editable text I can without having to recreate the whole thing. >And? It's called code de-duplication No. You don't get rid of separation of concerns to save a few bytes. If TextView cannot be made into a separate component that EditText uses then it should implement the functionality of TextView on its own. This is called the single-responsibility principle. A TextView should not be a texteditor. It can't get any simpler than that. Either refactor the text viewing components into something that can be shared by TextView and EditText, or separate them completely. >The funniest part to me is that your rant is about TextViews though. When that's been soft deprecated for 5 years already (replaced by Compose Text element). I wonder why this great piece of code was deprecated if it's so great? And yes, that's another great thing about the Andorid SDK. Everything is deprecated while its replacements are only supported on new devices. Then you end up having to do: if(onReallyOldDevice){ useDeprecatedMethod1() }else if (onOldDevice){ useDeprecatedMethod2() }else{ useSoonToBeDeprecatedMethod() } See eg. accessing file systems. [0] https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/widgets/text.dart https://github.com/flutter/flutter/blob/master/packages/flut... [1] https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/widgets/editable_text.dart https://github.com/flutter/flutter/blob/master/packages/flut... [2] https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/text_field.dart https://github.com/flutter/flutter/blob/master/packages/flut...

flutas 2y ago
> I wonder why this great piece of code was deprecated if it's so great? And yes, that's another great thing about the Andorid SDK. Everything is deprecated while its replacements are only supported on new devices. Again, same vibes. The reason you are seeing anything like this, is because you are looking at foundation code and expecting app code. This code is going to be used by apps to run on ALL devices. Best way I can try to describe it is just library code sits between the kernel and software, it has to support everything. Company X's latest XR/AI app doesn't. Software is constantly evolving for whatever the latest trend is be it VR, AI, or whatever, and eventually you move on from devices that don't get updated. But, so do users. Users by and far want the latest and greatest, shiniest thing. That means every company wants to support `thing`, even if it means dropping `oldThing`. Funnily enough I had to have a discussion at my job today about dropping support for FireOS 6 devices because of OS specific bugs that happen with Compose that cause a buggy UI. We can't make it work exactly as we want while providing a good experience, so we won't be providing an experience at all. The reason that's okay? Those devices have usage percentage that's practically nil, as they are older devices and not the "latest and greatest".
- fngjdflmdflg 2y ago
  >Again, same vibes. Are you serious? The Android devs have been working to fix the deprecation and update issue for the last decade and a half. I think you are actually the junior dev here if you are defending it. They have been slowly moving from their custom fork of Linux back to mainline, separating device-level components (eg. Bluetooth) as separate modules, trying to force device vendors to support a baseline of features via GKI, trying to separate kernel updates from higher level system updates, and trying to increase SoC support duration from vendors like Qualcomm. The minuscule device support length on Android is a real issue that Google has spent tens of millions of dollars trying to fix (and only now are they even close to being able to start fixing it). A lot of it is due to political decisions that began at the beginning of Android's lifetime, when device vendors had much more control over the operating system. The fact that pointing that out as a flaw gives you "junior programmer vibes" is seriously concerning. Also, you failed to address even a single point I made in my post about TextView.

on_and_off 2y ago

"to just show text" is such a tell that you know nothing about UI. Displaying text is extremely complex. This is only 8000 lines because skiaa does the brunt of the job. Also, who gives a shit about TextView? Just use BasicText, we aren't in 2017 anymore.

fngjdflmdflg 2y ago
The actual layout algorithm is handled by DynamicLayout, not the textView. It really is just supposed to show some text. You can see it here.[0] Almost all the difficult aspects of showing the text, such as alignment, text direction, line spacing, line breaking, ect. as well as the actual rendering of the text are handled by StaticLayout/DynamicLayout. All TextView should be doing is basically just allowing you to add text programmatically and handling the selection handles. That should not entail having a text editor. >"to just show text" is such a tell that you know nothing about UI I have actually made my own TextView using just layout so I don't think this comment is warranted. [0] https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/widget/TextView.java;drc=6e44f0cd4f0b4de5118d605eac7c3f90003128d2;l=10947 https://cs.android.com/android/platform/superproject/main/+/...
- flutas 2y ago
  > I have actually made my own TextView using just layout so I don't think this comment is warranted. Make sure you handle the following attributes and how they affect each other! > text, bufferType, hint, textColor, textColorHighlight, textColorHint, textAppearance, textColorLink, textFontWeight, textSize, textScaleX, fontFamily, typeface, textStyle, cursorVisible, maxLines, maxHeight, lines, height, minLines, minHeight, maxEms, maxWidth, ems, width, minEms, minWidth, gravity, scrollHorizontally, password, singleLine, selectAllOnFocus, includeFontPadding, maxLength, shadowColor, shadowDx, shadowDy, shadowRadius, autoLink, linksClickable, numeric, digits, phoneNumber, inputMethod, capitalize, autoText, editable, freezesText, ellipsize, drawableTop, drawableBottom, drawableRight, drawableLeft, drawableStart, drawableEnd, drawablePadding, drawableTint, drawableTintMode, lineSpacingExtra, lineSpacingMultiplier, justificationMode, marqueeRepeatLimit, inputType, imeOptions, privateImeOptions, imeActionLabel, imeActionId, editorExtras, elegantTextHeight, fallbackLineSpacing, letterSpacing, fontFeatureSettings, fontVariationSettings, breakStrategy, hyphenationFrequency, lineBreakStyle, lineBreakWordStyle, autoSizeTextType, autoSizeMinTextSize, autoSizeMaxTextSize, autoSizeStepGranularity, autoSizePresetSizes, textCursorDrawable, textSelectHandle, textSelectHandleLeft, textSelectHandleRight, allowUndo, enabled