Check if it's a mobile device (In a Teams tab)

[JimmyWork]

I have an app that checks if the device is a mobile device or desktop by using the following way.

Set(IsMobileDevice, !IsBlank(Acceleration.X)));

Screen1: OnVisible
If(IsMobileDevice = true, Launch("https://apps.powerapps.com/play/xxxxxxxxxxxxxxx",{}, 
LaunchTarget.Replace));

This works great if i open it from the powerapps app.

It does not work if i add the app to a Teams tab, it seems that Acceleration does not work inside of Teams even if i open it using a mobile device.

So i found this solution instead.

ClearCollect(collName, true);    // here I created a collection with a single value: true //
SaveData(collName, "fileName");   // try to save that collection wich doesn't work on a browser, just mobile app //
Clear(collName);        // delete the value I collected previously //
LoadData(collName, "fileName",true);   // try to load the data to an emptied collection, if it doesn't load it is because we aren't on mobile //
If( !IsEmpty(collName),  "do what i want")      // finally, check if the data was loaded corectly and only do the action that i want if so //

 https://powerusers.microsoft.com/t5/Building-Power-Apps/Detect-web-browser-users/m-p/320550/highligh...

This also works great in app or web browser but in Teams it will throw a big red error message.

I don't want the users to see an error message even if the solution works.

Do anyone have a possible workaround that would allow me to check if it is a mobile device when the app is added to a Teams tab.

[GarethPrisk]

There are a number of Parameters that can be checked with regular Power Apps, and Oakdale apps, to help you figure out the exact context of your app.

Questions

1. Which scenario are you (regular Power App / new Teams-based app)?
2. Are you launching apps from the Teams mobile app (meaning an app tab, from Teams app)?
3. Are you launching apps from the Power Apps mobile app (meaning the app directly)?

As you noted, the Acceleration approach can/does work but has some limitations. Additionally, with the offline data approach, it also assumes some additional functionality. The Param approach can be helpful, but we have seen a few idiosyncrasies with what parameters are actually populated in different scenarios.

Please see an app attached (regular Power App), which you can use to explore Params in various contexts. It includes:

• Text Input to try params (you can pass your own, after all)
• Labels for basic review
• Data Table with known Teams params (about 16 as of this writing)

You'll notice some obvious things based on context

• Running the app from the Power Apps app
  • 0 params
  • This is the worst outcome; but does correctly infer that we have no context for Teams
• Running the app from the web studio
  • 3 params (tenantId, source, screenColor)
  • This is better, but again correctly tells us we have no context for teams
• Running the app from a Teams tab, in the desktop Teams client
  • All params except (chatId, subEntityId)
  • This is a great example of everything we need to know about Teams and, the device itself
• Running the app from a Teams tab, in the web Teams client
  • Same as above
• Running the app from a Teams tab, using the Teams mobile client
  • All params except (chatId)
  • NOTE: Some Params are not set but instead a string of the placeholder are included, like {teamType} - boo!

A few noteworth params can help decode what you need, in most (valid) scenarios

• source
  • teamstab, means it was launched from a Teams tab
• hostClientType
  • web
  • desktop
  • android
  • ios

Above all, it's important to understand that you have both a valid context (teamstab) and valid device (ios/android), depending on your scenario. Since you mentioned it being a mobile/teams tab, I am assuming that you want to exclude the non-mobile/non-Teams scenarios for the app. Hopefully this helps!

[JimmyWork]

@GarethPrisk Thank you very much this gives me something to look into.

To explain better what I'm trying to do is this.

App1 is designed for desktops/tablets canvas.

When the user opens this app I want to check if the devices is a mobile device, if it is a mobile device I Launch the Mobile app instead.

I do this because the desktop app is not designed to be responsive and i want mobile users to have less options available and less information.

I have setup my powerapp for teams by clicking the "Add to Teams" and made it available for users to install in Teams.

You helped me out a lot, but i do realize that the best and only solution here is to actually make the app fully responsive or have two apps one for mobile and one for desktop.

[GarethPrisk · Accepted solution]

I expect MSFT will eventually give us tooling to allow an app to be setup with 'desktop' and 'mobile' layouts, for given screens and controls. Think about how Power BI does it.

Until then, you are correct - you're going to need to decide between one app, or two context-oriented apps. The former is more difficult to design and develop, but makes it simple for users (if designed/developed sufficiently), to have the appropriate app experience depending on context. The latter is simpler to implement, but does require users to know when (or easily be directed/redirected) to the appropriate app.

An example pattern for a single app:

• Loading Screen
  • Determine if Param("hostClientType") in ["android",iOS"]
  • And/or Parent.Size (the screen size, as determined by breakpoints) is above/below a threshold
• Based on above, Navigate to the appropriate screen-set for the device type/resolution
  • The screens would navigate between screens of the same screen-set, and avoid the others
  • Obviously this can quickly bloat the app and cause redundancies 😞
• Desktop screens
  • Can fully respond to Parent.Width and be responsive and (presumably) landscape oriented
• Mobile screens
  • Can have the controls embedded with a container that acts as a boundary
  • The boundary size would be smaller than most mobile resolutions, but have a max to avoid excessive stretching in Desktop

Ultimately, you need to decide what your priorities are. In most cases, having two apps is a better approach since its easier to develop, will typically be more feature-specific and performant, but will demand careful planning to ensure users are using the right app(s) at the right time(s). Having a single app is certainly possible, and can cut down on some redundancies but ultimately requires extra coding/processing to constantly adapt the controls or a second set of 'stuff' (like example above) to give different UX based on context.