141–150 of 157 posts
You should try iOS dev.
It's amazing Apple hasn't fixed the bug where switching branches will break an Xcode build. https://stackoverflow.com/questions/78244976/package-resolve...
Android development is not simple. Take time to learn the architecture and underlying concepts. It took me a couple of weeks and some false starts to make sense of things (although back then I was a college student; a professional can probably get started faster).
Earlier quoted context omitted.
It's incredibly robust compared to Windows https://recorder.easeus.com/screen-recording-resource/macos-... https://lifehacker.com/tech/mac-os-sonoma-update-fixes-scree... ... okay I don't even know what's this :D
Funny, for a lot of the functionality you get with Windows you have to pay some random dev for with MacOS. Window management alone feels like it's baby's first computer.
Earlier quoted context omitted.
>got this cryptic error: > 'lib/libjpeg.so' missing whats cryptic about that?
I get the sense that the only development environment the OP knows at all is Python. With that perspective I understand why they might think that error is cryptic.
Earlier quoted context omitted.
>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…
> The fact that pointing that out as a flaw gives you "junior programmer vibes" is seriously concerning. It's the fact that you hand wave away Text rendering as "just showing text" while claiming you've made your own. Then claim that platform code is terrible because it...uses flags to determine what platform it's on and use the appropriate commands... THAT is what gives me JR eng vibes. > Also, you failed to address…
I didn't wave away "text rendering" at all. TextView as nothing to do with text rendering. Have you tried reading the code? Also, even if it did, that would not make it any better. Your claim that TextView is good code because it implements everything from text layout and rendering to text editing is actually much much worse that it simply doing what it really does, which you would know if you would just read and understand the code. Why you have not done so by now is puzzling. Think of it this way: if you were looking at the source code of a text editor, would you expect the whole program to consist of just two classes? That is always going to be bad code.
>Then claim that platform code is terrible because it...uses flags to determine what platform it's on and use the appropriate commands...
Windows has backward compatibility going multiple decades. It even used to ship with a DOS emulator to ensure you can run programs from 30 years ago on it. Linux too has never broken ABI compatibility (although the same cannot be said for user space). Yet you seem to think it is fine for Android to break its API every update. Have you developed for any other systems? I get the feeling that all you know is Android and its awful SDK so you feel you have to defend it.
>Yeah, when talking about components A-Z and the structure around them you don't typically need to point out that X will be included, but here we are.
No. There were two points I made in the post you responded to. One was a very specific point about TextView where I gave my arguments as why it is bad code and in which I pointed out that you never even read the code we were talking about. The other was a side point about deprecating APIs in Android. You decided to ignore the entire main points of my post and only respond to the side point.
Earlier quoted context omitted.
>textSelectHandleLeft, textSelectHandleRight Done >textColor, typeface, textColorLink, textFontWeight, textStyle handled by TextPaint in StaticLayout/DynamicLayout. For example textColorLink is just `linkColor` from TextPaint.[0] >text, textSize, maxLines, justificationMode, breakStrategy, hyphenationFrequency, lineBreakStyle handled by StaticLayout/DynamicLayout >shadowColor, shadowDx, shadowDy, shadowRadius mTextPa…
> Only needed if you add a text editor into your text view, which I did not do. > I'm not going to go through all of these because I'm not sure exactly which side implements them (for example elegantTextHeight sound like something TextView does, but I'm not sure.) I suggest you actually sit down to read TextView before you make comments about it. Which is exactly my damn point, you expect your case to be the only one…
I expect the text editor to be a different component. Take a look at any other UI toolkit's text view like Swift for example:
>A view that displays one or more lines of read-only text.[0]
or QT:
>QLabel is used for displaying text or an image. No user interaction functionality is provided.[1]
In fact, even for just displaying text, I still expect rich text to be handled by a separate component. In Flutter you have RichText for example.[2] I don't know why are are confusing separating components with the components existing at all. Yes, "just displaying text" should be a simple component, because any reasonable UI toolkit will have already abstracted out all the layout code into a level bellow the user facing widgets, and the simple text component will just call into that.
>Have you handled LTR text correctly
That is handled by Layout via setTextDirection, not TextView. This is what I meant by saying you should read the code. Also I already mentioned text direction in my previous comment in this chain which I see you have not bothered to read.
>custom unicode in fonts, weird alignment issues due to accent marks?
Huh? Just read the code. TextView is not doing any of that.
>My guess would be no
All you have to do si wire up these fields from the XML input (another awful ASDK technology). That's really what TextView is meant to do: send its values to the underlying Layout and handle text selection like copy-paste. I didn't want to wire up XML that I don't need so I didn't. None of it is particularly hard.
[0] https://developer.apple.com/documentation/swiftui/text
[1] https://doc.qt.io/qt-6/qlabel.html#details
[2] https://api.flutter.dev/flutter/widgets/RichText-class.html
Earlier quoted context omitted.
containers/podman > [Feature]: Android support: https://github.com/containers/podman/discussions/17717 : > There are docker and containerd in termux-packages. https://github.com/termux/termux-packages/tree/master/root-p... But Android 13+ supports rootless pKVM VMs, which podman-machine should be able to run containers in; (but only APK-installed binaries are blessed with the necessary extended filesystem attributes…
Wait so you're telling me I can run podman on android?
Earlier quoted context omitted.
It would be interesting to see where this doesn't happen, you can't just update stuff without considering breaking changes and new bugs in new updates
Difference is that you only have to take your lunch break for it to happen in web dev. By the time you get back to work the following day the framework you're using is deprecated. At least with other platforms there tends to be a bit more stability.
You won't have to touch any horrible Kotlin nor Swift but still be able to publish the app on the stores if you want to.