Point was that "pulls in data much more slowly" is a lame excuse. Their app was coded like crap. Blaming the tech they chose instead of the developers was silly.
"'the benefits of cross-platform development weren't enough to outweigh the downsides of HTML5, which pulls in data much more slowly than native code,"
Pulls in data much more slowly?
Is he talking overhead of HTTP headers? Handshaking on websockets?
The worst part of the facebook app has been the fact that when you load it up it wipes out the screen of any data you had last time, then pulls in a full new set over a crappy mobile network connection which very often timed out. Had the app cached (HTML5 localStorage?) postings and displayed what you already had, while trying to get new ones, it would have been much more useful.
He can blame HTML5 all he wants, but poor design decisions could be made for any language and platform.
To be fair, SB1070 (the discriminatory law that made all the headlines) was authored by Russell Pearce that the citizens later impeached. He was thrown out of office by the people of his hometown.
He's trying to get elected again. If he makes it, feel free to trash Arizona.
I wouldn't expect a 35 dollar tablet to have the hardware to be my main tablet, but probably a bunch of cool things you could do with ten of them networked in a building and mounted on walls or something.
I'm not misinformed about this. The discussion didn't have anything to do with any sales chart. It was the game ranking on boardgamegeek.com which is based on how well liked a game is, not how well it is or was selling.
I know very well that the game was limited print run, I made sure to pick up a copy before it sold out.
abigsmurf is wrong about why it fell on the game rankings chart. The game was #7 three days ago which was already well after most places have sold out. Had it not been for the cease and desist, it would have remained highly ranked for quite some time.
It went from #7 to #170 in 3 days following the cease and desist. It had nothing to do with availability and everything to do with the reaction to Game Workshop's actions.
What do they plan to do to grant pixel-level access?
You can do this today with dojox.gfx and it's completely open source. You can use simple calls that are implemented differently on different browsers. On firefox and others your drawings are rendered in SVG, in IE its VML, on others its HTML5's Canvas. Canva's event model isn't as nicely integrated with the DOM as SVG and VML, but you can pretty much draw things cross platform.
Sure. "yum install wine" or "apt-get install wine" or "google's pointy and clicky installer to fetch wine"
Personally I hope they just pick rpm OR deb and the other distros just drop the unused one. Two package formats is a case where competition isn't helping linux.
From my 3 days experience with it, it looks exactly the same. The android plugin from the update site is 0.91. It may just be that 3.5 is backward compatible enough to run the same plugin.
Javascript libraries for things like browser abstraction and animations are really nice, but they're getting kinda of bulky. Content delivery networks like AOL and Google are hosting them for free, so it makes sense for websites to just include them and use the big guys' bandwith.
You can do cross site scripting right now using JSONP. Basically include a script with a callback function name and run an eval on the response. The object you really want as a response is placed in as the parameter to your callback. It's extremely useful when you are able to trust the other host.
However, if you don't trust the other host, you shouldn't be including their script in the first place. Because that script may contain something like a javascript function to send the cookies of the first domain to someone else.
It's pretty straightforward on how to secure the stuff, but we'd be a lot better of if browsers had a native evalJSON() function instead of just an eval(). That way we'd know we're just sending back objects instead of executing arbitrary code.
Re:Android just won't catch up with iPhone
on
Unlocking Android
·
· Score: 4, Insightful
It's Java + Eclipse, which is notoriously slow when compared to XCode and the iPhone Simulator
UI design is done in very verbose XML, as opposed to Apple's Interface Builder, which lets you easily drag things where you want them
The GUI is described in XML, but you don't have to use a text editor to build or edit it. There are in fact tools in Eclipse to drag and drop components into the GUI. Heck, there's even an applet I've seen that will do some point and clicky GUI creation and spit out XML.
Would you rather that there was only a closed source proprietary IDE that spit out binary data to build your GUI for Android?
Since Android is a platform and not tied to a single device, you have to design in "device independent pixels" which is much different than the iPhones set-in-stone 320x480 resolution
You say that like it's a bad thing. So if apple decided to put out an in-dash car PC using the iphone OS, you'd like the fact that the existing iphone apps look like shit in it? Or would you want the in-dash screen to run at an obscenely low resolution? How about programming GUIs in way that allows them to play nicely in multiple screen resolutions?
Core Animation... 'nuff said
No, not enough. Please elaborate on why that makes iphone such a great platform to develop on.
Re:Android just won't catch up with iPhone
on
Unlocking Android
·
· Score: 1
I'm actually running JF 1.5, rooting was easy:)
The browser pinch zoom is cool, but I'd really like it in the maps application.
Would be nice to see this stuff official though.
Re:Android just won't catch up with iPhone
on
Unlocking Android
·
· Score: 2, Interesting
I have a g1 and a ipod touch. The differences are really multi-touch and apple's stuff is more round and bubbly.
The online Android installation instructions are much more useful, because they also include the latest version of Eclipse, 3.4.
Actually 3.5 (Galileo) is out now. There aren't explicit instructions for it on developer.android.com, but it's still works the same way. Add the update site, and install the plugin.
Java isn't really open source, that's why it's a huge pain in the ass under Linux.
It's in the standard repos on most distros now. It's not any different than installing python or perl or any other language/platform.
Yes, Sun released a version of Java under the GPL. It's the "next" version of Java, Java 7 or 1.7 or whatever they're deciding to call it.
They released the 1.6 JVM and libraries that it was legally allowed to.
The current version of Java, the one that everyone uses, is most definitely not open source. It's free, sure, but it's licensed in such a way that Linux distributions can't package it. (Easily - some have worked around it, but the bottom line is that installing Java 6 on Linux involves an interactive process. It can't be automated.)
Everyone should be using 1.6 because 1.7 isn't released yet. 1.6 is GPL and open source. That "interactive" process was clicking on the EULA before it was open sourced. Not that big of a deal then, but it's not even an issue anymore.
The "open source" version of Java is missing large chunks of Java and is basically not at all ready.
Big chunks? The JVM and libs were almost complete. The small parts that couldn't be released were 3rd library implementations that Sun didn't have rights to release as GPL. The GNU Classpath project filled in the gaps almost from day.
So, Java isn't "really" open source. It's "going to be" at some point in the future - or at least it was. With Oracle in control, who knows.
It is open source. Really.
(Sure, Oracle can't un-open source what was released - but since that isn't enough for a full version of Java anyway, it's not like it really matters.)
No, it does matter. Billions of IT dollars are still being spent on projects using the java platform. I'm sure Oracle would have rather had Sun's implemenation all to themselves, but then they should have bought Sun a couple of years ago.
Slashdot Mirror
Point was that "pulls in data much more slowly" is a lame excuse. Their app was coded like crap. Blaming the tech they chose instead of the developers was silly.
"'the benefits of cross-platform development weren't enough to outweigh the downsides of HTML5, which pulls in data much more slowly than native code," Pulls in data much more slowly?
Is he talking overhead of HTTP headers? Handshaking on websockets?
The worst part of the facebook app has been the fact that when you load it up it wipes out the screen of any data you had last time, then pulls in a full new set over a crappy mobile network connection which very often timed out. Had the app cached (HTML5 localStorage?) postings and displayed what you already had, while trying to get new ones, it would have been much more useful.
He can blame HTML5 all he wants, but poor design decisions could be made for any language and platform.
To be fair, SB1070 (the discriminatory law that made all the headlines) was authored by Russell Pearce that the citizens later impeached. He was thrown out of office by the people of his hometown. He's trying to get elected again. If he makes it, feel free to trash Arizona.
The article mentions, box2d-js. The more current port is box2dweb: http://code.google.com/p/box2dweb/
I wouldn't expect a 35 dollar tablet to have the hardware to be my main tablet, but probably a bunch of cool things you could do with ten of them networked in a building and mounted on walls or something.
Love that music and loved 28 days later.
Would have been much more impressive to use something original or at least less well known.
I'm not misinformed about this. The discussion didn't have anything to do with any sales chart. It was the game ranking on boardgamegeek.com which is based on how well liked a game is, not how well it is or was selling.
I know very well that the game was limited print run, I made sure to pick up a copy before it sold out.
abigsmurf is wrong about why it fell on the game rankings chart. The game was #7 three days ago which was already well after most places have sold out. Had it not been for the cease and desist, it would have remained highly ranked for quite some time.
You're wrong.
It went from #7 to #170 in 3 days following the cease and desist. It had nothing to do with availability and everything to do with the reaction to Game Workshop's actions.
It started out as com.sun.java.swing.*
It was changed to javax.swing.* when it was released. "x" is more extension than experimental.
Is that a fact?
When you say J2ee do you mean strict Sun implementation?
I find that eclipse webtools with the spring IDE plugin does a good job for developing server-side java.
Or the Linux version.
It was ported to Linux 2 years ago(right after the windows release) but it was never released.
Asus tried it already and it failed.
Failed?
They sold a shitload of them.
It's had an x86 build target on scratchbox since at least 2006, maybe even day one.
You can do this today with dojox.gfx and it's completely open source. You can use simple calls that are implemented differently on different browsers. On firefox and others your drawings are rendered in SVG, in IE its VML, on others its HTML5's Canvas.
Canva's event model isn't as nicely integrated with the DOM as SVG and VML, but you can pretty much draw things cross platform.
Pure javascript, no plugins required.
Sure. "yum install wine" or "apt-get install wine" or "google's pointy and clicky installer to fetch wine"
Personally I hope they just pick rpm OR deb and the other distros just drop the unused one. Two package formats is a case where competition isn't helping linux.
From my 3 days experience with it, it looks exactly the same. The android plugin from the update site is 0.91. It may just be that 3.5 is backward compatible enough to run the same plugin.
Javascript libraries for things like browser abstraction and animations are really nice, but they're getting kinda of bulky.
Content delivery networks like AOL and Google are hosting them for free, so it makes sense for websites to just include them and use the big guys' bandwith.
You can do cross site scripting right now using JSONP. Basically include a script with a callback function name and run an eval on the response. The object you really want as a response is placed in as the parameter to your callback.
It's extremely useful when you are able to trust the other host.
However, if you don't trust the other host, you shouldn't be including their script in the first place. Because that script may contain something like a javascript function to send the cookies of the first domain to someone else.
It's pretty straightforward on how to secure the stuff, but we'd be a lot better of if browsers had a native evalJSON() function instead of just an eval(). That way we'd know we're just sending back objects instead of executing arbitrary code.
Eclipse isn't required for development, though it is extremely useful. And you don't like Java, there's a Native SDK now: http://developer.android.com/sdk/ndk/1.5_r1/index.html
The GUI is described in XML, but you don't have to use a text editor to build or edit it. There are in fact tools in Eclipse to drag and drop components into the GUI. Heck, there's even an applet I've seen that will do some point and clicky GUI creation and spit out XML.
Would you rather that there was only a closed source proprietary IDE that spit out binary data to build your GUI for Android?
You say that like it's a bad thing. So if apple decided to put out an in-dash car PC using the iphone OS, you'd like the fact that the existing iphone apps look like shit in it? Or would you want the in-dash screen to run at an obscenely low resolution?
How about programming GUIs in way that allows them to play nicely in multiple screen resolutions?
No, not enough. Please elaborate on why that makes iphone such a great platform to develop on.
I'm actually running JF 1.5, rooting was easy :)
The browser pinch zoom is cool, but I'd really like it in the maps application.
Would be nice to see this stuff official though.
I have a g1 and a ipod touch. The differences are really multi-touch and apple's stuff is more round and bubbly.
Estanislao was trolling.
The online Android installation instructions are much more useful, because they also include the latest version of Eclipse, 3.4.
Actually 3.5 (Galileo) is out now. There aren't explicit instructions for it on developer.android.com, but it's still works the same way. Add the update site, and install the plugin.
dojo.gfx does this as well.
IMHO the watershed moment in Java was 1.5, courtesy of generics which made the collections at least somewhat usable without constant swearing.
Was casting that big of a deal?
The newer syntactical sugar is nice, but the lack of it was never a showstopper.
Wrong. Wrong on every point.
Java isn't really open source, that's why it's a huge pain in the ass under Linux.
It's in the standard repos on most distros now. It's not any different than installing python or perl or any other language/platform.
Yes, Sun released a version of Java under the GPL. It's the "next" version of Java, Java 7 or 1.7 or whatever they're deciding to call it.
They released the 1.6 JVM and libraries that it was legally allowed to.
The current version of Java, the one that everyone uses, is most definitely not open source. It's free, sure, but it's licensed in such a way that Linux distributions can't package it. (Easily - some have worked around it, but the bottom line is that installing Java 6 on Linux involves an interactive process. It can't be automated.)
Everyone should be using 1.6 because 1.7 isn't released yet. 1.6 is GPL and open source.
That "interactive" process was clicking on the EULA before it was open sourced. Not that big of a deal then, but it's not even an issue anymore.
The "open source" version of Java is missing large chunks of Java and is basically not at all ready.
Big chunks? The JVM and libs were almost complete. The small parts that couldn't be released were 3rd library implementations that Sun didn't have rights to release as GPL. The GNU Classpath project filled in the gaps almost from day.
So, Java isn't "really" open source. It's "going to be" at some point in the future - or at least it was. With Oracle in control, who knows.
It is open source. Really.
(Sure, Oracle can't un-open source what was released - but since that isn't enough for a full version of Java anyway, it's not like it really matters.)
No, it does matter. Billions of IT dollars are still being spent on projects using the java platform.
I'm sure Oracle would have rather had Sun's implemenation all to themselves, but then they should have bought Sun a couple of years ago.