• Android "L" at Revealed at Google I/O, Looks Rad! (Also Android in your car and TV)
    50 replies, posted
AWFUL! I mean, SERIOUSLY?! [img]http://i.imgur.com/x0ehVUO.png[/img] How is this NOT a privacy issue?!
I've got to admit, I was extremely impressed (though bear in mind, I'm no smart-device tech junkie) with how easy to use and how fluid the control of my Nexus 7 tablet was due to its design considerations in each app and the android layout. The tabs system blew me away, you can open up multiple apps in seconds, press the tab button and flick-close any of them instantly. The back button was even a surprise. The drop down menu in the top right corner that gives you easy to adjust brightness, a settings/Wi-Fi shortcut and auto-rotate lock was really good. This was after having had a 3rd generation Ipod only before, which in comparison now seems like complete and total junk. I've seen the new Iphone generation and I can see where they've attempted to copy some of those things, but still overall it looks far more clunky.
[QUOTE=Map in a box;45224252]AWFUL! I mean, SERIOUSLY?! [img]http://i.imgur.com/x0ehVUO.png[/img] How is this NOT a privacy issue?![/QUOTE] Have you never used Google Maps before?
I can't wait for Samsung and LG to shit all over the new UI! [editline]26th June 2014[/editline] [QUOTE=Profanwolf;45214414]Maybe I wasn't very clear, but I was referring to people looking at the examples, be it users or developers. Developers are people too :v:[/QUOTE] I'd rather the dev team work on bugs instead of rebuilding the entire rendering system in HTML5. If I want to play with it, I'll just download the example code. The AndroidDevelopers website has come a hilariously long way in the last few years.
[QUOTE=itisjuly;45223442]It's just developing apps in C#, it does not make your android run in MONO vm. Not to mention xamarin is expensive. The free version has app size limit which is so small you will hit it after a few dozen code lines. Java is less than ideal VM these days. Especially for phones where battery life is kind of a big deal.[/QUOTE] Android itself is running on a modified Linux kernel (written in C). It's just the apps (including system apps) that are written in Java. They aren't running on the Java VM (Hotspot) though. They are running in Dalvik which was written specifically for low memory and low storage devices. Now we have much more RAM and storage and Dalvik will be replaced by ART.
[QUOTE=.Lain;45216740]lol [editline]26th June 2014[/editline] apple unlike google don't change their UI every other year[/QUOTE] This is literally the second change they've had in their 6-ish year history of the OS.
[QUOTE=itisjuly;45219920]How about a VM that is not Java then? Something .net/mono like?[/QUOTE] The JVM isn't the problem. Especially considering that Google wrote their own rather than using Sun/ Oracle or the OpenJRE. Java is pretty fucking fast today on desktops, this is pretty old data, but the JVM has improved since; [url]http://keithlea.com/javabench/data[/url] The JVM can optimise on the fly, something you don't get with native binaries. So if an app starts doing the same thing repeatedly, the JVM can optimise that fairly well to speed up the calls. With natives you have to hope the compiler understands that code will be used a lot, and hope that it optimises it as much as possible. There's nothing wrong with Java other than the actual language itself being a bit verbose today. But it's not like it's hard to write a new JVM language. Why switch ecosystem entirely just because some nerds have a hate-hardon with no real basis?
[QUOTE=hexpunK;45228175]The JVM isn't the problem. Especially considering that Google wrote their own rather than using Sun/ Oracle or the OpenJRE. Java is pretty fucking fast today on desktops, this is pretty old data, but the JVM has improved since; [url]http://keithlea.com/javabench/data[/url] The JVM can optimise on the fly, something you don't get with native binaries. So if an app starts doing the same thing repeatedly, the JVM can optimise that fairly well to speed up the calls. With natives you have to hope the compiler understands that code will be used a lot, and hope that it optimises it as much as possible. There's nothing wrong with Java other than the actual language itself being a bit verbose today. But it's not like it's hard to write a new JVM language. Why switch ecosystem entirely just because some nerds have a hate-hardon with no real basis?[/QUOTE] The JVM is (slightly) annoying to some extent though, for example it still doesn't support generic types properly and inserts type-checking casts everywhere because the generic type arguments all become [I]Object[/I]. Not having custom value types and standardised operator overloading is another matter, though iirc they are finally fixing them. There are things wrong with the CLR too, for example how it doesn't support type constraints based on available members and therefore has languages like F# use tons of hacks and static inlining to get it to work, but overall there are less problems with the architecture than in the JVM I think. Cross-platform support is another issue, Java has been around longer and is easier to make a runtime for, so it even runs on things like SIM cards.
[QUOTE=Tamschi;45228675]The JVM is (slightly) annoying to some extent though, for example it still doesn't support generic types properly and inserts type-checking casts everywhere because the generic type arguments all become [I]Object[/I]. Not having custom value types and standardised operator overloading is another matter, though iirc they are finally fixing them. There are things wrong with the CLR too, for example how it doesn't support type constraints based on available members and therefore has languages like F# use tons of hacks and static inlining to get it to work, but overall there are less problems with the architecture than in the JVM I think. Cross-platform support is another issue, Java has been around longer and is easier to make a runtime for, so it even runs on things like SIM cards.[/QUOTE] Yeah, the way the JVM handles generic types is pretty weird. It's not the fastest when it comes to stuff like that, and it can be a nightmare for the programmer to deal with the ludicrous amounts of type checks and casts you may need in code. I guess this is one of the major flaws that even Google can't fix, not without going against the JVM spec and kinda ruining the point of Java. Just a personal peeve of mine now when I see people complaining about the speed or efficiency of the JVM, having done a fairly interesting project that taught me a fair bit about it, it's nowhere near as bad as people like to say it is. :v:
[QUOTE=hexpunK;45228891]Yeah, the way the JVM handles generic types is pretty weird. It's not the fastest when it comes to stuff like that, and it can be a nightmare for the programmer to deal with the ludicrous amounts of type checks and casts you may need in code. I guess this is one of the major flaws that even Google can't fix, not without going against the JVM spec and kinda ruining the point of Java. Just a personal peeve of mine now when I see people complaining about the speed or efficiency of the JVM, having done a fairly interesting project that taught me a fair bit about it, it's nowhere near as bad as people like to say it is. :v:[/QUOTE] A lot of people's exposure to Java has been because of Minecraft. And we all know that Minecraft isn't exactly resource efficient. I don't think people realize performance problems in Minecraft are because its coded horribly and not really much to do with Java itself. That's just something I've noticed.
[QUOTE=hexpunK;45228891]Yeah, the way the JVM handles generic types is pretty weird. It's not the fastest when it comes to stuff like that, and it can be a nightmare for the programmer to deal with the ludicrous amounts of type checks and casts you may need in code. I guess this is one of the major flaws that even Google can't fix, not without going against the JVM spec and kinda ruining the point of Java. Just a personal peeve of mine now when I see people complaining about the speed or efficiency of the JVM, having done a fairly interesting project that taught me a fair bit about it, it's nowhere near as bad as people like to say it is. :v:[/QUOTE] The JVM definitely isn't that bad, Java itself is just sort of a dull language to code in :v: .. not to mention the previously mentioned 'generics', yay type erasure and cast-athon Not to mention the verbosity of performing certain tasks in it, but thankfully theres plenty of other languages that compile to jvm bytecode as well!
[QUOTE=Demache;45229256]A lot of people's exposure to Java has been because of Minecraft. And we all know that Minecraft isn't exactly resource efficient. I don't think people realize performance problems in Minecraft are because its coded horribly and not really much to do with Java itself. That's just something I've noticed.[/QUOTE] It's a combination of both, really. It's far slower than it would have to be but there's only so much you can do about optimising a game that heavily reliant on voxel data with no structs and the inability to trade safety for speed. IIrc they said themselves that C++ would be a better fit for the game at some point, though for some reason they're currently rewriting the engine still in Java, if I'm not mistaken.
[QUOTE=chimitos;45225205]I can't wait for Samsung and LG to shit all over the new UI! [editline]26th June 2014[/editline] I'd rather the dev team work on bugs instead of rebuilding the entire rendering system in HTML5. If I want to play with it, I'll just download the example code. The AndroidDevelopers website has come a hilariously long way in the last few years.[/QUOTE] You're a bit deluded if you think they need to recreate their whole rendering system in HTML5 to recreate the feel, I wasn't asking for an interactive phone running in my browser, I was asking for exactly what Icemaz linked to :v: Just small functional examples, they need in no way be complete, just like the videos. wah, merge [editline]27th June 2014[/editline] [QUOTE=Tamschi;45229418]It's a combination of both, really. It's far slower than it would have to be but there's only so much you can do about optimising a game that heavily reliant on voxel data with no structs and the inability to trade safety for speed. IIrc they said themselves that C++ would be a better fit for the game at some point, though for some reason they're currently rewriting the engine still in Java, if I'm not mistaken.[/QUOTE] The biggest problem with Java is that they have no way of controlling how things are laid out in memory, there's no stack allocation at all and there's no way to tell the memory allocator in the JVM to do anythin specific at all, which is essential if don't want to continually trash your cache (and not to mention waste tons of memory). It's a thing with managed languages in general rather than just Java, as soon as you involve a garbage collector you lose fine grained control of memory allocation, not to mention the ability to write custom memory allocators like anyone doing a voxel based game in C++ would. Personally, I doubt they'll ever go for C++. The ecosystem around the current game(and it being based on java) is so large it wouldn't do them any good.
Java really isn't the most suited to game development, especially if the game has a lot of dynamic elements. But for desktop applications, web-server stuff, phone applications, it works fine. It's what it was built for after all, you notice cache misses and paging a lot less in these scenarios. It'd be interesting to see Minecraft move off of Java, but it does work fairly well in Java considering Notch isn't the greatest programmer and they're only just rewriting the engine after years of bollocks being added in half-arsedly, Though I do like the idea of the HTML driven user interface of Firefox OS. Javascript is total balls to me, but it's easy to learn and use, has tons of resources now, and HTML is so easy to work with that anybody should be able to make something in it. Hopefully the changes to the Android design language make UI stuff a bit easier, right now it can get a bit messy.
[QUOTE=Profanwolf;45229422]The biggest problem with Java is that they have no way of controlling how things are laid out in memory, there's no stack allocation at all and there's no way to tell the memory allocator in the JVM to do anythin specific at all, which is essential if don't want to continually trash your cache (and not to mention waste tons of memory). It's a thing with managed languages in general rather than just Java, as soon as you involve a garbage collector you lose fine grained control of memory allocation, not to mention the ability to write custom memory allocators like anyone doing a voxel based game in C++ would. Personally, I doubt they'll ever go for C++. The ecosystem around the current game(and it being based on java) is so large it wouldn't do them any good.[/QUOTE] It would be nice to get stack allocation in .NET at some point. ([URL="https://stackoverflow.com/questions/10800063/how-to-instance-a-c-sharp-class-in-unmanaged-memory-possible"]You can actually hack it in if you really want[/URL], but it's extremely nasty right now :v: ) You should probably just use structs in such a case, then you can safely pass references into methods like in C++. (I realise there are some use cases where that wouldn't work, but they should be relatively few and far between.) [editline]27th June 2014[/editline] [QUOTE=hexpunK;45229514][...] Though I do like the idea of the HTML driven user interface of Firefox OS. Javascript is total balls to me, but it's easy to learn and use, has tons of resources now, and HTML is so easy to work with that anybody should be able to make something in it. Hopefully the changes to the Android design language make UI stuff a bit easier, right now it can get a bit messy.[/QUOTE] I think the main issue I have with web UIs is that they rely heavily on images and usually don't obey the native OS style, which makes them 1.) an eyesore for desktop applications and 2.) terrible resource hogs. I'm sure you can make really nice, [U]native[/U], UIs using HTML and CSS as soon as you take (inline) JS out of the equation, since then you can compile things into a native GUI again that renders with full hardware acceleration, procedural elements and none of the browser bloat. The missing separation of code and data also leads to security issues fairly regularly, for example almost all recent instant messenger worms without user interaction exploited the fact that ICQ/Skype/whatever display messages inline with IE.
[QUOTE=mchapra;45227295]This is literally the second change they've had in their 6-ish year history of the OS.[/QUOTE] Android Eclair to Froyo had significant UI changes, as did Froyo to Gingerbread, Gingerbread to Ice Cream Sandwich and Jellybean to KitKat. If you think they've only done two changes including this one in the history of Android you're obviously very new to the Android world. Even just the changes in the stock launchers has a big impact on how the device looks. Apple has really done one major change to springboard, and Microsoft arguably did one with changing the WP8 launcher to support different tile sizes and wallpapers with WP7.8 / 8.
google aren't consistent in their design choices nor are they ever planning to effectively enforce design guidelines on developers to stop apps from scaling so badly and have them be more consistent across the board. they have design problems even though their head of design is a fucking genius [editline]27th June 2014[/editline] in comparison microsoft and apple nailed their design in terms of actually making them work. regardless of how nice i think L looks (i do think it is quite nice)
[QUOTE=Kaabii;45229610]Android Eclair to Froyo had significant UI changes, as did Froyo to Gingerbread, Gingerbread to Ice Cream Sandwich and Jellybean to KitKat. If you think they've only done two changes including this one in the history of Android you're obviously very new to the Android world. Even just the changes in the stock launchers has a big impact on how the device looks. Apple has really done one major change to springboard, and Microsoft arguably did one with changing the WP8 launcher to support different tile sizes and wallpapers with WP7.8 / 8.[/QUOTE] I felt that you could only count Holo and This current one in terms of a properly named and documented design language and guidelines to developing apps for the OS but It seems I was mistaken.
[QUOTE=Kaabii;45229610]Android Eclair to Froyo had significant UI changes, as did Froyo to Gingerbread, Gingerbread to Ice Cream Sandwich and Jellybean to KitKat. If you think they've only done two changes including this one in the history of Android you're obviously very new to the Android world. Even just the changes in the stock launchers has a big impact on how the device looks. Apple has really done one major change to springboard, and Microsoft arguably did one with changing the WP8 launcher to support different tile sizes and wallpapers with WP7.8 / 8.[/QUOTE] but as far as the actual UI elements though (not the launcher nitpicking) there was literally only one before this gingerbread>honeycomb/ics/kitkat ics/kitkat was an evolution of honeycomb the design specs didn't change once ICS appeared from honeycomb, and they didn't change in the pre honeycomb days this is the second design language since android 1.0
[QUOTE=LordCrypto;45229942]but as far as the actual UI elements though (not the launcher nitpicking) there was literally only one before this gingerbread>honeycomb/ics/kitkat ics/kitkat was an evolution of honeycomb the design specs didn't change once ICS appeared from honeycomb, and they didn't change in the pre honeycomb days this is the second design language since android 1.0[/QUOTE] As far as the "actual UI elements" they've still redesigned it multiple times. I never said anything about Google's design language changing. I said Google has done UI redesigns in almost every major version and that is demonstrably true based on their changes to the launcher, the status bar, the notification drawer, the overscroll glow, application designs, icon designs, color themes, etc. That is by any sensible standard, a redesign. Nobody would ever look at Android Honeycomb and say it is designed the same way Android KitKat is despite it being evolved from the same Holo design language. You cannot look at Froyo and Gingerbread and say the UI stayed the same when there are blatant differences in darkness, widget designs, colors, the status bar, overscroll effects, etc. The same is true for ICS/JB going to KitKat, and for a lot of the other version changes. No other company does this. Microsoft and Apple don't even remotely come close to approaching upon the constant UI changes that Google has made. Google is the only company that consistently gets UI design wrong and has to change it. To be fair, Matias Duarte probably had a lot of trouble trying to redo EVERYTHING and have it be unified, and Android L looks like what's going to stay around for a while, but the lifespan of Holo was laughable compared to Microsoft's "modern UI" or Apple's previous Aqua design.
Sorry, you need to Log In to post a reply to this thread.