And if I could actually try Grouper, I would. But given I signed up over 4 months ago and haven't heard a peep (though the site still insists "YOUR APPLICATION IS ON ITS WAY. WE'LL BE IN TOUCH."), I'm currently labeling anything and everything Grouper as vapor.
I also consider the Facebook requirement obnoxious - up until I decided to give Grouper a spin, my Facebook profile was minimal, not even a profile picture. But I was curious enough that I bit the bullet and gave Facebook way, way more information about myself than I'd normally be willing.
Which, of course, makes the vapor nature of the service that much more upsetting.
My experience could very well be an aberration - that said, I figure I'd throw out a warning to others interested in trying to service but are hesitant to give Facebook more personal information.
"I hope Google does just that. It takes a nontrivial amount of stupidity to think that Apple does not know shortcomings of its maps application and are working on fixing that."
I'm... not sure how to parse that sentence. I guess it's implying I have a non-trivial amount of stupidity, which probably explains my parsing problem.
Transit routing is a hard problem to scale - Apple has taken a shortcut and pushed it off to 3rd party developers, who can tackle the much more approachable problem of solving it on a city-by-city basis. Which make sense... but this is still a large regression as far as users are concerned. And doesn't help folks that live in smaller cities.
Yes, Apple is probably working on this. But now we come to an odd signalling issue - Apple has basically told 3rd parties that it is worth their time investing in this area. If-and-when Apple opts to plug this functionality hole, they've pulling the rug out from under these developers. And any app developer worth his salt has to be factoring that.
And I'd be really surprised if Apple steps in any sooner than the next iOS refresh - fixing transit seems like a wonderful bullet point for iOS7.
"Loosing iOS users for some barely noticeable amount of switchers is hardly a good business for Google [...]"
Err... what are they losing, exactly? Users aren't inherently valuable. If there's value these iOS users add to Google, I'd love to hear it.
Google is already generating local search and behavioral data via their large Android install base. Beyond brand visibility (which is going to be reduced, thanks to Apple's own offering), what does releasing their own native app get them? A native version that, again I want to emphasis, Apple is actively competing against their own product. Whatever Google releases, it is now going to be a 2nd class citizen, without the OS-level hooks Apple's own solution gets. And this assumes that Apple even lets them release an app. This wouldn't be the first time Apple has blocked Google from releasing an application on iOS because it duplicates existing 1st party functionality.
Basically - why should Google release their own app?
"—do they even make money from Android phones someone sells? I heard Microsoft makes more money than Google does."
I don't think I can adaquately address this in a response to a comment. Google is not a charity, and Android does add to Google's bottom-line.
In closing - I'd fucking love it if Google released a native Maps app. I'm an iPhone user that's gotten bit by this, and am sticking with iOS5 for now. But I'm not going to hold my breathe waiting. Particularly when I don't see a compelling reason for Google to save me.
"If I were Google, I wouldn’t launch a native Maps app for iOS 6 for at least six months, [...]"
If I were in Google's shoes, I wouldn't be launching a native Maps app. Period.
It's not like Maps is driving vast amounts of search revenue for Google. And with the degraded functionality of Apple's own Maps app, Google's Map app has become a reason for a buyer to consider switching to a Google-blessed Android phone.
And I say this as a long-time iPhone user - Maps was an important application for me. Now that it's become less functional, I'm going to actively look at Android and WP.
I have no idea what Telrik is like. But I do know Eric - he's incredibly committed. Fiddler was a side project for him, written during his meager free-time when not working his full-time gig as a PM at Microsoft. The fact that it's made it this far is a testament to him and his commitment to making the web a better place.
So - I have a hard time believing he's going to let Fiddler fall apart. If anything, he's finally getting an opportunity to make it his priority, and with an actual development team backing him, I'm actually excited to see how far he can push Fiddler.
tl;dr - I don't have faith in Telrik. I do, however, have faith in Eric.
If PayPal is so very terrible (and I believe it), Is there a reason Amazon Payments or Google Wallet haven't overtaken PayPal in this market?
If neither Amazon nor Google's brand recognition hasn't convinced folks (buyers or sellers) to start pushing it instead of PayPal for Internet purchases, I can only hope it's because their solutions are equally terrible - otherwise, I have a hard time seeing how a new player will make headway in this space. And I'd really like a new player. :/
Anyone have any guess why Amazon pulled the plug? There must be a reason beyond "Amazon has decided against “boarding fresh crowdfunding accounts at this time”" - just pulling the plug on an entire category of products willy-nilly is a terrible image for a cloud service provider to project.
I'm confused - the author assumes an android powered camera should have the same usage expectations as a tablet or phone...
And that's a terrible mistake. I don't care how capable my Angry Birds experience is on my camera. I care about applications written to enhance the photo-and-videographic functionality of my camera.
I'm fine with Nikon throwing on a custom launcher, if that's what they need to do to work around Android's touch-focus. I'm fine (and in fact, prefer) folks authoring applications specifically to the Nikon camera's interface.
And there's so much opportunity to extend a camera's capabilities, once it can run 3rd party applications. Auto stitching panoramas. Unwrapping spherical maps. Chromakeying. Instagram-esque filters. Subject tracking. Realtime preview and control over wifi and bluetooth via companion devices. Panning motor control. Multiple camera's automagically synchronizing. Etc etc.
The author uses Parrot's Asteroid car stereo system as an example for how a non-standard usage and non-standard UI are bound to fail. But that's a really weak comparison. Who do you think is more likely to grow a robust 3rd party ecosystem - a one-off experiment in a crowded, cost-sensitive market (a $350 device for bleeding edge enthusiasts), or an oft-upgraded stable of professionals who are already spending multiple thousands on equipment to be more productive?
The alternative is Nikon creates their own OS and development environment. But why compete with a flourishing platform, when you can just simply use it?
Some of it might have to do with the server platform - a lot of us really like the flexibility of using Linux on the server, but when we think C# we think IIS + Windows.
Is the server-side ecosystem for Linux-hosted C# production worthy? And if so, does it compare well to the solutions getting recommended in this thread?
I only skimmed the article, but that strikes me as a "mistranslation".
Adobe is emphasizing that they have to do more compositing logic, so they they need an RGB version of the video frame on the CPU side.
If they did the colorspace conversation on the GPU, they'd have to pull the converted image back and incur the latency hit. Apparently, they see less latency in doing the conversation on the CPU, and have made the call to trade processor efficiency for latency.
To be clear: YUV colorspace conversion on a GPU is really damn simple. I have a ~30 line shader that does it from my video processing codebase. But I can take the hit - I do a substantial amount of image manipulation using shaders on the GPU, and mask the read latency with heavy multi-threading. A Flash application doesn't have this luxury.
But this discussion is largely academic - if you're writing a Flash based video player that doesn't need the flexibility of Flash's full compliment of image manipulation and composting functionality, you'd be using their StageVideo API - an API that does do all the video work on the GPU. This API was introduced in Flash 10.2, which came out after this article from 2010.
Does this mean there's a business opportunity here, than? A 3rd party, escrow-esque middleman who holds the domain so that neither party breaks the agreement?
I find the idea intriguing. Is there a market for crowd-funding scholarships - rather than let committees decide who to give a scholarship to, leave it to the people? Maybe even spin it as an investment in their career, with some sort of return or payback to the original investors?
This reply hit so very many of my buttons - it's either a brilliant trolling, or incredibly unfortunate. But either way, my (entirely too detailed) response:
> why is that comment either a) at all credible
First off - rather than address the content of the original commenter I quoted, the first thing you do is go after his credibility. An ad hominem attack, right off the bat?
I don't know the poster. I don't know you either - initially, you're both equally credible to him. But he at least talked the talk - all the things he said made complete sense in the context of someone working cross-device with GL. They dove-tail in a technical manner with the more abstract high-level picture being painted.
Could he be bullshitting? Of course. But the only folks who benefit from pseudo-anonymously posting bullshit are griefers and fanboys. And since the level of technical discussion exceeds what most griefers and fanboys are capable of, I'm giving him the benefit of the doubt.
Do I want to believe him? Hell no. But do I believe him? Yes.
> or b) informative
What? He EXPLICITLY STATES some of the very specific technical problems he's encountered. Problems that a 3rd party can verify for themselves to trivially determine the veracity of his statements. The issues he mentions, assuming they're real, are major technical hurdles for multi-device development. And now I know to look for them if-and-when I start hitting issues. Drivers and APIs lying are a huge deal. And, unfortunately, entirely too common when doing graphics work.
So I have to ask - what, exactly, is the criteria you're using to judge "informative"?
> The problem with this discussion -- it is ostensibly an iOS versus Android discussion
Like fuck it is. I generally try to keep a civil tongue, but that sort of platform apologism is an insult to every Android developer. Framing it as iOS vs Android debate? iOS is a red-herring. IF iOS DIDN'T EXIST, THIS PROBLEM DOESN'T GO AWAY - developers would still be hitting these pain points.
It looks like Android has a problem, and acknowledging it is the first step in correcting it. Pissy GL drivers exist - as anyone who touched a linux box in the Bad Old Days is probably entirely too aware.
> as if developers have the luxury of just developing for iOS and the market will follow (hint: ha! Android made most of its gains when there little to no apps for it. Apps like Netflix and others followed but didn't lead. Now you could fill your day trying out new games and apps)
WTH? How is this even related to the comment I quoted? But I'll bite - Battleheart's developer confirms that they has the luxury of just developing for iOS. And by making this cut, they're signalling they no longer care if the Android market follows him. Just like anyone can author a game in DirectX that just targets Windows can comfortably ignore OS X and still be profitable. It's sad, but a developer has to be pragmatic if they want the to survive long enough to release the next product.
And if you really want to be pedantic - the iPhone made all it's initial gain when there were no apps for it. Remember, on release the iPhone did not have a native market. Developers and users had to cajole Apple into it. But hey, now iPhone users can "fill [their] day trying out new games and apps". I'm not sure what the hell this has to do with anything, though.
> there are a lot of very, very strongly biased individuals and parties, and the discussion gets completely crowded out by what often ends up being bullshit (though it takes a lot of legwork and endless excluding to actually discern that). What I like to see are specifics, but they are shockingly hard to come by.
HOLY FUCK. This quote calls out BROKEN APIS YOU CAN EXPERIMENT WITH RIGHT NOW. The base discussion itself flows out of a developer expressing why he's leaving the platform, with specific reasons stated. There is NOTHING here that can't be verified. And I don't know where the fuck you get off characterizing a studio that's spending time and money desperately trying to support a platform to share their work with as many people as they can (which is why most indie game devs I know do this) as "strongly biased individuals and parties" against Android.
> In this case of the linked story the vendors used Unity 3D -- why they were even writing specific shaders (double shocking given that their top-down sprite graphics, if I am understanding their apps right, are the most bog standard shaders going) is a mystery.
And now you're attacking the developer's competence. :/ Let me twist your statement around - only an incompetent developer wouldn't use fragment shaders. They're a great way of providing compelling visual effects without incurring a substantial performance hit. By using more than just "bog standard shaders", the creators of Battleheart are demonstrating they're trying incredibly hard to create a satisfying experience for their end user - a step up from your cookie-cutter game developers.
Now, getting back to the actual topic - what are some short-term solutions to this problem? The only thing I can think of is a bunch of developers banding together and creating a "reference application" that thoroughly exercises the API on a device (sort of an android-esque Futuremark). And if a device fails to pass "certification", developers right-off supporting that hardware. It'd be great if a company with clout like Rovio pushed this, for example.
A longer term fix would be if Android started incorporating something akin to the Windows Experience Index. As the platform grows, I fully suspect Android will have to include something like this to help developers sanely handle the growing performance gap between devices.
Does anyone know if Google does any driver certification?
And a completely unrelated question - huggyface, may I ask who you are? You've got a karma that doesn't match your listed contributions (A 60-day-old account with 12 comments, no submissions, and over 420 karma), which has me terribly curious.
I completely support your decision to drop Android like a hot potato.
In the two weeks since starting as a senior graphics engineer at a middleware company who shall remain nameless, I have learned from coworkers about, or personally experienced:
- Drivers that crash if you try to actually use all of the texture formats they claim to support
- Drivers that crash if you try to actually use certain ARBs that they report as supported
- Drivers that report supporting 128 shader uniforms but crash if you try to access anything past the first 64
- Drivers that report supporting various OpenGL ARBs but actually have a software path
in fact, I don't believe there has been a single Android device that has come out so far that is actually point-for-point compliant with the requirements for OpenGL ES 2.0, yet they have no problems claiming to support it nowadays.
GPU support on Android is utterly atrocious, and I've managed to learn this in all of two weeks at my new job.
As someone that's on the verge of porting some 3D code to OpenGL ES 2.0, this is awfully depressing. :(
I find it interesting that the poster mentioned the growth of C# (going from 4th to the 3rd), but didn't mention Objective-C's much larger growth spike (from 8th to 5th place).
To me, that's the bigger story - I imagine all that Objective-C growth is getting targeted squarely at the mobile platforms. That's a lot of dev interest.
I also consider the Facebook requirement obnoxious - up until I decided to give Grouper a spin, my Facebook profile was minimal, not even a profile picture. But I was curious enough that I bit the bullet and gave Facebook way, way more information about myself than I'd normally be willing.
Which, of course, makes the vapor nature of the service that much more upsetting.
My experience could very well be an aberration - that said, I figure I'd throw out a warning to others interested in trying to service but are hesitant to give Facebook more personal information.