Live data from Hacker News

First Preview of Android N: Developer APIs and Tools

android-developers.blogspot.com

41–50 of 74 posts

Re: First Preview of Android N: Developer APIs and Tools

#41

I'm disappointed to see that it will take Android N for the Doze feature to be practical [0]. As it currently stands, Doze only activates when the device is stationary. My phone never leaves my pocket, since I'm paranoid about setting it down, so the gyrometer being engaged is enough to prevent Doze from triggering. [0] http://www.androidpolice.com/2016/03/09/android-n-feature-sp...

This is very true, but I think doing it one step at a time is a good way to slip into a more power-efficient system without breaking tons of top apps.

Too many top apps were dependent on constantly waking up and doing network or other expensive jobs. So for M Google says 'these things won't happen when the user leaves the phone on a desk for 30m+' which spurs people to prepare for this new world even if they won't encounter it much. Now with N Google is saying 'this will happen when the screen is off for a few minutes' and now any decent app needs to prepare for this, but the best apps already got into this new world for M.

Re: First Preview of Android N: Developer APIs and Tools

#42

I was really hoping for something more exciting. Like maybe native support for a new, different language (like Apple did with Swift). It would be absolutely amazing if Google came out with a mechanism for building native apps in, say, Rust.

To do that, all they'd really need to do is have a mechanism to build native apps in C, after which various language communities would be able to write simple wrappers that would allow them to use said C API. To an extent, that partially exists in the form of Android NDK, but that's not really a full solution. If and when Google makes it possible to easily create your entire app natively (with a clean C API), then yo…

It won't happen.

The last years the NDK support has always been seen as something to help bring "legacy" code from other platforms, be consumed from Java to help speed up some algorithms, games.

In fact, apparently they are now closing down the door to rogue developers that used to link to unofficial platform libraries.

If you look at the Tango SDK, apparently they have a C API to some platform APIs, however when one digs into them, they are wrappers to functionality implemented in Java.

Re: First Preview of Android N: Developer APIs and Tools

#43

I was really hoping for something more exciting. Like maybe native support for a new, different language (like Apple did with Swift). It would be absolutely amazing if Google came out with a mechanism for building native apps in, say, Rust.

To do that, all they'd really need to do is have a mechanism to build native apps in C, after which various language communities would be able to write simple wrappers that would allow them to use said C API. To an extent, that partially exists in the form of Android NDK, but that's not really a full solution. If and when Google makes it possible to easily create your entire app natively (with a clean C API), then yo…

It's easy to run other languages on Android (see Go binaries). It would be a huge effort (and some would say a distraction) to port the Android SDK to another language. It would also fragment the developer ecosystem if that language was not compatible with Java libraries (reducing your choices to Scala, Clojure, etc).

While the NDK is hard to use, it is enough to enable alternate modes of Android development. For instance with Unity you can develop and Android app using C# and the Unity graphical editor. That's a very powerful option for certain classes of apps.

Re: First Preview of Android N: Developer APIs and Tools

#44
post #40

Earlier quoted context omitted.

To do that, all they'd really need to do is have a mechanism to build native apps in C, after which various language communities would be able to write simple wrappers that would allow them to use said C API. To an extent, that partially exists in the form of Android NDK, but that's not really a full solution. If and when Google makes it possible to easily create your entire app natively (with a clean C API), then yo…

Qt has already been ported to Android via the NDK. Nothing stops other UI frameworks from doing the same.

Having used the 4.3 version I wouldn't recommend it, specially since looking at the web site it seems anything has hardly changed in that area since my attempt.

It adds very little value over Java + NDK on Android.

The Android native widgets aren't supported, rather emulated via QML and only the most well known ones.

For the majority of Android APIs no support is provided, offering no advantage over we having to write our own JNI wrappers.

Also iOS and Windows Phone support are even worse than Android.

Re: First Preview of Android N: Developer APIs and Tools

#45
post #3

Woah: >Improved Java 8 language support - We’re excited to bring Java 8 language features to Android. With Android's Jack compiler, you can now use many popular Java 8 language features, including lambdas and more, on Android versions as far back as Gingerbread. The new features help reduce boilerplate code. For example, lambdas can replace anonymous inner classes when providing event listeners. Some Java 8 language…

While it's certainly a change for the better, personally I find the Streams API is still clunky and lacking. In compare to LINQ, or Kotlin (case in point: http://stackoverflow.com/a/34642255).

Re: First Preview of Android N: Developer APIs and Tools

#46

I was really hoping for something more exciting. Like maybe native support for a new, different language (like Apple did with Swift). It would be absolutely amazing if Google came out with a mechanism for building native apps in, say, Rust.

That doesn't feel like the primary problem with Android. The lowest hanging fruit in that department is officially supporting Kotlin which is gaining traction in the community already.

Re: First Preview of Android N: Developer APIs and Tools

#47
post #25

Earlier quoted context omitted.

Sure, but ask yourself if that's a market you want to target. Do you care if digital signage terminals can run your app?

I really care if digital signage terminals can run my apps, because I sell digital signage terminals with these apps installed.

Then make the business case to the right stakeholders that supporting the latest versions of Android is important. I don't see how the digital signage ecosystem not staying up to date is Google's fault.

I have millions of installs for my apps and my minSdk is 16, and I'm very close to bumping it to 19.

Re: First Preview of Android N: Developer APIs and Tools

#48

Earlier quoted context omitted.

> no optimizing apps step after system update. That is fantastic news. Every single time my Nexus 6P gets an update it feels like it takes at least 15 minutes to "optimize apps". Every. Single. Update.

The effect will be even more amazing for non-nexus/carrier devices with bloatware - my work phone (VZW M8) just got Marshmallow and it took couple hours to complete - most of the time was spent on twice optimizing 303 apps! (Only 30-35 out of those are things I installed.)

Well, those devices rarely get updates anyway.

Re: First Preview of Android N: Developer APIs and Tools

#49
post #43

Earlier quoted context omitted.

To do that, all they'd really need to do is have a mechanism to build native apps in C, after which various language communities would be able to write simple wrappers that would allow them to use said C API. To an extent, that partially exists in the form of Android NDK, but that's not really a full solution. If and when Google makes it possible to easily create your entire app natively (with a clean C API), then yo…

It's easy to run other languages on Android (see Go binaries). It would be a huge effort (and some would say a distraction) to port the Android SDK to another language. It would also fragment the developer ecosystem if that language was not compatible with Java libraries (reducing your choices to Scala, Clojure, etc). While the NDK is hard to use, it is enough to enable alternate modes of Android development. For ins…

OTOH, that same fragmentation also means competition. Allowing for multiple independent languages to run on the platform means a plethora of developers to whom the platform is now accessible.

Having an API that is easy to use would really open up the ecosystem. Also, having much faster, machine targeted code (ie: compiled with CPU architecture and model specific optimizations and instructions) in C, C++, Rust, Go, etc. would mean better performance and less battery usage in some apps, which overall would translate to a superior user experience.

Re: First Preview of Android N: Developer APIs and Tools

#50

Extremely interested in the multi-window support. With phone screens getting bigger than ever, this could be a very useful feature for multi-tasking

I found Samsungs implementation very useful on my Galaxy Tab S 10.5. I would read a pdf for example and take notes in the other. I tried using it for simple development as well, running a local dev server. Unfortunately js ides were still lacking on Android last time I tried, but it's clearly something that could be improved.

Definitely super excited for Android itself to have this feature.

Post reply on HN