
Dart for Android apps with 120fps - xbmcuser
https://github.com/domokit/sky_sdk
======
cel1ne
The problem with Android isn't Java, but that it has one of most terrible,
buggy, undocumented and confusing SDKs I have ever seen. It tries hard to
touch every anti-pattern on the planet.

Android could be much more performant, but one would have to replace almost
everything regarding UI and layout. Apps built with Dart cannot be much faster
unless they do that.

I thought about rewriting/extending the base-class "View.java" to get more
performance and less bugs (the default layouting algorithm seems to have
exponential runtime! [0]), but the problem is

a) it would break compatibility with many other UI-components and

b) the behaviour and structure of the code is almost impossible to understand
and imitate.

Just look at this beast: 8866 LOC without comments in one class [1].

[0] [https://stackoverflow.com/questions/17493819/is-android-
layo...](https://stackoverflow.com/questions/17493819/is-android-layout-
really-exponentially-hard)

[1]
[http://grepcode.com/file/repository.grepcode.com/java/ext/co...](http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.0.2_r1/android/view/View.java)

~~~
bane
That's kind of scary that it passed internal code reviews and made it into
production without comments. It speaks to Google's internal processes quite a
bit.

~~~
duaneb
It has comments. They do not contribute to the line count.

------
tosh
TL;DR framework to build native Android applications using Dart that have
highly performant native UI (think React-Native retained mode, functional
style).

Related talk & demo:
[https://www.youtube.com/watch?v=PnIWl33YMwA](https://www.youtube.com/watch?v=PnIWl33YMwA)

The exciting thing here is that from a developer's point of view sky is just a
Dart package and you can immediately start to write an Android application but
still keep a fast feedback loop similar to web development (like you've seen
in React-Native demos).

~~~
tosh
It is still a bit early but the Q&A in the end hints that eventually you might
be able to have a Dart code base that drives native apps on Android, iOS and
basically any platform you want to support with a development cycle that feels
like web development (tooling, feedback cycle, debugging power) and yet gives
you highly performant native apps (120fps, very responsive to touch
interactions).

------
joosters
The Ars Technica article on this -
[http://arstechnica.com/gadgets/2015/05/01/googles-dart-
langu...](http://arstechnica.com/gadgets/2015/05/01/googles-dart-language-on-
android-aims-for-java-free-120-fps-apps/) \- has a worrying comment:

... _the majority of the app is served over HTTP, allowing for continuous
deployment where everyone always runs the newest version. URLs are a base
layer of DART, so everything is internet aware. The downside to this is that
the demo app doesn 't work when you're offline, and starting the app takes a
second or two because it needs to download data._

So this is effectively a permanent 'wget |sh' kind of system? Sign me up!

~~~
tosh
You forgot to quote the next sentence:

 _" Both of these could be solved with caching, though."_

Sounds like it is up to you if the app you deploy to the app store will have
this ability or not or on which side of the spectrum you want to be.

When you look at the Facebook app (or other popular apps) they've found ways
to 'update' parts of the application (or behave differently eg for a/b testing
of new functionality) without the user having to download a new version.

~~~
joosters
Yup. It's up to 'you' \- you being the app writer. The poor shmuck who
downloads the app has no choice or control over it.

~~~
evv
What web browser do you use? It probably updates itself on a regular basis.

Do you use any web apps? Those are updated and re-downloaded regularly,
depending on how the app is built.

If you use an Android or iOS-based device, the software on it often becomes
out-of-date and requires an upgrade in order to restore and improve
functionality.

The app writers should have such control. The 'poor shmucks' have as much
power as always in this ecosystem, because they can choose what apps they want
to trust and use.

~~~
joosters
I'm looking at this from Android, as that's the initial target and discussion
here. If I download an app from Google's app store, I have _some_ confidence
that the app is well behaved and has been checked for obvious malware... But
if the app depends on remote code that can change when it likes, how can I
ever be confident in using that app and granting it permissions?

~~~
choudanu4
In the Dart Conference talk, they mention that sky apps (DART apps on Android)
are given access to ever permission the system gives them. These system given
permissions will almost definitely work in the Play-store way (as opposed to
asking whenever it is required, a la website style).

------
shadowmint
This is a significantly more compelling use for Dart than anything else I've
seen.

Dart team; stop screwing around and pay attention to this! Dart has failed as
a browser script language, but its a good language in itself.

A cross platform language for building high performance apps, with a good
package management solution and tooling... Thats a compelling use case.
Something like a cross platform Swift...

Add some compiles to native binaries (or some kind of runtime bundling like
xamarin do) and you'd have a pretty interesting piece of tech there.

('lets focus on our to javascript compiler for the dart compiled from
typescript because the dart runtime is never going into Chrome or any other
browser' is not. Stop running down that ridiculous road already)

------
comex
I guess 120Hz mobile screens are in the "soon" category now?

[http://www.blurbusters.com/mobile-120hz-ips-displays-for-
sma...](http://www.blurbusters.com/mobile-120hz-ips-displays-for-smartphones/)

I'd be quite interested to see one for myself and get an idea whether it makes
for a noticeably smoother experience. I expect there will be a lot of trouble
getting software to reliably hit that number, though, especially Android...

~~~
Zr40
Even with a 60 Hz screen this will be advantageous. If the application is fast
enough to render at 120 fps, rendering at 60 fps means that the UI thread will
be idle at least half of the time, so the processor will draw less battery
power.

~~~
runeks
I don't get it. How will you achieve enabling your application to render at
120 fps, instead of 60 fps, without leveraging a twice as powerful CPU/GPU,
which will use roughly twice as much power?

I would think the added power draw from rendering at 120 Hz would come from
all the applications needing double the number of graphics-calculations they
need at 60 fps.

~~~
Dylan16807
>I don't get it. How will you achieve enabling your application to render at
120 fps, instead of 60 fps, without leveraging a twice as powerful CPU/GPU,
which will use roughly twice as much power?

By making it twice as efficient. Partially by using fewer cycles to compute
but probably largely avoiding tiny waits that waste power without computing.

------
xxgreg
Building an Android app with Sky is basically similar to using phonegap. i.e.
You use HTML/CSS and web components, but it promises better performance and a
more modern api.

The codebase is a forked version of chromium, but with a lot of legacy web
cruft removed. The DOM api is replaced with a new more modern api. CSS has
some important performance bottlenecks removed.

It also allows linking to off main thread code written in C++, Java, Go, JS,
Python and Dart. Main thread code must be written in Dart.

They are aiming for the performance of native, but with a development toolset
similar to the web.

IMHO a very worthwhile experiment.

Edit: The specs here give an idea of what the system is/does.

[https://github.com/domokit/mojo/tree/master/sky/specs](https://github.com/domokit/mojo/tree/master/sky/specs)

------
on_and_off
That's an interesting experiment. The demo is extremely underwhelming though.
I have to wait ~5 seconds for each screen to load, while on a wifi network. I
don't know if it is dues to Dart framework or the http code loading, but it is
way too high to be acceptable. The stocks app demo is a trivial exemple. A
simple list with nothing else except for a nav drawer. It is very fluid but
also extremely barebone.

Same thing for the square spinning at 60 fps. Call me back when there are 1000
of these.

Don't get me wrong, it is a very interesting experiment but it is hard to get
excited for something so limited.

------
sosuke
Is this not possible in Java on Android?

~~~
tosh
There are people who don't enjoy building stuff in Java and want an
alternative (like Dart). There are also people who don't want to learn (or
like) the existing Android APIs.

Sky opens the door to use Dart on the server side, on the web as well as for
highly performant native apps for Android (and eventually for other platforms
like iOS).

~~~
esteer
> Sky opens the door to use Dart on the server side, on the web as well as for
> highly performant native apps for Android (and eventually for other
> platforms like iOS).

What's wrong with using GWT and J2ObjC other than the fact that there are
people who don't enjoy building stuff in Java?

~~~
tosh
I don't see anything 'wrong' with GWT, just as there is nothing inherently
wrong with writing iOS apps using Ruby
([http://www.rubymotion.com/](http://www.rubymotion.com/)).

For example the Inbox team did a fantastic job re bringing a great user
experience to multiple platforms and I guess they were glad that they could
use one language throughout instead of having to jump between various tools
and idioms (see [http://gmailblog.blogspot.com/2014/11/going-under-hood-of-
in...](http://gmailblog.blogspot.com/2014/11/going-under-hood-of-inbox.html)).

It's just that like you mentioned people do have different preferences when it
comes to languages/tools/ecosystems. That's all.

There are people building web services using PHP, Ruby, Python, Java, Haskell,
Elixir, Erlang, Go, C++, JavaScript, Dart. Why not also have this choice on
mobile?

------
eklavya
Qt is also one one of the options. With it you get apps for all the platforms.

------
dheera
What are the hardware display refresh rates of these devices? If it can do
120fps I'm more interested in putting my phone on a spinning motor and turning
it into a volumetric projector.

------
Osiris
Whose sponsoring the development of such a large project? It looks like the
lead is a Google employee?

~~~
tosh
Eric Seidel is working on this, previously he worked on Chrome (WebKit, Blink,
…).

~~~
guelo
I've been half expecting that Google would announce something like this at IO
as a counter to Swift. But this makes it look like an unofficial side project.

~~~
Grazester
Why does Google have to "counter" swift?

~~~
tosh
Imho it makes sense for both Google on Android (Java) and Apple on iOS
(Objective-C) to provide more (and more) modern alternatives to develop
applications for their platforms.

There certainly are people who are happy with Java and Objective-C but there
are many who'd like to use different languages/runtimes/ecosystems.

The popularity of projects like Cordova and CrossWalk show how much demand
there is to build applications using web technology even if you have to pay
for it in performance.

Sky is a way to use Dart without having to compromise on application
performance nor on development feedback speed and debugging tools.

Also think of the people (whether large or small companies) who have to
support multiple platforms (Web, Android, iOS, Server, …) simultaneously and
right now are forced to use multiple languages and tools for
building/debugging. This is incredibly costly, especially if you want to
deliver high quality products.

------
higherpurpose
I'd rather see the apps written in Go.

~~~
yoklov
And I'd rather see them written in native code, using a native API that
doesn't require awkwardly traveling through Java.

Such is life.

