Hello, I agree with Sakari. In SysApps API's asynchronous methods should return either a Promise [1] (handling simple success/error outcomes of an async operation), or a control object such as TelephonyCall (for handling more complex scenarios such as state machines). Then it is possible to wire up test routines to them. Most SysApps API's should already be updated for using Promise's.
However, in Tizen API's the only way to test async methods is as painful as Alexis has described. We should fix these API's, so I assume we need to raise bugs to the spec, since they cannot be correctly tested (as per "computer science correctness"). [1] http://dom.spec.whatwg.org/#promises Best regards, Zoltan On Wed, Sep 18, 2013 at 2:18 PM, Poussa, Sakari <sakari.pou...@intel.com> wrote: > Yeah, > > The synchronous APIs are not the nicest ones, I have to agree. However, we > should keep the behavior and emulate it. But put a big comment there why > we do such busy waiting. > > And yes, the SysApps APIs will not be synchronous. > > BR; Sakari > > On 9/18/13 12:27 AM, "Kenneth Rohde Christiansen" > <kenneth.christian...@gmail.com> wrote: > >>I kind of believe that we need to implement the API the way it is >>designed; even if that makes no sense at all. At least it would be >>good to propose a better Power/Idle API soon as it should be quite >>easy to implement. >> >>Kenneth >> >>On Tue, Sep 17, 2013 at 9:51 PM, Menard, Alexis <alexis.men...@intel.com> >>wrote: >>> Hi, >>> >>> I was fixing the remaining tests from the tct suite related to Power >>>API and I'm left with two failures which I'd like to discuss. >>> >>> Consider the Power API : >>> >>>https://developer.tizen.org/help/topic/org.tizen.web.device.apireference/ >>>tizen/power.html >>> >>> and these methods : >>> >>> void turnScreenOn () >>> void turnScreenOff () >>> setScreenBrightness() >>> >>> The two tests are failing because they're testing the API basically >>>that way : >>> >>> turnScreenOn() >>> assert_true(isScreenOn()) >>> >>> Problem is that the underlaying C API we call (or even any other Power >>>management API I believe) is not a synchronous function call. It takes >>>few ms to change the brightness or to wake up/switch off the screen also >>>because you may need to change the power state and so on. >>> >>> I believe these TCT tests are covering the behaviour for the old WRT. >>>If we want to be compliant we need to behave the same and therefore >>>emulate the synchronous behaviour (btw I hope the SysApps API are better >>>because OMG these are terrible APIs). >>> >>> As we use the same C API as the ones in the old WRT I was curious on >>>how the people behind the old WRT solved it and here is the magic piece >>>of code : >>> >>> void PowerManager::setScreenState(bool onoff){ >>> int ret = 0; >>> if( onoff ) >>> ret = pm_change_state(LCD_NORMAL); >>> else >>> ret = pm_change_state(LCD_OFF); >>> if( ret<0 ){ >>> LoggerE("Platform error while changing screen state %d", ret); >>> throw UnknownException("Platform error while changing screen state"); >>> } >>> >>> int timeout=100; >>> while(timeout--){ >>> if( isScreenOn() == onoff ) >>> break; >>> usleep(100000); >>> } >>> } >>> >>> So should we emulate the sync behaviour? If so, I believe that we can >>>do better than the piece of code above (by blocking the return of the >>>fct while we wait the state change callback from the platform) -> better >>>suggestion? >>> >>> Software Engineer @ >>> Intel Open Source Technology Center >>> >>> _______________________________________________ >>> Crosswalk-dev mailing list >>> Crosswalk-dev@lists.crosswalk-project.org >>> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev >> >> >> >>-- >>Kenneth Rohde Christiansen >>Senior Engineer, WebKit, Qt, EFL >>Phone +45 4294 9458 / E-mail kenneth at webkit.org >> >>﹆﹆﹆ >>_______________________________________________ >>Crosswalk-dev mailing list >>Crosswalk-dev@lists.crosswalk-project.org >>https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > > _______________________________________________ > Crosswalk-dev mailing list > Crosswalk-dev@lists.crosswalk-project.org > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
