You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A user/developer wants to evaluate the energy consumption of one of his smartphone application,
this one launch the Hot-Pepper Android application, log in, select the APK he wants to evaluate and send it to one of our server,
the server, receiving the request, will select a user-based scenario for this specific application (wrote by a user/developer for example), or just Monkey if the user-based scenario for this application is not available,
all energy consumption tests, for this application, are launched - using for example lightpowertool and the Yoctopuce ammeter - 5 or 10 times,
tests are done - the user is noticed with a notification from the Hot-Pepper application, and a simple dashboard for these tests will be available on his personal account (on the Hot-Pepper website),
if the application can be improved (for energy consumption), a new APK is automatically generated (Spoon?) and the user/developer can just download it on his personal account.
We can imagine also that, if the application has already been tested (we have to ensure that the application has the same build version id), we will not run tests again but just send saved informations to the user.
Also, we can purpose to the user to upgrade his application if the next build version is more economical, or notice him that the next version is, in contrast, less economical.
The text was updated successfully, but these errors were encountered:
LightPowertool extract the timeline for the measures (FxOS-Powertool canno't) - I think I can correlate with more or less accuracy this timeline with the scenario's timeline...
To correlate the energy consumption with other versions of the same app can be also usefull for developers but also for the application users. For example, if the next version of the application improves a few things but consuming more energy, the user can refuse this upgrade...
This feature can be imagined using this scenario:
We can imagine also that, if the application has already been tested (we have to ensure that the application has the same build version id), we will not run tests again but just send saved informations to the user.
Also, we can purpose to the user to upgrade his application if the next build version is more economical, or notice him that the next version is, in contrast, less economical.
The text was updated successfully, but these errors were encountered: