Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:Safari was late in implementing some web APIs (Score 1) 311 311

App API support is totally different than in-browser support.

As a web developer, it's very difficult to determine which specific hardware my page is being rendered on. And the abstraction of the web implies that I *should not* be targeting specific hardware.

Hence OS level. Of course I shouldn't be targeting specific OS either, but that's a different story.

Comment Re:That's because... (Score 1) 311 311

Surely their native APIs are not so limited that they make you embed a whole browser in your application just to be able to do something.

Starting a sentence with "surely" to indicate disbelief is asking for confirmation of the statement contained therein.


But I wasn't the one playing grammar nazi with where question marks were being placed.

The API does provide a web view and I don't think there is really anything you can do in web app that you can't do in a native app. In fact for a long time it was the other way around, WebGL 3D graphics have only recently become available in Safari.

The HTML view originally did not allow any remote content loading. This is one of the limitations PhoneGap was originally created for. The "UIWebView" added later essentially embeds a Safari page in your app and prevents a very tidy container to limit how the contents can affect the container app.

Comment Re:Safari was late in implementing some web APIs (Score 1) 311 311

Firefox already does this with its WebGL driver blacklist. It does not support WebGL on pre-OpenGL 2.0 GPUs, such as the integrated GMA 3100 in the Atom N450 processor in my laptop.

Only because Firefox cannot control the hardware and the software layers. What's the point in saying your software supports feature X if all the hardware it runs on can't support X? Apple controls both sides within their products so they can choose what "support" means. They chose to make iOS8 the point where hardware-accelerated 3D was supported inside the browser because that's the release where all their supported hardware could handle the feature and do so without performance degradation.

Again, as a developer or product manager, "works in iOS8" is a lot easier to worry about than "works in iOS8, but only on iPhone 4s and later (not iPhone 4), iPad 3 and later (but not the first iPad mini) and only on the last version of the iPod Touch". Limits on hardware fragmentation is considered one of the benefits of iOS and OSX development.

Comment Re:Enterprise (Score 1) 311 311

Standards - They've supported tons of standards, and all their enterprise/business support tool chains are built up from *NIX libraries. Yes, they layer their own customizations on top (just like everyone else) and yes, these often change between releases without warning (but that's the point about secretive roadmaps).

It's pretty hard to claim that Safari always sucked. Webkit was a fork of KHTML and from day one it was better than any KHTML browser (Konquerer was horrendous!). By limiting the browser to just the standards they quickly got other browser makers to improve their standards support (hey, there's "standards" again!). The only "enterprise-friendly" browser has always been IE, and that's only if you define "enterprise" as "dependent on IE-specific behaviors".

Of all of these, secretive product roadmaps is the only one really at fault for lack of enterprise adoption. Speaking of enterprise adoption, which enterprise companies don't support iOS devices in this day and age?

Comment Re:That's because... (Score 1) 311 311

With the question mark it is an implied continuation of the previous question.

"You realize ... there are a lot of limitations in the iOS APIs because they'd prefer you do certain things in browsers where it can follow standards instead of being some developer's hack-up of poor security or poor performance?"

Speaking of which, Mr. Grammar Nazi, you forgot your own question mark:

Surely their native APIs are not so limited that they make you embed a whole browser in your application just to be able to do something.

For an example, try loading a publicly hosted URL directly in an HTML view with an app. Oh right, it used to be blocked because its a huge security risk on the level of stupidity that PDF is known for, and it directly duplicates what the browser should be doing. Instead you can use platform APIs to request content for your your view, or use the platform-provided wrapper to display remote content safely - which by necessity require you to build in a more responsible and secure way.

Comment Re:Safari was late in implementing some web APIs (Score 2) 311 311

For instance, please explain why it took until iOS 6 for HTML/JS apps to access the user's photo and video libraries through an controls

Because exposing a user's files to any in-page behavior is a security risk and needs to be handled in clean managed ways with limited APIs? The hooks they established to do this went far beyond just browsers and also affect how content is provided to apps and 3rd party API calls.

and until iOS 8 for HTML/JS apps to put the most basic 3D view on screen (WebGL).

Because 3D in browser has gone through a lot of iterations over the years? Read up on VRML for example. WebGL is a relatively recent fad extended from OpenGL and so relies on device drivers for hardware acceleration. Rather than have pages that would perform poorly or be inconsistently incompatible, Apple didn't guarantee provide the feature until OS-supported devices could support it. It's bad enough to run into situations where "it works on latest release, but not previous ones". Imagine how bad it would be if "it works on the latest release, but only on these specific models". That's a non-starter when it comes to the world of HTML/JS/CSS development.

Comment Re:That's because... (Score 1) 311 311

LOL - you realize the the original iPhone allowed *only* HTML/JS apps? And there are a lot of limitations in the iOS APIs because they'd prefer you do certain things in browsers where it can follow standards instead of being some developer's hack-up of poor security or poor performance?

Comment Re:Define controversy... (Score 2) 126 126


If you're browser-side JS developer (as opposed to something server-side like Node.JS) and you haven't worked with JQuery, then you're not really a browser-side JS developer. It's just far too widely used to pretend that it doesn't or shouldn't exist. And most of the consistency across other frameworks (like using the $ shortcut or css selectors to target elements in the DOM) comes from the popularity of JQuery to begin with.

Comment Re:I remember seeing a carpool club in the 90's... (Score 1) 333 333

You answered your own question:

The latter of these two was not actually permitted to be demanded by the driver, but it was still a general practice among club members

If you volunteer to give your carpool driver $10 to help with gas - it's fine.

If your driver asks for $10 to cover gas - it runs afoul of the livery laws. It's hard to enforce, but that's generally how the law is written (at least in the US).

Comment Re:Arrest (Score 1) 333 333

Cabs predate the automobile by a long shot.

Even cities with incredibly good public transportation options still have cabs because there is a natural market for being able to travel *directly* from point A to point B in a more expedient manner than public transportation could ever provide.

Comment Re:Infinity (Score 1) 1067 1067

This is a little like saying it would be handy if the compiler knew what you meant when you wrote code that attemtped to do soemthing for which there is no specifically well defined answer.

If the compiler or language has a consistent, documented behavior for the scenario, then by definition there is a specifically well-defined answer.

For certain knowledge domains and programming patterns, this would not be a hurdle but a benefit. Languages are full of these behavioral "flavors".

Comment Re:Infinity (Score 1) 1067 1067

According to another poster elsewhere, some processors do exactly what the OP requested, and that it's doable today in machine code. Other posters have mentioned that using unsigned or floating point integer types allow this behavior in various languages.

There's no reason why it couldn't be supported by a language, and it's absolutely not impossible.

Everyone's argument about it being impossible comes from expressing things in languages where it's explicitly "undefined" or NaN, or otherwise illegal in that language. If it's a standard and predictable behavioral rule of a language, then it's definitely usable in that language.

Weak types in PHP or JS are very analogous. Sure, lots of people make mistakes with them (and there's other faults that encourage those mistakes), and most problems stem from inconsistencies in the language APIs when converting types, but if you understand how types work in those two languages you can write surprisingly complex behaviors using very simple and concise expressions. Simplicity and terseness is very important in a scripted language.

Comment Re:Infinity (Score 1) 1067 1067

What's good for a particular algorithm buried in the code base is not necessarily good for user input which may be used a hundred other ways.

0 could be a perfectly valid user input or calculated result of multiple user inputs that could cause the algorithm to choke.

Prefixing every math operation you put in your code base with a check for 0 if the input values are unknown can be tedious, especially in obtuse languages/platforms that don't support good modularity - hence the OPs question about a globally consistent behavior.

Economists state their GNP growth projections to the nearest tenth of a percentage point to prove they have a sense of humor. -- Edgar R. Fiedler