diff options
Diffstat (limited to 'doc/src/howtos')
| -rw-r--r-- | doc/src/howtos/developmentsteps.qdoc | 186 | ||||
| -rw-r--r-- | doc/src/howtos/scalabilityintro.qdoc | 55 |
2 files changed, 214 insertions, 27 deletions
diff --git a/doc/src/howtos/developmentsteps.qdoc b/doc/src/howtos/developmentsteps.qdoc new file mode 100644 index 0000000..e898bf5 --- /dev/null +++ b/doc/src/howtos/developmentsteps.qdoc @@ -0,0 +1,186 @@ +/**************************************************************************** +** +** Copyright (C) 2011 Nokia Corporation and/or its subsidiary(-ies). +** All rights reserved. +** Contact: Nokia Corporation (qt-info@nokia.com) +** +** This file is part of the documentation of the Qt Toolkit. +** +** $QT_BEGIN_LICENSE:FDL$ +** No Commercial Usage +** This file contains pre-release code and may not be distributed. +** You may use this file in accordance with the terms and conditions +** contained in the Technology Preview License Agreement accompanying +** this package. +** +** GNU Free Documentation License +** Alternatively, this file may be used under the terms of the GNU Free +** Documentation License version 1.3 as published by the Free Software +** Foundation and appearing in the file included in the packaging of this +** file. +** +** If you have questions regarding the use of this file, please contact +** Nokia at qt-info@nokia.com. +** $QT_END_LICENSE$ +** +****************************************************************************/ +/*! +\page qtdevelopment-steps.html +\title Qt Development: The Steps from Challenge to Achievement + +\section1 The Challenge + +One day, your boss runs into your cubicle and exclaims to you, "The board blew +millions on a new enterprise HelloWorld application. The new one does not work +and we need a solution quickly before this disaster brings down the company! I'm +putting you in charge of the whole project while I go on vacation -- see you in +2 weeks." + +\section1 Brainstorming Ideas - It is time to play! + +Never one to shy away from a challenge (especially when your job might be on the +line), you first set out try come up with an idea about what your options are. + +You ask around a bit and discover that the broken application was intended to +replace one that has been living on a dusty mainframe for the past 25 years. The +machine is nearing end of life and, rather than invest in replacement hardware +to run a legacy HelloWorld program, the board decided to invest in new software +that could be run on desktops, web, mobile devices and embedded into the +company's main product line -- a pocket size device with a small LCD screen, +which flashes the message "Hello World" every full moon. + +The vendor that was chosen to handle this task was a well known multinational +company that specialized in enterprise CRM/ERP systems. The project missed +several delivery deadlines over a 2 year period, and was 500% over budget. There +was not going to be much margin for error trying to fix the problem, and there +would likely be no budget either. + +You begin researching dozens of possible possible approaches to the problem. One +of the biggest challenges is that there are very few options that will allow you +to create native applications that use the same framework for targeting +\l{qt-creator-configure-target}{multiple platforms}. + +Some years ago you had coded a small desktop application using the Qt framework, +without realizing that it also can be used for targeting the web, mobile devices +and embedded devices. Since that time, Qt has added a new feature called \l{Qt +Quick}, which provides the ability to easily design applications with intuitive, +modern-looking, fluid user interfaces. + +\section1 Creating an Objective + +You quickly realize that you might need two, three, or more interfaces for your +application -- one for each of the target platforms you are aiming for. +Thankfully Qt has options well suited for each of them. + +For your mobile application the choice seems obvious enough. The new Qt Quick +technology looks very promising, but you do not know QML; the declarative +language that helps define the interface in a Qt Quick program. You still want +to give it a try, but worry that you might not have something complete before +your boss returns from vacation in two weeks. You also wonder if Qt Quick is +applicable to desktop and embedded targets -- and then of course there is the +need for something targeting the web. You decide to give Qt Quick a try first +and \l{QML Examples and Demos}{see where it takes you}. + +\section1 Developing Plans + +One thing you realize after reading up on \l{Qt Quick} is that things are very +different from the desktop when designing an interface. Qt Quick doesn't contain +ready made UI 'chrome'; the widgets and other design elements that define the +application interface. A new technology, called Qt Quick Components, looks like +a promising solution, but the components will only be available at a later date. +For now you'll have to come up with something on your own -- but you are keen to +give your design skills a work out, and learning to use Qt Quick seems to be a +great way to do it. + +Not knowing a better place to start, you begin by taking a cue from web design +and plan a wireframe, which helps +\l{http://doc.qt.nokia.com/qtcreator-snapshot/creator-visual-editor.html}{define the application layout}, +content and user interaction. You decide on breaking the field of the screen +space into three roughly equal size parts. There will be one section across the +top, which will span the width of the screen, and two sections in the lower +have, which will be approximately as tall as the top section is wide (when in +portrait mode). + +The top section will be a simple text representation of the phrase "Hello World" +in English. In the lower left you would like to place some kind of audio +playback feature that repeats back the phrase in the top section of the screen. +Finally, in the lower right hand side of the screen will be four links to +similar views for additional languages -- Mandarin Chinese, Brazilian +Portuguese, Arabic, and Russian. When the user clicks one of the links the text +at the top is then translated, and the playback corresponds to the appropriate +language. + +While the wireframe is effective in dealing with one part of the design +challenge, it does not cover visual aspects other than layout and content. This +means that you still need to define colours, white space, and typography (among +other things). This is where a style guide would come in handy, if your company +already had one that is. In the absence of one you decide to again get some +inspiration from the web, and you mimic some of the company's website design +into your application -- a sans-serif font for white text on a blue field across +the top, black text on white for the bottom two sections, and a small company +logo to the left of the "Hello World" message. + + +\section1 Execution: The Coding Begins! + +At long last you sit down to \l{qt-technologies}{implement} your plans and +designs. The first few steps go according to plan, and creating the basic layout +and text goes fairly smoothly -- but you run into a few challenges quite +quickly: + +Devising a user friendly interface to audio playback is not as intuitive as you +first thought. Since there exist a ready made component for +\l{http://doc.qt.nokia.com/qtmobility-1.1.0/qml-multimedia.html}{multimedia}, +you remove the bottom left field and now have the screen split in two. You add +textual links for each of the five target languages, and when the user clicks +one of them the message text changes and the appropriate audio plays back. It is +a small sacrifice to make for now, and you are sure there is a solution to be +found once you have become more proficient with QML. + +The next challenge you run into is that \l{qt-deployment}{deploying} the +application to a Symbian phone is not as clearly understood as you expected. +Again you are sure there is something you are missing, but for the time being +you manually copy the .sis file to the "Installs" directory on the phone +(connected to the development machine by USB) and then install it through the +Application Manager. + +When you finally manage to install the application on the device you notice +something that looks rather peculiar, and something you had not thought of. When +the phone is turned into landscape mode, your text remains at the same absolute +coordinates as when it was in portrait mode. You had not realized you needed to +anchor it in order to achieve the centering you wanted. There was an +\l{qt-testing}{easy fix} for this, but you were glad you saw this earlier rather +than later. + + +\section1 Innovating + +After the ups and downs of learning to develop a basic application +using Qt Quick, you start to see greater possibilities for using Qt technologies +for your current and future projects: + +\list +\o Extending HTML5 based applications that tie Javascript to a Qt C++ back end +using \l{Qt WebKit} +\o An \l{qt-rendering-painting-system}{OpenGL} based UI for embedded platforms +\o \l{Gestures Programming}{Touch} screen support +\o \l{http://doc.qt.nokia.com/qtmobility-1.1.0/location-overview.html}{Location} based applications +\o \l{qt-technologies}{Much, much more} +\endlist + + +\section1 The Achievement + +After your boss returned from vacation you presented him with the finished Qt +Quick application, demonstrating it on both a mobile device as well as desktop +(it happened to work well on both with little modification). You also provided +him a presentation that detailed your road map for taking things to the next +level -- targeting other platforms, such as the web, as well as improving on the +existing application you just completed. + +Even though the final product did not turn out the way you originally planned, +your boss was still sufficiently impressed. Not only was the go ahead given for +future projects, but ramping up a small team of developers and designers was +also suggested to help support your efforts. + +*/ diff --git a/doc/src/howtos/scalabilityintro.qdoc b/doc/src/howtos/scalabilityintro.qdoc index d9c5658..66c7bb7 100644 --- a/doc/src/howtos/scalabilityintro.qdoc +++ b/doc/src/howtos/scalabilityintro.qdoc @@ -28,6 +28,7 @@ /*! \title Scalability \page scalability.html + \preliminary \omit preliminary docs for next SDK release \endomit \omit Somewhere I need to mention applications with more than @@ -69,15 +70,19 @@ Using small top-level layouts makes your codebase smaller and easier to maintain. Also, components that scales relative to their parent are more reusable. The layouts should be children of the - applications root item. You can change between them by, for + application's root item. You can change between them by, for instance, using the opacity property of Item; that is, if your - application has more tham one top-level layout. + application has more tham one top-level layout. Such a top-level + layout is also often referred to as a page, i.e., a layout that + uses the entire screen. For instance, an organizer application + will typically have separate pages for showing the calender and + editing todo items. You should define the measurements separate from the UI, for instance by using a JavaScript object that you fill in with a script on application start up. - QML's provides several ways of laying out components, e.g, using + QML provides several ways of laying out components, e.g, using anchor based layout, the more classic Grid; Column; and Row elements, and by setting the dimensions of Items directly. When laying out components in scalable applications, you should @@ -101,10 +106,10 @@ common components and attributes, and will most likely connect to the same data model. - Therefore, the top level definitions should be quite + Therefore, the top-level definitions should be quite straightforward and short, with the majority of the functionality refactored into contained Components. It is important to try to - avoid unnecessary duplication between these top level definitions, + avoid unnecessary duplication between these top-level definitions, in order to improve maintainability. There are some patterns that you might consider when designing @@ -127,11 +132,12 @@ definition, if defined appropriately using anchors. \endlist - The Loader component can be used to load separate QML files based - on some criteria, such as Device Profile resolution. In the case - of form factor, this information will not change during the - application's lifetime, therefore there is no issue with memory - usage or performance. + The \l{Loader} component can be used to load separate QML files + based on some criteria, such as Device Profile (configuration of + screen pixel resolution and DPI density). In the case of form + factor, this information will not change during the application's + lifetime, therefore there is no issue with memory usage or + performance. \section1 Defining Measurements @@ -139,14 +145,11 @@ component layout, there are a number aspects to consider: \list - \o The layout structure, the high level relationship between + \o The layout structure, the high-level relationship between items. Which item is the parent? How are the items arranged relatively on the screen? Are they in a grid or column? \o The layout measurements. How big is an item, or a margin inside the edge of an item, or an anchor between items? - \o The constraints imposed by the container. This might be - ApplicationWindow contents in the case of a Page, or it may - be some other container in the case of a Button. \o The implicit size of contained items. Some child items will require a certain amount of space, such as a button containing a text. That may also depend on the current @@ -188,7 +191,7 @@ \section1 Using QML's Layout Features - For a given form factor, top level Layouts structure definitions, + For a given form factor, top-level Layouts structure definitions, or component layout structure definitions, should in general be defined in a proportional way using a combination of @@ -232,7 +235,7 @@ \section1 Orientation Switches - Application top level page definitions, and reusable component + Application top-level page definitions, and reusable component definitions, should use one QML layout definition for the layout structure. This single definition should include the layout design for separate Device Orientations and Aspect Ratios. The reason for @@ -242,13 +245,13 @@ orientation changes. On the contrary, you should perform thorough tests if you choose - to use a Loader to load additional QML that is needed in separate + to use a \l{Loader} to load additional QML that is needed in separate orientations, as this will affect the performance of the orientation change. In order to enable layout animations between the orientations, the anchor definitions must reside within the same containing - component. Therefore the structure of an page or a component + component. Therefore the structure of a page or a component should consist of a common set of child components, a common set of anchor definitions, and a collection of states (defined in a StateGroup) representing the different aspect ratios supported by @@ -256,7 +259,7 @@ are not possible on Symbian due to compatibility support for S60 applications). - If a component, contained within a Page element, needs to be + If a component contained within a page needs to be hosted in numerous different form factor definitions, then the layout states of the view should depend on the aspect ratio of the page (its immediate container). Similarly, different instances of @@ -264,11 +267,9 @@ in a UI, and so its layout states should be determined by the aspect ratio of its parent. The conclusion is that layout states should always follow the aspect ratio of the direct container (not - the "orientation" of the current device screen). The only - exception to this is of course the top level Window definition, - which is handled by the framework. + the "orientation" of the current device screen). - Within each layout State, you should define the relationships + Within each layout \l{State}, you should define the relationships between items using native QML layout definitions. See below for more information. During transitions between the states (triggered by the top level orientation change), in the case of anchor @@ -284,7 +285,7 @@ \list \o What if you have a single page that looks completely different between landscape and portrait, i.e. all of the - child items are different? For each Page, have two child + child items are different? For each page, have two child components, with separate layout definitions, and make one or other of the items have zero opacity in each state. You can use a cross-fade animation by simply applying a @@ -309,15 +310,15 @@ handler in this case, to ensure that the list item delegate has been constructed before the value is set. \o What if the two orientations take up too much memory to have - them both in memory at once? Use a Loader if necessary, if + them both in memory at once? Use a \l{Loader} if necessary, if you cannot keep both versions of the view in memory at once, but beware performance on the cross-fade animation during layout switch. One solution could be to have two "splash screen" items that are children of the Page, then you cross fade between those during rotation. Then you can use a - Loader to load another child component that loads the actual + \l{Loader} to load another child component that loads the actual model data to another child Item, and cross-fade to that - when the Loader has completed. + when the \l{Loader} has completed. \endlist */ |