• (nodebb)

    What if it's not mobile, but is android and iPhone at the same time?

  • (nodebb)

    That's absolutely the wrong way to do that, and I hate it, but there's just so many times you can say, "send server-side values to the client as an object, not inline".

    Or just plain don't send the whole if() branch of the JS (or send the if() branch without the if(){} around it in the opposite case). Sheesh.

  • (nodebb) in reply to Mr. TA

    Or, worse, what if it's mobile, android, iPhone and iPad all at once (where "mobile" means "Windows Mobile", of course...).

  • (nodebb)

    we've got some lovely order-of-operations abuse

    How do you justify calling it "abuse"? I do that frequently. It is correctly using the order . . . what's wrong with that?

  • (nodebb)

    I'm not a JavaScript expert, but can it be that "true" === "true" evaluates to false because these two strings are equal but not identical?

  • (nodebb) in reply to Melissa U

    That would be a pretty severe violation of POLA if "true" == "true" and "true" === "true" weren't both true.

    (For the folks who don't know about POLA: "Principle of Least Astonishment".)

  • David-T (unregistered) in reply to Steve_The_Cynic

    JavaScript has plenty of POLA violations, but I don't think that is one.

  • (nodebb) in reply to David-T

    Indeed, it isn't, as revealed by the JS console in Firefox. with == and with ===, the result is the same.

  • Jonathan (unregistered) in reply to Steve_The_Cynic

    if "true" == "true" and "true" === "true" weren't both true

    They're probably not true, but are "true".

  • (nodebb) in reply to Jonathan

    No, they (er, the results of the comparisons) really are (according to the console in Firefox) the booleans rather than strings.

  • Scragar (unregistered) in reply to Melissa U

    In JS strings are primitives, meaning their equality logic doesn't follow the same logic as comparing objects(where any two objects are different even with the same contents).

    === really just means it passes the same check as == AND they're the same type. "1" == 1 is true, but "1" === 1 is false because their type is different.

    The weird exception to this is the Symbol primitive, which acts like an object in that they're all different on comparisons unless they're the exact same Symbol, even using ==. Symbol("foo") == Symbol("foo") is false.

  • (nodebb) in reply to Steve_The_Cynic

    That reminded me of the old joke, "In Heaven, the Germans are the engineers, the French are the cooks and the English are the policemen."

    In Heaven, the security is done by iPhone, screen size is by iPad, open source is by Android. I've never used a WinMobile device so I don't know what their strong suits were hahaha

  • Guessed (unregistered)

    It doesn't matter what the precedence of = is because this code doesn't use the assignment operator; it uses initialization, which is syntactically distinct from expressions. (Try (var x = 0) or var (x = 0): You'll get a syntax error.)

  • Duke of New York (unregistered)

    = in a var statement isn't an operator. It's initializer syntax. Precedence doesn't apply.

    While you should rely on capability detection and styling rather than user agent sniffing, projects in the real world (especially those that use var) have to deal with browser quirks and odd requirements, or used to.

  • Osric (unregistered) in reply to Duke of New York

    Especially if you've ever done something like browser game development targeted at mobile, the usual rules on capability sniffing generally start falling down, as there are things you need to check that are not covered by capability sniffing.

    For example: iOS at some point disabled the capability of going to fullscreen programatically (or at least did at a certain iOS version, and IIRC, it was maybe removed only on phone, but not tablet). Whilst you can detect that programatically (by knowing that you got a runtime exception when trying to invoke that api), the common solution adopted in the world of mobile gambling, is to allow a "swipe for full screen" gesture. If you want that implemented only on iOS, you need to start knowing about your environment you're running in. (Note that this all might have changed since I was doing this - the general rule on mobile, is nothing stays the same for long).

    It's not a pretty solution, for sure, but I don't fully agree with "you should always be using capability detection", because sometimes, there just isn't an obvious way to do that (and you can be aware that all of your rival game developers sure arent using capability detection to solve the same problem either)

  • (nodebb) in reply to Mr. TA

    I've never used a WinMobile device so I don't know what their strong suits were

    Laying tiles, of course.

  • (nodebb)

    we've got some lovely order-of-operations abuse: === has higher precedence than =, which makes sense but hardly makes this code readable.

    I'm sorry, but don't understand what the problem is here. === compares two things and = is assignment. Even ignoring the fact that these are all initialisers in the example, assigning the result of an equality comparison to a (boolean) variable is hardly a WTF and if anybody finds it difficult to make sense of, I suggest they do not seek to make a career in computer programming.

  • Flying Space Monkey (unregistered)

    TRWTF is split processing server/client. The bane of computing history.

  • Délibábföl (unregistered) in reply to Melissa U

    They are identical since both are representations of the same string in the string pool

  • Bob (unregistered)

    I'm sorry, can someone explain for n00bs like me how if (false === true) isn't always a no-op, and how var isMobile = "" === "true" etc. is not the same as var isMobile = false?

  • Osric (unregistered) in reply to Bob

    This is a bit of guesswork, but (false === true) smacks of conditional code pre-processing (replacing a constant with a feature flag), but where the relevant no-op code isn't removed out of the result - maybe I am being too generous, but that's a perfectly viable pattern in the js ecosphere

  • Ryc (unregistered)

    Sadly this is often the best way to do it - at the server (or maybe build) level it's doing a straight replacement, which means that it might be replacing a server side variable with an empty value - and if you don't want to create an error you've then got to wrap it in a string so you can actually check if it's empty. There's a high chance the config variables can be true / false / `` - so you've got to compare against the string value... In JS the strings as primitive objects are deduplicated and not pointers (so you can never compare the same string values and get a false result, but if they're Objects then they can be different - but we don't talk about that)...

    There's better ways to do this, but they require data validation on the server (or build) side which is often out of the control of the developer - hence doing this so it will at least work - and often making the "is it true" code support case insensitivity and even a "1" value etc)

  • (nodebb) in reply to Osric

    Yes, it looks like the code is generated based on some server-side condition. Something like this in PHP, say:

    <?php
$result = whateverFunction();
?>
if ({$result} === true)
{
	// do stuff
}

    In this case, if the PHP variable $result evaluates to false, then the resulting JS ends up as

    if (false === true)
{
	// do stuff
}

    as we saw.

Leave a comment on “Device Detection”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article