blackberry / BB10-WebWorks-Framework

The BB10 WebWorks Framework is packaged within an application BAR file to run on a BB10 device (or simulator)
60 stars 34 forks source link

As a webworks developer I have access to window covers #395

Open nukulb opened 11 years ago

nukulb commented 11 years ago

feature to be whitelisted blackberry.app

blackberry.app.coverSize - returns the size of the cover to expect, eg - {x:396,y:294}
blackberry.event.addEventListenerr('entercover', function () { }); blackberry.event.addEventListener('exitcover', function () {});

blackberry.app.setCover(cover); where Cover is

* "cover":{
"type":"snapshot" // can be file|snapshot
 "capture":{"x":0,"y":0,"width":100,"height":200}}, //needed in the case type is snapshot.
"path": "/some/awesome/path/file.jpg", // needed int eh case type is file
  "text":[
   {"label":"Label", "size":3}]  // An array of objects describing strings to draw on the label. The navigator will choose the amount of text that will fit.
             //takes in label, size, color, wrap - color is HEX string like #FFFFFF, wrap is a boolean value
  "transition":"default",         //transition Valid transitions are: default, slide, fade, none. specifies the transition used when changing to the new cover
   "badges":true                   // A Boolean value that specifies if badges should be shown over the cover or not.
 }

Implementation qnx.webplatform.getApplication().coverSize qnx.webplotform.getApplication().updateCover(cover)

events through webplatform/framework/chrome/events/application

jeffheifetz commented 11 years ago

Do we want to define some constants for some of these values, mainly the possible type and transition values.

kwallis commented 11 years ago

Does this provide all the same capabilities as native? Is the developer able to periodically update the cover with subsequent setCover calls?

nukulb commented 11 years ago

the feature you are mentioning is called covers with type="live" Just like you have type snapshot or file. Unfortunately this capability is not open to External developers and requires internal permissions. So I don't believe external devs can do "periodically update the cover" in any other platform either.

If the app has the internal permission it should be able to do it even in WebWorks.

nukulb commented 11 years ago

@jeffheifetz @haahmad - we should define constants for type and transitions since they are constants.

nukulb commented 11 years ago

confirmed cascades only allows static images or new UI tree but only once :) No live updates

According to cascades docs -

"Cascades lets the developer use static images or a completely dedicated UI tree to present itself when minimized."

jeffheifetz commented 11 years ago

Does "A new ui Tree" mean a different file entirely? Could we define a cover in HTML?

nukulb commented 11 years ago

It has been deemed that we need a better API for this as the cover object can be complex to figure out for the end user.

In light of doing a better API we are descoping this from the next release and doing one for the release after the next one as we are out of time for the next release.

Cascades exposes a very nice and clean API for this and we should experiment with doing some awesome things before we just do a pass through API.

cc @kwallis @bhiggins @haahmad will be working on a proposal tomorrow for this.

@haahmad - when you are ready please put up your proposal on this issue and we can talk about it in more detail.

haahmad commented 11 years ago

I am thinking along the lines of something like this:

blackberry.ui.cover: {
    function setContent(type, options) {...}, //type = blackberry.ui.cover.TYPE_IMAGE --> options = {path : ....}, type = blackberry.ui.cover.TYPE_SNAPSHOT --> options = {x: , y: , width: , height: }, type = blackberry.ui.cover.TYPE_DOM --> options: {dom: }
    function setTransition(transition) {...}, //sets transition for applications cover
    function updateCover() {...}, //actually updates cover
    function resetCover() {...}, //resets the window cover to default
    coverSize, // {"x":334, "y":396} width and height
    labels, //array of CoverLabel objects, {"label": "label", "size": 8, "color": "#FF0000", "wrap": true}
    badges //boolean whether or not splat notifications will be dispalyed
}
nukulb commented 11 years ago

you need to add

resetCover()
haahmad commented 11 years ago

@nukulb updated

nukulb commented 11 years ago

whitelisting blackberry.ui.cover I assume.

nukulb commented 11 years ago

@kwallis - you ok with the new proposal from @haahmad

nukulb commented 11 years ago

@haahmad its confusing that these are exclusive

function setImage(path) {...}, //path to image for window cover function setSnapshot(x, y, width, height) {...}, //snapshot dimensions for snapshot window cover function setContent(content) {...} //DOM content that will be displayed in the window cover (through UIWebview)

you can't set all three

how will the user know?

haahmad commented 11 years ago

@nukulb calling one of those would wipe out the other two, we could document that. Maybe we should add a property that exposes what mode the cover is currently in.

nukulb commented 11 years ago

setContent(type, options)

if type is Image then options = {path : ....} if type is Snapshot then options = {x: , y: , width: , height: }

haahmad commented 11 years ago

Updated to include new setContent function

nukulb commented 11 years ago

@kwallis I think I am ok with the updated proposal What are your thoughts on it?

As for when to update. Users can update it any time, they get an entercover and exitcover when entering and exiting cover. They can set it any time they want. run_in_background just means when their javascript can run so they don't need to use but if they want to have frequency of updating the covers while under cover they will need to do that using setTimout(function () { } , 20000)

@haahmad make sure you test the above scenario please

kwallis commented 11 years ago

As long as we document whether they need to have run_when_backgrounded or not. I like the latest proposal.

haahmad commented 11 years ago

@nukulb @kwallis updated again to include coverSize and renamed constants so they also include what property they refer to, for example blackberry.ui.cover.TYPE_IMAGE

bglowDragosh commented 11 years ago

Hello everyone. Any updates on when we will be able to implement setting new DOM content in a window cover?

bbsam commented 11 years ago

Hi,

Good Morning.

I am trying to implement something like nukulb mentioned in this forum in my webworks application:

"As for when to update. Users can update it any time, they get an entercover and exitcover when entering and exiting cover. They can set it any time they want. run_in_background just means when their javascript can run so they don't need to use but if they want to have frequency of updating the covers while under cover they will need to do that using setTimout(function () { } , 20000)"

Is this supported? If so give me some sample how to do it.

Thanks in advance.

splatterb0y commented 11 years ago

Hi guys. I just want to recommend adding an image from http as cover. Maybe the WebWorks API can handle the download and base64 encoding of the image to make it usable?

bbsam commented 11 years ago

Yes this would be helpful...

listedegarde commented 10 years ago

I was working on a Webworks window cover this evening, and was making use of blackberry.ui.cover.TYPE_SNAPSHOT {x: , y: , width: , height: } I discovered y (and I assume x) is calculated after width and height. Although it can be resolved through simple mathematics, it just seems more logical to calculate x and y first, or resize them proportionally. For example:

Using the Dev Alpha C: the cover size is {width:310,height:211}. If I set my snapshot to y:94 (to remove the title bar), it will work perfectly if my width and height are set to 310 and 211, respectively. However if I decided to use 1.5 times that width and height, {width:465,height:317}, y must be set to 63, which of course is 94 / (465 / 310). The reason, it seems, would be that it starts by fetching 463 x 317, resizing it to 310 x 211 and then subtracting x and y, which were not resized proportionally.