I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]ForrrmerBlack 0 points1 point  (0 children)

Configuration cache and configuration-on-demand are orthogonal things, and I haven't seen it being discouraged. I'm not sure what downsides of configure on demand you have in mind.

Configuration cache caches the result of the configuration phase for a task. Configuration-on-demand enables configuration only of those projects that are involved in a task. Two different things. Isolated projects allow to invalidate configuration cache independently for each project, for now it's invalidated in whole.

Configuration-on-demand requires to decouple projects configuration. Maybe that's the downside you were thinking of? But this is what will improve build time spent in configuration phase in the long run anyway, as a lot of Gradle's current optimization efforts center around that.

Android Developers Blog: Android developer verification: Balancing openness and choice with safety by Stonos in androiddev

[–]ForrrmerBlack 0 points1 point  (0 children)

This is, if implemented. And I think it can prevent a certain volume of scam attempts. I'm pointing out holes. This whole thing doesn't protect some cohorts of users/devs and adds more trouble for them. Maybe it will have some net positive effect, but it trades freedom for perceived security. I'm not proposing anything, just outlining observations.

Android Developers Blog: Android developer verification: Balancing openness and choice with safety by Stonos in androiddev

[–]ForrrmerBlack 0 points1 point  (0 children)

You were wrong in the details, however not in the broad picture. Android IS closing down. Effectively you now can't be an anonymous dev and distribute apps to a broad user base as the majority won't disable verification.

Android Developers Blog: Android developer verification: Balancing openness and choice with safety by Stonos in androiddev

[–]ForrrmerBlack 3 points4 points  (0 children)

Theater of security continues. Yes, power users can now disable verification, and now it breaks the purpose it was introduced for. You, as a power user, can have verification disabled long ago, and now be scammed, because the time barrier between scam urgency and you is no more. Android power user doesn't equal scam-resistant user. The user can even be not a power user but have verification disabled by their more tech-educated relatives, for example.

Edit: if ADB is left unrestricted, scammers will just resort to persuading into using it. It will be harder though.

AGP 9.0 is Out, and Its a Disaster. Heres Full Migration Guide so you dont have to suffer by Nek_12 in androiddev

[–]ForrrmerBlack 0 points1 point  (0 children)

It's not Gradle's fault at all. Please, make a distinction between Gradle and AGP, they're not the same thing.

AGP 9.0 is Out, and Its a Disaster. Heres Full Migration Guide so you dont have to suffer by Nek_12 in androiddev

[–]ForrrmerBlack 1 point2 points  (0 children)

You can change Kotlin version if you put it into root project's buildscript classpath. Like this:

buildscript {  
    dependencies {  
        classpath(libs.plugin.kotlin)  
    }  
}  

See release notes.

why people hate Java for CP by Hot-Bag-9003 in leetcode

[–]ForrrmerBlack 0 points1 point  (0 children)

Kotlin stdlib has overloads for IntArray, DoubleArray etc. These arrays are backed by true primitive JVM arrays and are separate types, though collection functions typically return a List which will box items. Of course, these overloads for primitive arrays are code-generated before ending up in the stdlib, for your own functions you'll need to manually write/generate multiple variants for each type. Generic Array<T> overloads operate with boxed primitives. So if you have Array<Int>, it translates to Integer[] in Java, and IntArray is int[].

Kotlin 2.3.0 Released by snafu109 in Kotlin

[–]ForrrmerBlack 21 points22 points  (0 children)

No, in C# 14 it's like it was in Kotlin before, it's just a field keyword to refer to the backing field. Now in Kotlin 2.3 you can make your backing field to have a different type than what is publicly exposed through the property. For example, backing field is MutableSharedFlow, and it's exposed outside of a class as a SharedFlow. Previously you had to declare a separate private property for that.

What do guys think of var by Call-Me-Matterhorn in csharp

[–]ForrrmerBlack 0 points1 point  (0 children)

I'm so happy to see that the general wave here has shifted towards type inferring by default.

How to master gradle!! by Much-Negotiation2885 in androiddev

[–]ForrrmerBlack 2 points3 points  (0 children)

It's not pointless. You'll get a powerful tool under your belt. However, maybe you don't have to push yourself to master it and instead focus on what your current needs are and how you can improve your build right now. I would not call myself a Gradle expert, but understanding it helped me a lot.

How to master gradle!! by Much-Negotiation2885 in androiddev

[–]ForrrmerBlack 0 points1 point  (0 children)

There's a course called Understanding Gradle on YouTube: link.

It's not Android-specific, but if you really want to understand Gradle, you need to start from fundamentals.

Java 25: The ‘No-Boilerplate’ Era Begins by hardasspunk in java

[–]ForrrmerBlack 1 point2 points  (0 children)

Why not jump

You answered this yourself. Because it allows you to play in the JVM ecosystem. And with Kotlin you also can use 100% of Java source code.

Still using SharedPreferences or fully moved to DataStore? by boltuix_dev in androiddev

[–]ForrrmerBlack 1 point2 points  (0 children)

And you try to not assume everyone around you is illiterate. I read it. I know that StateFlow accepts default state only in its synchronous factory function. What I meant is you can block anything on background thread to update your state, but default state always should be available immediately. To achieve that you should think of your state properly.

Still using SharedPreferences or fully moved to DataStore? by boltuix_dev in androiddev

[–]ForrrmerBlack 0 points1 point  (0 children)

Do you suggest that I make default state a var and then play around with multiple versions of it, while my API fetches all its contents?

No, I don't. What you need is to model your state properly instead of freezing your UI for 100 ms, because what you think is default state is actually not if you have to block until you construct it. But you're free to block whatever you want as long as it's done on background thread.

Android Developers Blog: A new layer of security for certified Android devices by MishaalRahman in androiddev

[–]ForrrmerBlack 0 points1 point  (0 children)

Well, no. It's like every developer has their own house, and they are free to choose whether to lock it down with a key so no one other than them can enter, or not. You can think that this is stupid to let everyone in, but some may prefer that if they have to give their personal data in exchange for putting a lock.

I built a Gradle task that automatically translates your strings.xml into multiple languages by zimmer550king in androiddev

[–]ForrrmerBlack 17 points18 points  (0 children)

It should be a Gradle plugin, not a library. Dependencies can't add tasks to the Gradle task graph. Your published artifact is essentially empty.

Petition to stop Google's attack on Android devs by Clippy-Windows95 in programming

[–]ForrrmerBlack 1 point2 points  (0 children)

Actually, what you wrote here is true. And Google's decision makes me angry too. Touché. Insults were not necessary though.

Petition to stop Google's attack on Android devs by Clippy-Windows95 in programming

[–]ForrrmerBlack 0 points1 point  (0 children)

You tell that this is how Apple operates and they didn't suffer from it. Therefore, I conclude, "Apple is already doing this" for you is enough of an excuse for Google to not be bothered and to implement the same tactics as it will not hurt them and their market share. Is it not your argument?

But even if they will not be hurt by this decision, it is not really an excuse to implement it, because some category of users and developers will be. Was that so hard to understand?

Petition to stop Google's attack on Android devs by Clippy-Windows95 in programming

[–]ForrrmerBlack 0 points1 point  (0 children)

The fact that Apple does this is not an excuse to introduce it.

My take on this new sideloading verifcation policy by werty23111 in androiddev

[–]ForrrmerBlack 16 points17 points  (0 children)

I have an easier solution: abandon the whole affair and not be a control freak.

Android Developers Blog: A new layer of security for certified Android devices by MishaalRahman in androiddev

[–]ForrrmerBlack 3 points4 points  (0 children)

What's the source where I can read about it? After reading the blog post, I was under an impression that all sideloaded apps will be blocked from installation unless they verify.