Awesome, works really nicely on my Nexus 4. I'll definitely be using it from now on. The comment view looks a lot like my 'Reddit Now' app so that's probably why I like it so much! The transition between comments and the article is a nice touch too. 5* from me.
I disagree. The thought of maintaining an app with a large code base written in JavaScript doesn't seem like a "step forward" to me. I'd much rather stick with my Android apps object oriented code base and associated tools.
I've been rewriting my latest released Android game in Html5 and Coffeescript for PhoneGap, which lets me deploy on iOS and Android, plus Blackberry and other platforms, but I'm focusing on iOS and Android for now. I'm doing that because I need to make an iOS version, and would rather spend my dev time adding more features or developing more products rather than redeveloping the same product on multiple platforms. This approach also opens me up to the possibility of having a web version, perhaps a Facebook and/or Google+ module. I'm astounded on how much smaller my code is in Coffeescript than Java. It's about 1/2 the size of its Java counterpart.
Many people will of course not move on to HTML5 app development. Every time technology changes, lots of people don't migrate. But it really is an amazing way to go. Coffeescript solves a lot of problems and makes the code very small. Jasmine unit testing helps with the scary feeling of not having type safety. PhoneGap lets you deploy it as a native app. Chrome has a surprisingly awesome stepping debugger built right in. Vim + the cofeescript plugin automatically compile the Coffeescript every time you save. The difficulties of debugging in Coffeescript are mostly overstated in my experience, and countered by the feeling that I'm developing code faster than I ever have before in any other language.
It's not all cake and ponies, and I've had to figure out a number of things. But it's a really fantastic way to develop apps. Try it.
OpenGL is a C api, so it's very natural to write introductory material for GL in C. Anyone is serious about wanting to use OpenGL should know enough C to read it and translate to whatever language you want. You also don't need to worry that much about language bindings or windowing system wrappers in the example apps. Example apps will also be more portable when written in C.
If this were written in Java, where there are no raw pointers or pointer arithmetic, etc, you'd have to use something like Java NIO Buffers or other abominations like that. You have to use raw pointers with OpenGL, since you do DMA transfers to upload and download geometry and texture data to and from the GPU. This is done with explicit transfer calls (with a pointer to the data) or with memory maps (where you get a pointer to a page aligned buffer that's ready for DMA transfer).
This is just another example on how every language that doesn't allow you to use pointers (for "security" reasons) will have something more complicated to replace them.
NOTE: if you really want Java versions, you can go ahead and write them. 10 years ago many people used the NeHe tutorials to learn OpenGL (don't touch them in 2011) and they were ported to pretty much any language and windowing framework out there. But they were ported bu individuals in the community, not by the original author.
Just because it's a C API doesn't mean it isn't used in other languages or has to be used in C. C can be unforgiving on the novice, so battling C while trying to learn OpenGL concepts can quickly become a losing battle. Portability is at the cost of complexity, setting up a C/C++ OpenGL cross platform build environment is not a piece of cake, especially on Windows.
C does allow low level access to memory, while this is powerful it also adds complexity. Things like loading a text file or image file aren't straightforward. Many libraries are in various states of disrepair. Getting a crash course in static vs dynamic libraries, linker settings, dependency/DLL hell detracts greatly from the learning experience.
Suggesting that allowing the programmer to use a buffer object or array in a call to GLBufferData would be somehow more complicated than wrangling with pointers & memory allocation is something I'll have to firmly disagree on.
I'd honestly suggest someone starting out with OpenGL to try out WebGL. Loading shaders & textures is a snap(comparatively) & your build environment is your web browser & with that you get instant feedback. Javascript debuggers have also come a long way. Then later you can transfer your knowledge to other more performance oriented languages, if you need that.
Even if a novice reader is not familiar with C at a very deep level, it's not that different from other programming languages. You should be able to read C and grasp the basic concepts of storing objects in memory, because a lot of OpenGL is about storing stuff in memory and you have to think about pointer alignments and stuff like that.
And besides, if you're writing example applications for a book or a tutorial, you should probably stick to very simple C code anyways. The kind that anyone can read to some degree.
Please note that I did not advocate that the reader must write their own projects using C, even if the book examples are in C. They can pick any other language they feel comfortable in. Just be prepared to deal with binding libraries and windowing toolkits and all the little things that you need.
Programming the GPU is one of the most hostile programming environments out there. You might not have a debugger available and you can't even debug with prints, you have to deal with memory explictly, drivers are buggy and a small mistake in your program might crash your computer partially or fully or cause very unintended consequences. I would not recommend for a novice who can't deal with C code to go there. This is true whether you use C or not. Even with WebGL.
Most of the people who want to learn OpenGL, actually want to learn 3d graphics programming. Then it's actually better to take a 3d engine that deals with 3d models, lights and cameras and stay away from OpenGL, which is basically a very complicated way of drawing triangles very fast.
A lot of stuff you said about C being difficult in practice, libs that are broken, difficulty on setting up on Windows, etc are true. However, they don't really apply to using it as a language in programming examples in a book or a tutorial.
> Most of the people who want to learn OpenGL, actually want to learn 3d graphics programming.
What 3D engines would you recommend? I've looked at OpenInventor and Coin3d briefly but I'm interested in solid modelling as well, rather than 'just' visualisation. I'm guessing there's no such thing as an well documented and easy to use open source equivalent of the Parasolid or ACIS kernels? :-)
Maybe I should have said "C novice". There are many savvy programmers who have only glanced at C/C++ code or have never touched the thing. C can be a bit of a culture shock when coming from a dynamic or managed language.
>>C does allow low level access to memory, while this is powerful it also adds complexity.
This low-level interaction with memory is pervasive in OpenGL's design. These features are so intrinsic to how OpenGL works that no wrapper can completely abstract them away.
I concur. While in most cases, some knowledge of Java or C will let you squint and read the other, when learning openGL for the first time, translating from another language makes it a lot harder.
I recently tried to learn it for Android games (so Java) working from a C++ book, and I eventually gave up. If I see a C-style array, what am I supposed to have there? A straight array? An Array? A buffer? Do we all mean the same thing by a float? My library looks a bit different -- I've got a similar function with a different prefix or suffix -- is it the one you're talking about? Even the same function expecting a different number of arguments is somewhat crippling when you don't know what they do, and don't have the vocabulary to understand what the documentation means.
OGL isn't easy to learn, and I don't think you can do the language translation easily until you've already learned it.
I think the title is misleading. If I'm not mistaken it's not actual infinite scrolling, the only change is the search bar and search tools remain in a fixed position. It's a nice change.
>The new interface seems to set the stage for a fluid design that removes pagination and replaces it with infinite scrolling.
The key phrase in the article is "setting the stage". Google hasn't switched to infinite scroll yet, but with a fixed header it seems most likely for them to do so soon.
I haven't seen it in action, but from what I saw in the video, it was actual infinite scrolling - the pagination controls got replaced with 'second page' content after scrolling down.
My guess is that the pagination controls are there to accomodate people with JavaScript disabled.
Yes, datastore backup and restore using bulkloader is not comfortable. For getting backup in local machine i am using bulkloader. However, i am doing online backup using backup(dummy) appengine project. I am coping data back and forth between production and backup projects for backup and restore purpose. Its comparatively easier.
One area where there is an obvious hole in the market imho would be catering for the disabled traveller. If she could provide a service whereby she could organise disabled friendly flights, assistance to and from the airport, guarantee accommodation would meet your requirements etc it would be a great load off the mind of those who fear travelling due to their disabilities. A "disabled holiday planner" effectively.
