Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Update swipedown menu to be application wide. #515

Closed
glasspear opened this Issue · 23 comments

7 participants

@glasspear
Collaborator

With the new bb10 design guideline released (https://developer.blackberry.com/design/bb10/menus.html) it appears that the application menu should be application wide rather than screen based.

A couple things to ponder:
1 - where will it be generated now? In the index.html code, or should it be an object passed through the bb.init() function?

2 - Does this negate issue #57? Seems counter the rules to be able to change the menu once the app runs?

Thoughts on this?

@tneil
Owner

All very good questions up for discussion and debate :)

@glasspear
Collaborator

Since no one else is chiming in my thoughts:

I think it should switch to application wide and it should be an bb.init() like onscreen ready, it could be passed a JSON object of the up to 5 menu options including icon, click function and text. It would be parse top to bottom for positioning left to right.

I also think that even though it isn't in the UI guidelines for Playbook that the UI guidelines for BB10 should be used for the Playbook. This will not only reduce code, but also confusion.

The menuitem separator also appears to be an item that can be removed as there is no mention of it in the UI guidelines. It would still be in place for BBOS.

If this is accepted then it would definitely negate Issue #57.

These updates could be combined with Issue #379 to bring the swipemenu inline with the application menu.

Also up for discussion would be changing (or aliasing) these functions to call them appMenu for consistency sake.

@tneil
Owner

Another option is to include the application menu in a text/template javascript tag. This way you could use the same formatting that we already have today. It could be included inline in the index.htm or as a linked in javascript file

<script type="text/template">

     <div id="mymenu" data-bb-type="menu">
          <div data-bb-type="menu-item" data-bb-img="icon1.png" onclick="foo();">Foo</div>
          <div data-bb-type="menu-item" data-bb-img="icon2.png" onclick="bar();" data-bb-selected="true">Bar</div>
          <div data-bb-type="menu-item" data-bb-img="icon3.png" onclick="fooBar();">FooBar</div>
          <div data-bb-type="menu-separator"></div>
          <div data-bb-type="menu-item" onclick="barFoo();">BarFoo</div>
      </div>

</script>
@glasspear
Collaborator

That is a much better way to handle it actually! I admit I hadn't heard of this, but from what I can find it is a perfect use of text/template.

I didn't really want to add things to bb.init(), JSON was the least messy way I could think of.

@tneil
Owner

What I haven't been able to figure out yet is how to take the contents from a text/template and get it into an XML structure. I'm assuming you would do it with DOM Parser

  var parser = new DOMParser();
  xmlDoc = parser.parseFromString(text,"text/xml");

I'm wondering if we should do it more like the following:

<script data-bb-type="menu" type="text/template">
          <div data-bb-type="menu-item" data-bb-img="icon1.png" onclick="foo();">Foo</div>
          <div data-bb-type="menu-item" data-bb-img="icon2.png" onclick="bar();" data-bb-selected="true">Bar</div>
          <div data-bb-type="menu-item" data-bb-img="icon3.png" onclick="fooBar();">FooBar</div>
          <div data-bb-type="menu-separator"></div>
          <div data-bb-type="menu-item" onclick="barFoo();">BarFoo</div>
</script>
@LizMyers

Am late to the party here and unaware of all the issues - but - I like the above menu structure. Very simple to understand/use. Also agree that Device & Playbook coding should be same. In fact, I've been using responsive design as much as possible (specifying em spacing and % layouts) in the hopes that I could have one BB code base.

@tneil
Owner

Adding a dependency to #497 for text/template support...

The other complication is that currently the the screen menu is used for BBOS/PB/BB10 as per screen menu. Moving it to an application wide menu will have some conflicts with the BBOS screen based menu.

Possible thoughts are to make the Context Menu the screen based menu implementation for BBOS since you can only have one context menu per screen already.

@nathanpc

I have no problem with swipedown menus being application-wide. If you want a screen-wide menu you should use the ActionBar one.

@4PeopleSoftware

I don't think you can make the context menu the screen menu in BBOS. There is a difference. When you press the BB button you get the general menu or to keep using the same terms here, the screen menu.

When you select an item, like in the ListField and the user presses the trackball/-pad or on touch screen BBs touches the item, the app can show a different menu that in later BBOS versions is a modal dialog based menu and on earlier BBOS versions it's a normal menu but it opens in the center of the screen above the trackball/-pad.

What I would do is this:

If you specify a menu in index.html via the above proposed way using the

@tneil
Owner

But the BBOS BB button menu is also context aware. It isn't only the press and hold on later BBOS devices that's context aware. The press and hold menu on latter BBOS devices typically shows a subset of the main BB button menu which is also context aware.

I figured that since we aren't supporting press and hold context menus on BBOS, I thought we could piggy back on this unused declaration. Considering you can only declare one context menu per screen in bbUI

@4PeopleSoftware

the BB button menu is only context aware because it can be implemented like that in BBOS (when you write it native in Java). But here we are coming from a different angle.

Maybe I need to rephrase what I wrote above to make it more clear :-)

@tneil
Owner

Yup I understand that... however the bbUI context menu is also only context aware if you implement it like that :)

@tneil
Owner

Thinking about it more, I believe you are right.. we could just simply make what currently is the "screen menu" an application wide menu. For individual screens on BBOS, you would use the blackberry.menu.* apis to manipulate the items for the screen/context if you needed to change them.

@4PeopleSoftware

Another thing I would add: While you put an awful lot work into the library to make it work with BBOS as well, I think the focus going forward should be on BB10. I think very soon not many if any would use bbUI and WorkWorks to build a BBOS application. I may be wrong but I can't see it being the case.

@glasspear
Collaborator

Would the application menu get re-written per screen then Tim? That way for BBOS if they added something with the blackberry.menu.* apis for a specific screen it would be cleared out and they could add new items for the new screen. Wouldn't be any extra overhead on PB and BB10 compared to the current system as it is being redrawn on those currently. Although there is something to be said to make it application wide and not redrawing it for efficiency sake.

I agree that BBOS should receive less focus, but in many cases it doesn't take much work to make things backward compatible with it.

@tneil
Owner

Let's start off with getting the "push the screen contents down" functionality in place #379. That way we will have the appearance tweaks figured out, and then we'll come back and tackle the application wide question.

Compatibility changes are tricky and I'd like to think this one through a bit more

Sound like a plan?

@rorycb

Makes sense to me. I'll start working through #379.

@glasspear
Collaborator

Wrong account :) But still me.

@glasspear
Collaborator

Another item that is needed in this update for BB10 -

When a menu item is touched (but not released) a highlight appears above it using the highlight colour of the app

Note: this was worked in as part of #815

@sh2sg

Should swipedown event be disabled after app launched a card? For example app calls media player card, swipe down menu still works but behind the card, once you quit the card, you will see swipe down menu is already triggered.

@glasspear
Collaborator

It probably should be disabled, I'll have to look into how to detect a card entering and exiting the screen.

@tneil
Owner

Rory, do you want to open up a new issue to track that scenario?

@glasspear
Collaborator

:+1:

@tneil tneil closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.