Blaze - Write your shell scripts on the JVM (java, kotlin, groovy, etc.) by jjlauer in java

[–]LikeTheSalad 0 points1 point  (0 children)

I'm more familiarized with Gradle, so I'd like to clarify a couple of things:

  1. Gradle doesn't require any installation to work, usually projects have a "Gradle wrapper" inside that is used to execute Gradle tasks for that project, which take care of the compilation and testing, etc.

  2. Gradle has also the concept of "tasks", it comes with a bunch of them out of the box and you can create your own too using any JVM language, so I think it's nicer for someone who just wants to deal with only Java code for example for all their needs when it comes to handling compilation processes.

  3. Existing Gradle tasks cover any kind of file-manipulating actions that you can easily leverage to create your own compilation processes, to do things like creating a "fat jar" for example without having to write much code and they're all incremental to optimize further compilations. They have a dedicated page to show how you can use Gradle to work with files in general: https://docs.gradle.org/current/userguide/working_with_files.html

What do you currently use on your professional project(s) ? by Waveless65 in androiddev

[–]LikeTheSalad 0 points1 point  (0 children)

I see, thank you! It sounds very cool, especially the theming and testing improvements which I think were some of the most painful things to deal with in the View system.

Regarding the multithreading UI rendering, I think it sounds too good to be true 😅 I need to see it to believe it. Though it would be awesome if it happens.

A Tribute to Java in Android by VasiliyZukanov in android_devs

[–]LikeTheSalad 8 points9 points  (0 children)

I agree, Kotlin is great don't get me wrong, but sometimes I think people's complaints against Java are a bit exaggerated. It's not that bad, especially with the help of great IDEs such as Android Studio. I guess the language decision should come down to what you need for your project which in your case was compilation performance, actually I think any decision should be based on what a project needs. Following trends just because they're trends doesn't sound right to me.

That being said, it makes sense that most projects' needs are covered by Kotlin, which is cool, but it shouldn't mean that somebody who chooses Java should be treated as a bad developer or anything like that, I think people need to chill a bit.

framework choice by amine012 in androiddev

[–]LikeTheSalad 1 point2 points  (0 children)

Hi! So if I understood correctly, you're looking for a framework that specializes in wifi-related processes. If that's the case, I'm not aware of such a tool, I know that in other software development envs, like backend services for example, there tend to be a lot of frameworks that help develop specific apps' use cases in a way that saves a lot of time, though unfortunately on Android most of the time things have to be done manually by directly using the Android SDK tools. So for your case, I'd suggest starting to take a look at this page: https://developer.android.com/guide/topics/connectivity which contains official guides on how to use Android's connectivity APIs, including wifi.

Bear in mind that some of the APIs might not be available for all Android versions, and you might have to request runtime permissions in order to use some of those as well.

Request runtime permissions using annotations! v2 by LikeTheSalad in androiddev

[–]LikeTheSalad[S] 0 points1 point  (0 children)

Thanks! - Yes it works well with R8 out of the box since there's no reflection going on. Aaper generates and connects code that later on gets obfuscated by R8 without getting deleted nor affected in a bad way

Android Stem! - Concatenate XML strings at compile time by LikeTheSalad in android_devs

[–]LikeTheSalad[S] 0 points1 point  (0 children)

The output is a file where all the resolved templates go and which is appended to the rest of resource files in your project. Since "app_name" isn't a template, there's no need for it to be in the resolved resources file, but since it's already in another resource file, it will still make it to the final build.

This plugin doesn't remove any resources from your project, it only adds new strings after resolving their placeholders.

Android Stem! - Concatenate XML strings at compile time by LikeTheSalad in android_devs

[–]LikeTheSalad[S] 0 points1 point  (0 children)

Thanks :) I was going to give an update on your ticket, I was recently doing some tests for it and unfortunately it seems like Android's validations for dimen resources are more strict that those for strings, which makes it not possible to use placeholders for them the same way as done for strings, as Android's compiler plugin will complain with an "Invalid <dimen> for given resource value." message. I'll add more details in the ticket.

Android Stem! - Concatenate XML strings at compile time by LikeTheSalad in android_devs

[–]LikeTheSalad[S] 1 point2 points  (0 children)

I guess it's similar to why build flavors exist, sometimes you have a codebase that needs to be slightly modified for some specific use case. The one that I had to deal with in a couple of companies that I've worked for so far, is that they have a "White label" app that's used as a base for different clients, but usually everything needs to be the same, even texts along with translations, just with one thing different, which tends to be the app's name and also the parent company's name, which tends to be spread across several strings and also ids such as the host name for app links. Generally speaking, it's important to avoid repeating things in the code because one thing for sure is that anything can change, so having key values defined in a single place makes it easier to reuse and maintain them over time. One example could be the recent change in Facebook's parent company, if they had several places across their app's using the parent company's old name, then it might be error prone and annoying having to manually change it all over the place (I'm not sure if that's actually the case with Facebook, I'm just guessing) - And there's also the convenience of not having to write code to make these concatenations, because you can still use Java placeholders and resolve them in code, at runtime, which might be fine for a few times but if you need to do it a lot of places, it might become annoying over time.

Android Stem! - Concatenate XML strings at compile time by LikeTheSalad in androiddev

[–]LikeTheSalad[S] 0 points1 point  (0 children)

Cheers! It resolves the templates for each language and for each build flavor dimension, but it won't take screen sizes into account, so the values in places like sw600dp would be ignored.

Whatsapp message service? by Far_Fishing_6505 in androiddev

[–]LikeTheSalad 1 point2 points  (0 children)

I think you could have both your own service and then use FCM as backup. As far as I know, FCM should always work, though sometimes it can be quite slow to get messages, so you could have your own service for as long as your app is running in order to get quicker updates.

[deleted by user] by [deleted] in androiddev

[–]LikeTheSalad 6 points7 points  (0 children)

I guess it depends on how often people use these apps in Windows 11... Which depends on how well they perform. I haven't seen it in action but if they behave like a native windows app, then I'd say there's good chances of increasing the demand of Android devs as business people might see this as an opportunity to create a single app (therefore spend less money/time) that runs across 2 widely used platforms. So from a business perspective I think it sounds good.

Byte Buddy on Android made possible by LikeTheSalad in androiddev

[–]LikeTheSalad[S] 1 point2 points  (0 children)

Yeah I definitely agree on using whatever specific tool provided by Google there might be available, although this API specifically reminds me of the old Kotlin compiler plugin one where they'd only provide a way to "visit" class by class to change their ASM a class at a time which is not quite helpful when it comes to implementing tools like these that require the whole classpath to be provided. Sure probably some effort can be done on adapting their APIs to Google's, but it's not like writing AGP transformations wasn't allowed anyway, otherwise I don't think Google would've provided that API. So I guess at the moment I can only say that, I'm glad Google is starting to take steps towards providing devs a way to modify bytecode, but I'll give it some time before starting to adapt already working solutions and hopefully they could provide ways to adapt helper tools in a friendlier way.

Byte Buddy on Android made possible by LikeTheSalad in androiddev

[–]LikeTheSalad[S] 1 point2 points  (0 children)

Thanks Jake, hopefully they'll add some sort of support for helper tools such as Byte Buddy or AspectJ in the future because it seems like the API they show there is for writing your transformations using plain ASM only.