Announcement

Collapse
No announcement yet.

Google Reaffirms Commitment To Kotlin Programming Language For Android

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • tildearrow
    replied
    Originally posted by archsway View Post
    When using squashfs, the converted svg images got compressed to 14k, a reduction of 34x!
    But that's because XML (the language used in SVG) has a lot of words and hence is easy to compress.

    Leave a comment:


  • archsway
    replied
    Originally posted by tildearrow View Post

    Really? OK, I'll make up my own format then: test.ppm.zstd
    potrace did a pretty good job on most of the images, and when zipped, reduced 480k of images (there are more...) to 80k.

    When using squashfs, the converted svg images got compressed to 14k, a reduction of 34x!

    Leave a comment:


  • cynical
    replied
    Originally posted by uid313 View Post
    I think it is only a subset of Java 8, not all of it. Also Java 8 is outdated, now there is Java 13.
    It doesn't support type interference, so the code gets repetitive since you can't use the var keyword. It doesn't have support for properties with getter/setters either. I much prefer C# over Java.
    They have the major stuff like streams and lambdas, which make Java bearable. I'd love to have var, and ofc when I say modern Java is a good language I'm talking about the latest Java, but even Java 8 is such a massive improvement. Loosening the restrictions a bit and letting people just write lambdas instead of anonymous or inner classes is just amazing. I'm a lisp programmer at heart so anything that takes us a step closer to the functional paradigm is worthy of praise from me.

    The thing that most excites me is GraalVM, since I might be able to skip Java entirely and write Clojure without an application startup time or memory penalty. In fact, I love how we are moving towards targeting some kind of runtime/bytecode by default with WASM and the JVM. People should be able to write in their language of choice and get decent performance. You might save memory by not having to package a large runtime if you are using C, C++, or Rust, but regardless your code should execute with similar performance.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by archsway View Post
    Even zstd does a better job of compressing those images than png...
    Really? OK, I'll make up my own format then: test.ppm.zstd

    Leave a comment:


  • Delgarde
    replied
    Originally posted by kpedersen View Post
    Is its even possible to build an Android Kotlin project offline? Last time I checked, the whole system was so incredibly dependent on external information (thus non-deterministic), you could never rely on it professionally.
    It depends on what you mean by "offline", but generally with tools like Maven or Gradle, the dependencies are downloaded and cached, so you don't need to be online if stuff isn't cached... e.g. you've changed dependencies, or you're working on a new project and don't have its dependencies cached yet. In large organisations, it's also common to have a local proxy, so that individual developers aren't downloading from the internet but from a local server... the build machine doesn't itself need internet access.

    As to "rely on it professionally", these tools have been the standard for the Java world — enterprise development — for many years now, so I'm not sure what you're thinking of... hundreds of thousands of developers _do_ rely on it professionally. And it generally _is_ deterministic, since dependencies don't change automatically... if some package you depend on releases a new version, you're not going to find yourself automatically upgraded. It's not impossible that someone could re-publish a modified artefact under a previously-released version, but that doesn't really happen, since people quickly stop trusting projects that do that kind of stuff.

    Leave a comment:


  • archsway
    replied
    Originally posted by tildearrow View Post

    Yes, I do...
    But why would Material Design be an extra weight? Extra libraries?
    I mean, isn't it supposed to be simpler than the old one?
    I looked through the F-Droid apk and a lot of the size comes from multiple versions (for different screen densities) of a number of png images, all of which would be better represented with svg images (or even Google's own webp image format...).

    Even zstd does a better job of compressing those images than png...

    Leave a comment:


  • coder
    replied
    Originally posted by Aeder View Post
    It's funny that Google's reputation for killing products regardless of how loved they are leads to having to say things like "Yes, we will continue to support this growing programming language".
    My inner cynic just wonders whether they're scheming on switching to it as a way to get out of Oracle's litigious sights.

    Leave a comment:


  • coder
    replied
    Originally posted by bug77 View Post
    I like the whole Zen of Python (for those that don't know it: https://www.python.org/dev/peps/pep-0020/). I like the second and third to last best.
    Heh, I didn't know about:

    Code:
    >>> import this

    Leave a comment:


  • bug77
    replied
    Originally posted by sandy8925 View Post

    Uh no, they need to include components that work regardless of Android version, and across multiple devices. They also don't know what kind of weird custom changes OEMs make.

    While they can depend on some platform code, they can't depend on it entirely.

    So, it definitely won't shrink the size of an app.
    I disagree. Material Design assets come with everything released in the past 5 years or so and, while 3rd parties can customize Android, they're not allowed to remove from the official distribution. It's guaranteed they're available. You will only need to include custom widgets you've developed on top of the standard ones (and CSS + images to go with them if needed).
    In fact, what you're describing is some Chinese software that I have seen that was showing WinXP decorations when run on Win7 - they weren't using the platform supplied widgets, they were using wrong widgets because they needlessly packaged them into the app.

    Leave a comment:


  • Guest
    Guest replied
    Originally posted by bug77 View Post

    If anything, Material Design should shrink the size of an app, because most assets are now preinstalled, eliminating the need to package them.
    Uh no, they need to include components that work regardless of Android version, and across multiple devices. They also don't know what kind of weird custom changes OEMs make.

    While they can depend on some platform code, they can't depend on it entirely.

    So, it definitely won't shrink the size of an app.

    Leave a comment:

Working...
X