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].
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.
Granted, the use of word "bugs" was a bit too much.
I consider it a bug when ´Environment.getExternalStorageState´ tells me the SDCard is mounted, when the SD-slot is empty. That was because parts of Samsung's internals storage where referred to as external storage.
I consider it very bad design when Android allows me to write Views that cause layout-passes multiple times during construction. (Because of setTypeFace). That Views are riddled with methods which cause re-layouts mixed with others that don't. There should be an annotation for this.
I know, nowadays there's a logging-statement if that occurs, that wasn't there in Android 4.2 IIRC.
On a complicated app you can either do proper separation of concern and compose everything in nested Views, but you have to throw everything back into a single View to get more performance. Or you write your own layout-manager which is what I did.
It's impossible to define constraints on animations. I can't tell android, hey that view is going to change it's height, but not it's width and it won't affect anything else, so save yourself some time and stop calculating the height of this letter for the 546th time in the last 10 seconds. rantrant
Hardware-Acceleration is a different matter. I ended up disabling it completely, because it would accelerate some animations, fades and make some other parts jittery. Most fine-grained layer-control specified in the Guide doesn't seem to affect anything.
And so on, and so forth.
Android development is painful compared to other SDKs and that's why app-quality is so low. You can claim that stems from confusion: no it doesn't, i've read large parts of the (UI) code by now and I've written software in many languages for many years.
Or ignorance: Maybe in the sense that I refuse the reason for all this: That most of Android was baked hastily in the beginning to get something out and fixing mistakes which would require most APPs to be redone is close to impossible. Android is the new Windows. ;)
I still don't see why this is a bad thing. Sure it would be nice if they split the file into multiple source files for maintainability. But, should we also chastise the Linux kernel for having source files that have more than 5K+ LOC that aren't documented nearly to the extent the Android source is?
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.
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 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!
"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.
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.
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).
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?
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.
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)
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 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.
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).
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.
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.
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).
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?
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).
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.
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.
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.
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:
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.
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...