B4J Question [ABMaterial] Navigation bar recommendations for small devices???

[Mashiane]

Hi there

The ABM navigation bar on small devices for me is very tricky. The title at times seems to take a while to decide where it wants to be placed so it dances a little bit left and right then it holds. Perhaps its mym device. I need some recommendations on how to make this work for me.

I need a way to automatically decrease the font size for small devices so that it fits on the available space and any other thing others are doing in handling or not handling the nav bar for small devices.

Another thing is there a way to hide the hamburger button?

 

[Anser]

In the BuildPage()
Did you try

ABM.SetFontSizePercentages(80,90,100)

OR

ABMShared.BuildNavigationBar(page, "{ST:font-size: 20px !important;   position: relative;   top: -2px;}Your Nav bar Title{/ST}","../images/logo.jpg", "", "", "")

It seems that the first method is the recommended one

 

[alwaysbusy]

ABM 4.32 will have a property in the NavigationBar theme to hide the Title if on small devices:

MyTheme.NavigationBar("onetwo").TopBarTitleVisibility = ABM.VISIBILITY_HIDE_ON_SMALL_ONLY

Why would you want to hide the hamburger icon? That means the user cannot navigate anymore within your app. Just don't use a navigationbar then alltogether.

 

[Mashiane]

Thanks guys. I want to hide the hamburger on left and have a button on the right side of the navbar that a user can select and it will show my own defined side bar on the right.

 

[Harris]

want to hide the hamburger on left and have a button on the right side of the navbar that a user can select and it will show my own defined side bar on the right.

Or, have hamburg show the contents of your right sided menu... (on the left). I do this now (public or private menus).
Too many disparate features skew how one expects an app to work (mobile or desktop). Let us try not to break the Material concept and dig ourselves a hole we shall ultimately bury ourselves in. Unless we are gainfully employed by Google - we cannot call these shots.
This does make us ponder however - How the heck did those developers ever get employed by Google (what were they thinking)?

 

[Mashiane]

Or, have hamburg show the contents of your right sided menu... (on the left). I do this now (public or private menus).
Too many disparate features skew how one expects an app to work (mobile or desktop). Let us try not to break the Material concept and dig ourselves a hole we shall ultimately bury ourselves in. Unless we are gainfully employed by Google - we cannot call these shots.
This does make us ponder however - How the heck did those developers ever get employed by Google (what were they thinking)?

Thing is, most people (I could be wrong) are right handed and it makes sense to use the right thumb to select stuff and scroll, unless of course you are using both hands. I believe in giving people options and thus things should be at least flexible and not locked up to make them difficult to use. I guess though nothing could be ever perfect, only in some dreams.

 

[Harris]

most people (I could be wrong) are right handed

True... (but who are we to discriminate)?
It is a Material convention.
I have not found an app that asks if you prefer left - or right hand operation? (imagine the coding involved). How do you propose to make this setting?

The point was: "Too many disparate features skew" ... AB has already sidelined the Material base to accommodate his (and our) whims and needs -as he has stated - and mostly against his better judgement. We don't complain - we like it! It is our AB - Material Design - and it works.

You (and I) have a hard enough time trying to keep up with each new version features. My advise: be careful what you ask for.
My 2 pesos....

Thanks

 

[alwaysbusy]

And I am a lefty, so that argument doesn’t make sence at all!

 

[Mashiane]

My point is, nothing is impossible and our imagination can take us only to how far we want to go. That is exactly why ABM is beyond normal, its extra ordinary.

That is why also in the feedback app we have a feature request for anything doable (that does not break existing code) and will work and other important considerations like ABs time.

Looking at just the additional features that ABM already has is evident to it breaking grounds and going to infinity and beyond. Did I just quote toy story?

If everything in ABM is a component and has a reference I.e and id, and using css to turn off or on the visibility property with existing abm visibility enumeration could work and is doable and wont break any existing code, then part of my question is already solved.

I dont think ABM was ever in the first place bound and limited to conventions, otherwise we would only be having components as equal with the same look as to what material designs has in store, it has gone beyond the call of duty to be the excellent tool it is, outside that box frame, with additional components and exciting features driven by the same imagination of AB and people who request features. I understand that those are scaled, importance and value add, besides no one can please everyone otherwise we would have dysfunction. Thanks for the chat.