Merge lp://staging/~abreu-alexandre/unity-webapps-qml/application-api into lp://staging/unity-webapps-qml

I tested it and it's mostly working. A few comments:

getPlatformInfos: I think it's better to call it "getPlatformInfo" without the final "s". Anyway, this just returns the name of the QPA plugin, so I'd rather rename the method to "getPlatformName" or keep the current name and make it return a dictionary, currently having only one field "name" which contains the platform name. But I'd take the second approach only if you really plan to add more info there in the future.

The example expects the onActivated() and onDeactivated() signal to carry a parameter, but they don't.

All the methods are asynchronous and take a callback; even the applicationName() function is asynchronous, even if the result is immediately available. I'm not familiar with HTML5 development so this might be perfectly fine, I just point this out because coming from the C++ world this sounds rather strange (and a bit inconvenient).

Naming: it's better to use the same convention for all the getters: either start their name always with a "get", or never. Most of the methods you added start with "get", but "applicationName" doesn't.

getInputMethod(): it's not very clear what this function does; maybe rename it to "getInputMethodName"?

nameFromScreenOrientation(): you are only use two possible values, "Landscape" and "Portrait", while Qt supports 4. I guess that most apps don't care about distinguishing between the extra modes, but maybe some do (to be sure that the mic is on a specific side, for instance)?

> I tested it and it's mostly working. A few comments:
>
> getPlatformInfos: I think it's better to call it "getPlatformInfo" without the
> final "s". Anyway, this just returns the name of the QPA plugin, so I'd rather
> rename the method to "getPlatformName" or keep the current name and make it
> return a dictionary, currently having only one field "name" which contains the
> platform name. But I'd take the second approach only if you really plan to add
> more info there in the future.

done,

> The example expects the onActivated() and onDeactivated() signal to carry a
> parameter, but they don't.

done,

> All the methods are asynchronous and take a callback; even the
> applicationName() function is asynchronous, even if the result is immediately
> available. I'm not familiar with HTML5 development so this might be perfectly
> fine, I just point this out because coming from the C++ world this sounds
> rather strange (and a bit inconvenient).

right, agree, took another approach,

> Naming: it's better to use the same convention for all the getters: either
> start their name always with a "get", or never. Most of the methods you added
> start with "get", but "applicationName" doesn't.

done,

> getInputMethod(): it's not very clear what this function does; maybe rename it
> to "getInputMethodName"?

done,

> nameFromScreenOrientation(): you are only use two possible values, "Landscape"
> and "Portrait", while Qt supports 4. I guess that most apps don't care about
> distinguishing between the extra modes, but maybe some do (to be sure that the
> mic is on a specific side, for instance)?

right, agree, done

FAILED: Continuous integration, rev:99
http://jenkins.qa.ubuntu.com/job/unity-webapps-qml-ci/98/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-webapps-qml-trusty-amd64-ci/46/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-webapps-qml-trusty-armhf-ci/46/console

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/unity-webapps-qml-ci/98/rebuild

PASSED: Continuous integration, rev:102
http://jenkins.qa.ubuntu.com/job/unity-webapps-qml-ci/100/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-webapps-qml-trusty-amd64-ci/48
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-webapps-qml-trusty-armhf-ci/48

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/unity-webapps-qml-ci/100/rebuild

I think there's a problem with how the getters are implemented. Let's take getScreenOrientation() for example: when the client calls this method, it will retrieve the application name which was setup, which is correct. If the application registers a callback with onScreenOrientationChanged(), then this._screenOrientation will always get updated propertly, so getScreenOrientation() will always return the proper value; however, if the application doesn't call onScreenOrientationChanged(), this._screenOrientation will never be updated and getScreenOrientation() will always return the old value.

I'm not sure how expensive the switch betwenn client and backend is, so depending on that:

1) If the switch is not very expensive: don't cache any values in the client, always request the properties directly from the backend.

2) If the switch is very expensive, do as you are doing, but register an internal callback to the cached properties in the Application constructor. Something like:

  var self = this;
  this._name = content.name;
  this._proxy.call('onApplicationNameChanged', [function(name) {self._name = name; }]);

(In the latter case we might even want to avoid passing through the backend when the client calls onApplicationNameChanged(): we could make it store the function callback into an array (this._applicationNameListeners) and in the callback registered in the Application constructor we could then invoke all the callbacks in this._applicationNameListeners, after having updated "self._name = name")

Can you also make the getInputMethodName return the value immediately?

Other than that, it all looks good to me!

> I think there's a problem with how the getters are implemented. Let's take
> getScreenOrientation() for example: when the client calls this method, it will
> retrieve the application name which was setup, which is correct. If the
> application registers a callback with onScreenOrientationChanged(), then
> this._screenOrientation will always get updated propertly, so
> getScreenOrientation() will always return the proper value; however, if the
> application doesn't call onScreenOrientationChanged(), this._screenOrientation
> will never be updated and getScreenOrientation() will always return the old
> value.
>
> I'm not sure how expensive the switch betwenn client and backend is, so
> depending on that:
>
> 1) If the switch is not very expensive: don't cache any values in the client,
> always request the properties directly from the backend.
>
> 2) If the switch is very expensive, do as you are doing, but register an
> internal callback to the cached properties in the Application constructor.
> Something like:
>
> var self = this;
> this._name = content.name;
> this._proxy.call('onApplicationNameChanged', [function(name) {self._name =
> name; }]);
>
> (In the latter case we might even want to avoid passing through the backend
> when the client calls onApplicationNameChanged(): we could make it store the
> function callback into an array (this._applicationNameListeners) and in the
> callback registered in the Application constructor we could then invoke all
> the callbacks in this._applicationNameListeners, after having updated
> "self._name = name")
>
>
> Can you also make the getInputMethodName return the value immediately?

all done