Flexible templates for phone vs tablet - best practice?

Hi all, question.We’re building a hybrid phone/tablet app, and would like to provide an enhanced view for tablet layouts.

I found (and replied to) a similar forum post from a year ago (Ionic best practice: Responsive Design vs separate templates for Mobile/Tablet/Web)… but I’m not sure what solutions are out there. Is anyone else providing multiple layouts for tablet vs phone? If so how are you accomplishing it?

Here’s mine. It works, but it sure doesn’t seem elegant. Better answers are gleefully appreciated :smile:

providing a seperate template for tablet vs modal:

.config(function($stateProvider) {
  $stateProvider
  .state('app.jobdashboard', {
    url: "/job/details",
    views: {
      'menuContent': {
        templateUrl: window.innerWidth < 500 ? "templates/job/dashboard.html" : "templates/job/dashboard-wide.html",
        controller: 'JobDashboardCtrl'
      }
    }
  });
})

Sure wish there were more best practices or built-in functionality for this. Seems needed, and a platform IsTablet would be just as if not more useful than isIPad.

1 Like

isTablet would be the holy grail for this sort of thing. Sadly the increasing pixel density and varying devices sizes make this almost impossible get right.

I’m building Foodica for mobile and tablet view and what I’ve decided on is to change the display type at config level. Most apps either have a 2x mobile portrait view or a landscape/responsive tablet version. So up front the developer knows they’re posting the app for different views.

1 Like

Foodica looks very cool, hope you have success!
Want to go into a little more detail how you are implementing change at config level? Is that config as in a user setting?

@nerdlandiamark Thanks.

Something along the lines of creating an angular constant that takes the folder name of the mobile or tablet templates. So switching between the two values changes the display.

I’ll be writing the detail in posts leading to foodica’s launch. So subscribe if you’re interested.

Hi @nerdlandiamark. Its been a while. Between then and now there are 3 possibilities:

  1. Have a config variable isTablet = true/false. Then, depending on which, set the starting route of the app for either mobile or tablet (this is what I started with in Foodica). You end up with two folders that share the same scss

  2. same as (1), but instead, house the two versions in the same template file using ng-if=!isTablet or ng=isTablet for mobile and tablet respectively. less files to deal with but duplicate markup

  3. heavy reliance on media query plugin. Problem is you have to test this at design level.

So how do you determine if it’s an Android tablet?

You don’t test for tablet/mobile. You make the call to submit two versions of the same app (one for mobile, one for tablet). The concession with (1) or (2) is you don’t need to have two project folders for managing tablet and mobile. So you merely change the variable to the relevant device size (of course your design would have been planned from the get go to look well on a 7 inch in portrait mode)

Baring that, option 3 is where I’m thinking I should go in the future, assuming I can calculate the width/height and pixels and ratio and come up with function that works well.

Please let me ask in another way: it sounds like mobile/tablet is under user control. If that is correct, are you saying there is a separate mobile and a tablet app in the app stores, or is it a single app, but at start up the user specifies the device (and the app specifies stuff like layout for each screen).

There are some apps that have “Tablet” version on the app store, e.g. Evernote. As I imagine that you can’t download the tablet version on an iphone, they have to be “separate” versions of the same app. So rather than automatically determining if its a tablet, or letting the user decide, the next best thing would be submit a mobile version and tablet version respectively to the same store. All you would have to do is change the variable isTablet and the underlining code handles the rest (proper views, etc)

Reply if you need more info