Dart for Android apps with 120fps(github.com)
github.com
Dart for Android apps with 120fps
https://github.com/domokit/sky_sdk
12 comments
The obtuse answers on that thread are also the typical types of answers I see from the Android community as well. It's like the people heavily involved in Android are unaware that there is a whole other world of nicer and more efficient SDKs out there.
Did you watch the video? This project replaces everything about ui and layout within your app.
Trying to open [1] in Firefox froze the browser for several seconds. Wow, Google.
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.
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
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).
Related talk & demo: 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).
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).
The Ars Technica article on this - http://arstechnica.com/gadgets/2015/05/01/googles-dart-langu... - 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!
...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!
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.
"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.
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.
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.
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.
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?
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).
[deleted]
Like a web browser?
My web browser doesn't have many permissions to access my data (texts, contacts, location etc) - apps, on the other hand, may have a wide range of permissions and so are open to abuse.
Your web browser runs the apps that contain all of your data, like gmail, google maps, facebook, etc. If your browser doesn't correctly sandbox each site, then vast swaths of your data would be compromised.
Web browsers have the ability to use your location information, microphone, camera, and local storage. Plus the web browser is almost always running.
You may not realize it, but you already trust your web browser to protect you and safely dole out permissions. Why would a next-gen application environment be any different?
Web browsers have the ability to use your location information, microphone, camera, and local storage. Plus the web browser is almost always running.
You may not realize it, but you already trust your web browser to protect you and safely dole out permissions. Why would a next-gen application environment be any different?
Because the web browser is heavily tested and vetted, and I trust it. Whereas some apps I only trust because they have been given some (albeit maybe minimal) checking and validation prior to being allowed onto an app store. If the app I use changes under my feet with no way for me to control that, then I can't see any way of trusting the app.
> Web browsers have the ability to use your location information, microphone, camera, and local storage. Plus the web browser is almost always running.
You don't permit browser access to all that when you visit a internet page. You do on Android if you want to install an app.
You don't permit browser access to all that when you visit a internet page. You do on Android if you want to install an app.
I assume the final apk to be released would actually package the Dart code/server within itself? Kind of like React Native.
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)
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)
I guess 120Hz mobile screens are in the "soon" category now?
http://www.blurbusters.com/mobile-120hz-ips-displays-for-sma...
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...
http://www.blurbusters.com/mobile-120hz-ips-displays-for-sma...
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...
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.
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.
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.
>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.
By making it twice as efficient. Partially by using fewer cycles to compute but probably largely avoiding tiny waits that waste power without computing.
Somewhat related: VR apps will likely require more than 60fps, definitely more than 30fps, diminishing returns beyond 120fps (see 3min interview w/ Palmer Luckey, Oculus VR founder: https://youtu.be/BQoPvZGjYvQ).
I hope so, 120Hz screens would be nice for VR. I think Samsung's latest Super AMOLEDs already have 90Hz or so.
Also, rendering at 120Hz allows you to motion blur the UI on 60Hz screens very simply.
At least it makes more sense then 4K in 5" size factor.
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
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
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.
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.
Is this not possible in Java on Android?
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).
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).
> 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?
What's wrong with using GWT and J2ObjC other than the fact that there are people who don't enjoy building stuff in Java?
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/).
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...).
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?
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...).
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?
Oh GWT? I think not even Google uses it as much
http://en.wikipedia.org/wiki/Google_Web_Toolkit
Sure, let me add another layer of abstraction because some people only know Java...
Sure, let me add another layer of abstraction because some people only know Java...
For one thing, the edit-build-test cycle for mobile devices is rather slow, so there's room for improvement.
If they just don't like the language, why not just run a different language on the JVM?
They don't dislike the language (some of them even worked on the JVM's major implementation, HotSpot).
They are building a competing VM, DartVM.
Because of the way Dart (and its VM, built for its needs) was designed, they believe they can eventually outperform Java on the JVM, all the while providing a fully dynamic programming language, because of smart runtime optimizations.
If they win this bet, they'll have made an acceptable replacement for the way Android apps are built. Then, things would get inversed, and developers wishing to keep using Java would use a Java-to-Dart compiler (instead of a Java-to-JVM bytecode one).
They are building a competing VM, DartVM.
Because of the way Dart (and its VM, built for its needs) was designed, they believe they can eventually outperform Java on the JVM, all the while providing a fully dynamic programming language, because of smart runtime optimizations.
If they win this bet, they'll have made an acceptable replacement for the way Android apps are built. Then, things would get inversed, and developers wishing to keep using Java would use a Java-to-Dart compiler (instead of a Java-to-JVM bytecode one).
Android doesn't use the JVM
That makes more sense to me, Sky looks pretty cool.
Qt is also one one of the options. With it you get apps for all the platforms.
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.
Whose sponsoring the development of such a large project? It looks like the lead is a Google employee?
Eric Seidel is working on this, previously he worked on Chrome (WebKit, Blink, …).
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.
It is an unofficial side project. Same as what the go team is doing with their language.
I don't expect the Android team to switch language soon. In their own words, the engineering cost to rewrite the whole stack in another language is just too big, especially since they are not convinced that it is an obvious way to improve the platform.
In the near future, I would be less surprised to see them adopt Kotlin : it fixes many of java weaknesses, accepts java classes and produces compatible bytecode.
In the near future, I would be less surprised to see them adopt Kotlin : it fixes many of java weaknesses, accepts java classes and produces compatible bytecode.
I think its pretty exciting that Google is attacking the cross-platform development problem from many angles.
They are building Java apps like Inbox that work on many platforms, using tools like Google web toolkit and J2ObjC.
Plus there is the App Runtime for Chrome, which basically allows Android apps to run in Chrome on any desktop OS.
And now there is this Dart approach. Hopefully these different teams are collaborating and will eventually converge when one of these tools eventually takes off.
They are building Java apps like Inbox that work on many platforms, using tools like Google web toolkit and J2ObjC.
Plus there is the App Runtime for Chrome, which basically allows Android apps to run in Chrome on any desktop OS.
And now there is this Dart approach. Hopefully these different teams are collaborating and will eventually converge when one of these tools eventually takes off.
It was announced/demoed at the Dart Dev Summit earlier this week (see talk: https://www.youtube.com/watch?v=PnIWl33YMwA) which imho is fitting. It is still a bit early but you can already follow the related GitHub projects:
https://github.com/domokit
https://github.com/domokit
Why does Google have to "counter" swift?
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.
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.
AFAIK Eric Siedel and Adam Barth were two lead developers from Chrome team. Probably they have a good core team working on this.
I'd rather see the apps written in Go.
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.
Such is life.
How would that..work? Pretty much the entirety of Android apps function based on subclassing Activities, Fragments, etc - how would this work in a language without java-like inheritance?
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...
[1] http://grepcode.com/file/repository.grepcode.com/java/ext/co...