Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.
Talk:Implementing custom orientation changes animation with QML
Ieatlint - Don't use any QSensor to detect orientation changes for UI
This article is wholly wrong. It will lead to additional power consumption by activating a sensor that is unneeded, and lead to unexpected behaviour, especially on devices with slide-out keyboards.
Why this is wrong:
- As noted in QOrientationReading documentation: "The orientation sensor reports the orientation of the device. As it operates below the UI level it does not report on or even know how the UI is rotated. Most importantly this means that this sensor cannot be used to detect if a device is in portrait or landscape mode." As an example, on an E7, if the keyboard is out, the device locks the UI to landscape. Turning the device towards it's side will cause your application to believe it is then in portrait, but the phone will actually stay in landscape mode, making your application reformat its layout to an unusable state.
- The phone will rotate its UI independent of you updating your layout. This will result in a delay between the phone's UI rotation and your app updating. Additionally, it will result in the layout being resettled twice -- once because the phone will put a resizeEvent() to all your widgets as it rotates your UI, and then a second time when you update your layout. On slower phones and/or larger applications, this can be especially problematic.
- It requires additional permissions to access the sensors on Symbian ("ReadDeviceData"), which doesn't require extra signing steps, but it does require the user allow the application more access than it should require.
- It requires QtMobility, which is an unnecessary library that could slow down application launch and increase RAM usage.
So what's the proper way to do this? In the example above, you would need to create a new class inheriting QDeclarativeView. Add an event handler for resizeEvent(). In the event handler, test if the widget width exceeds the widget height. If it does, you're in landscape, otherwise you're in portrait. Send signals to the QML as needed here. I would recommend adding a variable to track what your current orientation is, and only causing a layout update if it changes -- sometimes you'll get a resize event that doesn't require you alter your layout, and you're wasting resources and it may be visible to the user.This method will always keep your application in sync with what the phone's UI orientation is. It require no additional libraries, Symbian capabilities, or sensor readings. I've used this in Symbian and Maemo 5 with both widget-based UIs and QML..
22:54, 18 July 2011 (EEST)
Forum Nokia KB - Known Issues Board 110901Article needs further review. Re-evaluate in next KIBo.
09:59, 1 September 2011 (EEST)
Kratsan - Reply to Don't use any QSensor to detect orientation changes for UI
This article was written to implement orientation change with nice animations, the most important point of the article was to remove the black screen that the Symbian OS does between the orientation change.
To achieve this behavior these two steps are required:
- The application is locked to portrait so that orientation is no longer changed by the underlying platform, we get rid of black screen
- The QDeclarativeView's resizeEvent cannot be used as the view size does not change, instead the orientation must be detected by using the sensors and the orientation information must be delivered for the UI, this leads to requirement of the ReadDeviceData capability and use of QtMobility
The detection of the HW keyboard of E7 is lacking in this snippet and some code should be added to detect and inform the UI accordingly.I think nowadays Qt code could be moved to QML code, because the QtMobility bindings are available. The QML OrientationSensor http://doc.qt.nokia.com/qtmobility-1.2/qml-sensors.html should give all the required information.
10:21, 1 September 2011 (EEST)
Korva - Solution in Qt Components
For everyone seeking guidance from here (this entry is pretty high on google search):
You can use the Window component from the new Qt Quick Components to very easily take care of orientation detection. If you use Window as the parent element, just query the inPortrait property. It handles the E7 keyboard open -scenario correctly. Documentation: http://doc.qt.nokia.com/qt-components-symbian-1.0/qml-window.htmlTaking Qt Quick components into use: http://doc.qt.nokia.com/qt-components-symbian-1.0/index.html
13:02, 29 September 2011 (EEST)
Hamishwillee - Added ArticleNeedsUpdate template
Hi Korva, Kratsan
Korva, thanks for the comment. I agree. I've added the ArticleNeedsUpdate template with this information so that people see it "up front".
Kratsan, would it be possible for you to re-write this article with the new mechanisms in mind? Or to create a new one? BTW, thanks for this article, very helpful prior to proper mechanisms being created.
03:09, 5 October 2011 (EEST)
Tomi - The Times They Are a-Changin'
I feel that the animated orientation change using Qt Quick Components is too small of a subject to require a new article. As for this article, I'd suggest archive or remove.
17:00, 23 February 2012 (EET)
Hamishwillee - Kind of, but this article is accurate
Hi Tomi, Ieatlint
After discussion with the author I concluded that the article is accurate but was/is subject to mis-interpretation.
The right/normal way to do transition animations is to use the standard animations you get from Qt Quick Components and follow the various other instructions in the doc about orientation and scalability. You can also use the Window Element if you need to do any processing before or after a transition.
This article is for the small subset of cases where the normal transitions are NOT sufficient. This is IMO a valid use case to document, as long as its made clear this is not the "standard" way.
I have updated the overview appropriately. I have renamed to make it clear this is "Custom". Feel free to review or update the article overview more if you think I haven't been sufficiently clear.
regards HamishPS I plan to remove these comments in a couple of days.
04:13, 27 February 2012 (EET)