2 minor issues - NavMenu and screen orientation

Question

Hey,

I've been testing some stuff regarding the NavDrawer and screen orientation lately. The app must have all orientations checked and also auto rotation.

Here are two bugs that I've found:

1. The Canvas resolution must be something like 360x640 (X < Y), but start the app on landscape (mobile - android). The GUI elements are larger than normal (I think the resolution doesn't adapt to 640x360), but switching to portrait, and back to landscape corrects it.

2. Open up NavDrawer on portrait (mobile)

Switch to landscape -> the dark area of the NavDrawer is smaller (it's not autoresizing when the orientation changes).

Using latest MaterialUI with Unity 5.4.1p1. These are minor bugs, so whenever you have some time, please take a look at them :)

Many thanks,

Raydekk

Comments

I have many similar issues due to scaling in general. I'm targeting a 1440x2560 resolution and the Nav Drawer is WAY too small in the example scene.  In addition I had to increase the handle from 8 to 64 in order to even be able to open it.  

I screen captured the nav on device and screen captured Gmail's nav for comparison and used it as a template in Unity to line up the sizes. For the widths to line up I needed 370 for x for portrait (I have not tried any of this on landscape). However at this scale, the font text is way too large (about 2x), the icons are non-standard large (about 1.3x), and the list item heights are within a few pixels or so to being correct. The Nav header also doesn't line up (but it does at 380 for x).  I'm not sure if it helps but the Adaptive UI Grid only covers 1/4 of the screen width-wise (it seems to scale inversely to everything else - the smaller the reference resolution the smaller it gets unlike everything else).

All other example scenes have similar issues (being about 2x too small). Some of these can be fixed by setting the Canvas Scaler "Match" ratio to 0.5, but not all.

Using latest MaterialUI with Unity 5.4.0f3.

---

What resolution did you use in the end for the Canvas?

---

I wound up going with 360x640 and I'm going to live with the lack of complete parity with Google's apps for now. Unity does not make it easy, but one of the things I was hoping to find here was a scaler that had Google's "dp" units on the inside of a container so that it's easy to follow the spec.

---

Hey raydekk, Aaron,

Just wanted to let you know I'm aware of the scaling issues, and I am currently working on a new scaler that works similarly like how Android scales everything (DPI-based), which will completely replace Unity's CanvasScaler. CanvasScaler's 'constant physical size' mode also works this way, but imo it's useless if you want fine control over it.

This results in more consistent sizing between devices with different pixel densities, and completely does away with worrying about reference resolution width/height/orientation.

So far it seems to be working really well, but I'm still in the process of polishing and testing it, and improving compatibility with both mobile and desktop screens without needing to change any settings - so far it does either one great, but not both, but I believe I know how to solve it in the near future.

In fact, it would be fantastic if I could have some assistance with testing the new scaler. Would you be interested in trying out a test version of it?

~ Declan.

---

Sure thing...i'm up for it

---

Mind giving me an email I can send it to?

(Or just shoot one over to contact@materialunity.com and I'll reply to that)

---

Sent :)

Thanks for helping to test this out.

---

Is there any update on the estimated time when the plugin will be updated with this scaler?
The plugin itself hasn't been updated since 25 okt 2016 (half year) and we're in the middle of a rework / development of our app. We'd love to use the plugin but with these bugs it will be in an unreleasable state. We use DP scaling by setting the canvasscaler's scaleFactor to Screen.dpi / 160, but by doing so it breaks the animations as they don't scale by the scaleFactor apparently.

Also the prefabs bug where values are locked because of SetDirty in the EditorUpdate (as described in an other post) due to this bug we can't really use version control to update our prefabs normally without bypassing it by breaking the prefab instance.

Instead of a Soon (tm) could you give a raw indication please? We want to know if we're even going to make our deadline or have to schedule in time to fix these bugs ourselves somehow, though this will cause conflicts with future updates which we want to prevent of course.

We're really looking forward to the bug fixes as well as feature additions that were described in other posts.