Best way to identify a device

Hi,

In my web app, I need to differentiate computers, phones and tablets, for showing more or less data given the screen’s size.

In Web 1.0, there was an available constant, no longer available in 2.0.
So, I found 3 workarounds but don’t know which one is best.

1: detect the screen size. With all possibilities of existing screens, it’ll be overcomplicated to take a decision.
2: parse Session.Header(“User-Agent”). An iPad and Mac return the same data, so won’t work. Also, parsing is never much reliable here.
3: I noticed an OrientationChanged event is triggered for phones and tablets (the ones I tried), although not documented (therefore, reliable?). Mixed with 2:, maybe something can be built…

Anyone already dealt with such a question?

Don’t build for the device, build for the dimensions. When possible, build in a responsive manner, even if you have to use Resized events. If you’re going to target a wide variety of screen sizes, it’s really the best way.

I just released GraffitiResponsive for Web 2.0 which can help you out there as you can embed containers in a flex layout.

1 Like

Ok. In my case, it’s displaying a custom calendar. For small screens, I can’t shrink the picture (as it would become unreadable) but rather would show only “today” and “tomorrow” (from the start day) and less hours in the day. Is this a bad design, knowing the “desktop” web version is already working?

Thanks. Actually, it’s just “either I can show all data, or I show a lite version”. I can’t easily resize down and it’s not a variety of screen sizes, just the one which are “too small”, whatever that means…

Yes, these classes look amazing and I considered buying them already twice. But for a single developper with no extra money, it’s too expensive (for me, at least).

First, I wouldn’t use a picture. You’re targeting the web, you should build something web. Barring that, you could detect the resolution and send a different picture that’s a legible size, switch to a list view of days and events, or some other more appropriate measure.

That’s the thing. You’re designing large and expecting everything else to just work. It’s not going to, and forcing a mobile device display to fit the desktop paradigm is a recipe for disaster either in terms of view-ability or user experience. In many cases, you may need to entirely rethink and/or reimplement your design to handle devices with a width or height of <768px.

One way some people get around this is having their logic in a module and creating two versions of a page, one for large displays and the other for small displays. But the best route is to design responsively using web technologies.

Sorry, I translated wrong. Of course, I’m drawing directly to a WebCanvas.

Yes, I didn’t considered mobile enough (I rarely use web pages on a phone and this is a me-and-friends only project). I’m now choosing what to strip off the working project (rethinking without breaking the working part).

That’s the path I chose. Only, I use properties rather than modules and reuse the same classes.

I don’t know them so won’t choose this path :thinking:
It’s currently well responsive, I think.
Thanks.

I see it the other way around, being a solo developer I would rather pay for the stuff that @Anthony_G_Cyphers has done with Graffitisuit over having to develop them myself (I don’t have the time).

2 Likes

And me, it’s the other way around :grin:
I have the time but not the money.

I agree, if I can afford it I buy toolkits like this to save me time, but I understand that not everyone can do that. Especially if your bootstrapping or developing free software.