Long live Qt 4.5!

1 files changed, 230 insertions, 0 deletions

diff --git a/doc/src/examples/blockingfortuneclient.qdoc b/doc/src/examples/blockingfortuneclient.qdoc
new file mode 100644
index 0000000..5c9dbe1
--- /dev/null
+++ b/doc/src/examples/blockingfortuneclient.qdoc
@@ -0,0 +1,230 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Qt Software Information (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** 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 either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at qt-sales@nokia.com.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/*!
+    \example network/blockingfortuneclient
+    \title Blocking Fortune Client Example
+
+    The Blocking Fortune Client example shows how to create a client for a
+    network service using QTcpSocket's synchronous API in a non-GUI thread.
+
+    \image blockingfortuneclient-example.png
+
+    QTcpSocket supports two general approaches to network programming:
+
+    \list
+
+    \o \e{The asynchronous (non-blocking) approach.} Operations are scheduled
+    and performed when control returns to Qt's event loop. When the operation
+    is finished, QTcpSocket emits a signal. For example,
+    QTcpSocket::connectToHost() returns immediately, and when the connection
+    has been established, QTcpSocket emits
+    \l{QTcpSocket::connected()}{connected()}.
+    
+    \o \e{The synchronous (blocking) approach.} In non-GUI and multithreaded
+    applications, you can call the \c waitFor...() functions (e.g.,
+    QTcpSocket::waitForConnected()) to suspend the calling thread until the
+    operation has completed, instead of connecting to signals.
+
+    \endlist
+
+    The implementation is very similar to the
+    \l{network/fortuneclient}{Fortune Client} example, but instead of having
+    QTcpSocket as a member of the main class, doing asynchronous networking in
+    the main thread, we will do all network operations in a separate thread
+    and use QTcpSocket's blocking API.
+
+    The purpose of this example is to demonstrate a pattern that you can use
+    to simplify your networking code, without losing responsiveness in your
+    user interface.  Use of Qt's blocking network API often leads to
+    simpler code, but because of its blocking behavior, it should only be used
+    in non-GUI threads to prevent the user interface from freezing. But
+    contrary to what many think, using threads with QThread does not
+    necessarily add unmanagable complexity to your application.
+
+    We will start with the FortuneThread class, which handles the network
+    code.
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.h 0
+
+    FortuneThread is a QThread subclass that provides an API for scheduling
+    requests for fortunes, and it has signals for delivering fortunes and
+    reporting errors. You can call requestNewFortune() to request a new
+    fortune, and the result is delivered by the newFortune() signal. If any
+    error occurs, the error() signal is emitted.
+
+    It's important to notice that requestNewFortune() is called from the main,
+    GUI thread, but the host name and port values it stores will be accessed
+    from FortuneThread's thread. Because we will be reading and writing
+    FortuneThread's data members from different threads concurrently, we use
+    QMutex to synchronize access.
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 2
+
+    The requestNewFortune() function stores the host name and port of the
+    fortune server as member data, and we lock the mutex with QMutexLocker to
+    protect this data. We then start the thread, unless it is already
+    running. We will come back to the QWaitCondition::wakeOne() call later.
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 4
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 5
+
+    In the run() function, we start by acquiring the mutex lock, fetching the
+    host name and port from the member data, and then releasing the lock
+    again. The case that we are protecting ourselves against is that \c
+    requestNewFortune() could be called at the same time as we are fetching
+    this data. QString is \l reentrant but \e not \l{thread-safe}, and we must
+    also avoid the unlikely risk of reading the host name from one request,
+    and port of another. And as you might have guessed, FortuneThread can only
+    handle one request at a time.
+
+    The run() function now enters a loop:
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 6
+
+    The loop will continue requesting fortunes for as long as \e quit is
+    false. We start our first request by creating a QTcpSocket on the stack,
+    and then we call \l{QTcpSocket::connectToHost()}{connectToHost()}. This
+    starts an asynchronous operation which, after control returns to Qt's
+    event loop, will cause QTcpSocket to emit
+    \l{QTcpSocket::connected()}{connected()} or
+    \l{QTcpSocket::error()}{error()}.
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 8
+
+    But since we are running in a non-GUI thread, we do not have to worry
+    about blocking the user interface. So instead of entering an event loop,
+    we simply call QTcpSocket::waitForConnected(). This function will wait,
+    blocking the calling thread, until QTcpSocket emits connected() or an
+    error occurs. If connected() is emitted, the function returns true; if the
+    connection failed or timed out (which in this example happens after 5
+    seconds), false is returned. QTcpSocket::waitForConnected(), like the
+    other \c waitFor...() functions, is part of QTcpSocket's \e{blocking
+    API}.
+
+    After this statement, we have a connected socket to work with. Now it's
+    time to see what the fortune server has sent us.
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 9
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 10
+
+    This step is to read the size of the packet. Although we are only reading
+    two bytes here, and the \c while loop may seem to overdo it, we present this
+    code to demonstrate a good pattern for waiting for data using
+    QTcpSocket::waitForReadyRead(). It goes like this: For as long as we still
+    need more data, we call waitForReadyRead(). If it returns false,
+    we abort the operation. After this statement, we know that we have received
+    enough data.
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 11
+
+    Now we can create a QDataStream object, passing the socket to
+    QDataStream's constructor, and as in the other client examples we set
+    the stream protocol version to QDataStream::Qt_4_0, and read the size
+    of the packet.
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 12
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 13
+
+    Again, we'll use a loop that waits for more data by calling
+    QTcpSocket::waitForReadyRead(). In this loop, we're waiting until
+    QTcpSocket::bytesAvailable() returns the full packet size.
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 14
+
+    Now that we have all the data that we need, we can use QDataStream to
+    read the fortune string from the packet. The resulting fortune is
+    delivered by emitting newFortune().
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 15
+
+    The final part of our loop is that we acquire the mutex so that we can
+    safely read from our member data. We then let the thread go to sleep by
+    calling QWaitCondition::wait(). At this point, we can go back to
+    requestNewFortune() and look closed at the call to wakeOne():
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 1
+    \dots
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 3
+
+    What happened here was that because the thread falls asleep waiting for a
+    new request, we needed to wake it up again when a new request
+    arrives. QWaitCondition is often used in threads to signal a wakeup call
+    like this.
+
+    \snippet examples/network/blockingfortuneclient/fortunethread.cpp 0
+
+    Finishing off the FortuneThread walkthrough, this is the destructor that
+    sets \e quit to true, wakes up the thread and waits for the thread to exit
+    before returning. This lets the \c while loop in run() will finish its current
+    iteration. When run() returns, the thread will terminate and be destroyed.
+
+    Now for the BlockingClient class:
+
+    \snippet examples/network/blockingfortuneclient/blockingclient.h 0
+
+    BlockingClient is very similar to the Client class in the
+    \l{network/fortuneclient}{Fortune Client} example, but in this class
+    we store a FortuneThread member instead of a pointer to a QTcpSocket.
+    When the user clicks the "Get Fortune" button, the same slot is called,
+    but its implementation is slightly different:
+
+    \snippet examples/network/blockingfortuneclient/blockingclient.cpp 0
+    \snippet examples/network/blockingfortuneclient/blockingclient.cpp 1
+
+    We connect our FortuneThread's two signals newFortune() and error() (which
+    are somewhat similar to QTcpSocket::readyRead() and QTcpSocket::error() in
+    the previous example) to requestNewFortune() and displayError().
+
+    \snippet examples/network/blockingfortuneclient/blockingclient.cpp 2
+
+    The requestNewFortune() slot calls FortuneThread::requestNewFortune(),
+    which \e shedules the request. When the thread has received a new fortune
+    and emits newFortune(), our showFortune() slot is called:
+
+    \snippet examples/network/blockingfortuneclient/blockingclient.cpp 3
+    \codeline
+    \snippet examples/network/blockingfortuneclient/blockingclient.cpp 4
+    
+    Here, we simply display the fortune we received as the argument.
+
+    \sa {Fortune Client Example}, {Fortune Server Example}
+*/