Qt and mobile development have a long history. Qt's beginnings included early releases on Linux personal digital assistants in the late Nineties and at the turn of this century. Since then, it's been ported to a number of mobile environments, including the mobile variants of Linux that Nokia shipped such as MeeGo and Symbian. While Symbian and MeeGo came and went, Qt's acceptance of mobile platforms lives on, most recently with support for Android.
In this chapter, we will talk a little about writing mobile applications and then learn how to set up Qt Creator to write applications for Android. It's worth noting that while we will leverage everything you have learned about Qt development when developing a mobile application, we also need to understand how the environments that the mobile software runs on are different from traditional desktop and laptop environments as well as how to design those constraints. Once we understand these differences, writing software for mobile platforms such as Android with Qt is a matter of snapping your fingers!
We will cover the following topics in this chapter:
- A mobile software development primer
- Setting up Qt Creator for Android
- Supporting other mobile platforms
The key point to remember when developing software for any mobile platform, such as a cell phone or tablet, is that every resource is at a premium. The device is smaller, meaning:
- Your user will pay less attention to your application and use it for shorter periods of time
- The screen is smaller, so you can display less information on the display (don't be fooled by the high dot pitch of today's displays; reading a six-point font on a four-inch display is no fun, high pixel densities or not.)
- The processor and graphics processing unit are slower
- There's less RAM and less graphics memory
- There's less persistent storage for your application's data
- The network is slower, by as much as three orders of magnitude
Let's take a look at each of these in more detail.
Can you walk and chew gum at the same time? I can't, but many people walk, chew gum, and use their mobile devices at the same time (worse, some even drive while using their devices). It's very rare for an application on a cell phone or tablet to have 100 percent of the user's attention for more than a few minutes at a time. A good rule of thumb is the smaller the device, the more likely is the user bound to treat it as something to pick up and glance at, or use while they're doing something else.
The limited attention that your user gives to your application has three key consequences:
- Your application must be fast. Mobile devices are no place for extra progress bars, spinning cursors, or lengthy splash screens.
- Your application must be succinct. The best mobile applications show data only on a page or two, having very flat navigation hierarchies. A common structure is to have a single screen with information and a single screen with preferences that lets you configure what information should be shown (such as, the location for which you're getting the information). Favor clear iconography over verbose text—if you can't draw, find someone who can, or buy icons from a site such as The Noun Project (http://thenounproject.com/).
- Your application must be accessible. Buttons should be big (a good guideline is that no hit target in your application should be smaller than the pad of your finger, which is about a square centimeter), and text should be bigger, if possible.
For these reasons, Qt Quick is a better choice for most mobile applications that you'll write. You can create smooth, responsive applications that are visually pleasing and don't overwhelm your users.
Mobile devices must carry their power source with them: batteries. While batteries have improved over the last 20 years, they haven't kept up with Moore's Law; most of the improvements have been made on the processor side, as processors have become smaller and dissipate less heat in the course of a normal operation.
Nonetheless, mobile devices aren't as fast as desktops or laptops—a good way to think about it is that the last generation's processor design probably scales well for mobile devices today. That's not to say that mobile devices are slow, but just that they're slower. An equally important point to consider is that you can't run the processor or graphics processor at full tilt without seriously affecting the battery life.
Qt—especially Qt Quick—is optimized for low power consumption, but still there are things that you can do to help squeeze the best performance out of your mobile application:
- Don't poll: This is probably the single most important point. Use Qt's asynchronous signal-slot mechanism wherever possible, and consider multithreading using
QThreadand the rest of Qt's multithreading environment, if you need to do something in the background. The more your application sleeps, the more it prolongs the battery life. - Avoid gratuitous animations: Some amount of animation is both customary and important in today's applications; well-thought-out animations can help orient the user as to where they've come from in an application's user interface and where they're going. However, don't flash, blink, or otherwise animate just to see pixels move; under the hood, a lot has to take place to move those pixels, and this consumes battery.
- Use the network judiciously: Most mobile devices have at least two radios (cellular and Wi-Fi); some have more. Accessing the network should be seen as a necessary evil, because radios consume power when transmitting and receiving data. Also, don't forget data parsing: if you're parsing a lot of data, it's likely that you're running the CPU at full tilt to do the heavy lifting and that means a lower battery life.
You've already been warned about the high cost to the battery for using the network. To add insult to injury, most mobile devices run on networks that can be up to three orders of magnitude slower than a desktop; your office desktop might have a gigabit Ethernet, but in many parts of the world, a megabit a second is considered fast. This situation is rapidly improving as network operators deploy cellular wireless networks such as Long Term Evolution (LTE) and Wi-Fi hotspots everywhere, but these are by no means uniformly available. On a recent trip in California, in the course of eight hours, my cellular network connectivity throughput ran a gamut from faster than my cable modem (running at 25 megabits a second) down to the dreaded megabit per second which can make a large web page crawl.
For most applications, you should be fine with the Hyper Text Transfer Protocol (HTTP); Qt's QNetworkAccessManager class implements HTTP and HTTPS, and using HTTP means that you can build web services to support your backend in a standard way.
If you're developing a game or a custom application, you might need to build a custom protocol. Consider using QTcpSocket or QUdpSocket for your network protocol, keeping in mind of course that TCP is a reliable protocol. However, with UDP, there's no guarantee of your data reaching its destination; reliability is up to you.
Note
Something to make a special note of is error handling in networked applications; unlike a desktop, where network failures are likely to be rare because your computer is tethered to the network, wireless networks can suffer all sorts of transitory problems. These don't necessarily lead to logical failures; a short drop in network connectivity can result in Domain Name Service problems, Transport Layer Security timeouts, or retry timeouts. Handle errors in your application, and ensure that there are mechanisms to retry important network operations, such as data synchronization and content uploads. Be prepared for duplicate requests and uploads too, in the cases where your device uploads something to a server which doesn't get an acknowledgement from the server because of a network problem and tries again.
Mobile devices typically use all the solid-state memory. Although solid-state memory has come down in price significantly in the last several years, it's still not as cheap as the rotating magnetic memory that makes up the disk drives in most desktops and many laptops. As a result, mobile devices might have as little as 8 GB of flash memory for persistent storage, or if you're lucky, 16 or 32 GB. This is shared across the system and all the applications; your application shouldn't use more than a few gigabytes at most, and that's only if your user is expecting it, say for a podcast application. That should be the sum total of the size of your application: its static resources such as audio and video, and anything it might download and cache from the network.
An equally important point is that the runtime size of your application needs to be smaller. Most mobile devices have between a half-gigabyte and 2 GB of dynamic RAM available; the system shares this across all running applications, so it's important to allocate only what you need and free it when you're done.
Finally, don't forget that your graphics textures and things can eat valuable GPU memory as well. While Qt manages the GPU for you, whether you're using Qt or Qt Quick, you can write an application that consumes all of the device's texture memory, making it difficult or impossible for the native OS to render what it needs, if it needs to interrupt your application with another application or system message.
To paraphrase the immortal bard, that's the question. With Qt's incredible flexibility across numerous platforms, the temptation to grab an existing application and port it can be overwhelming, especially in the vertical markets where you have a piece of custom software written in Qt for the desktop and you have a customer who wants the same thing for the latest mobile device for their mobile workers. In general, the best advice I can offer you is to avoid porting UI and to only port the business logic in an application if it seems well-behaved for mobile devices.
UI ported from the desktop or a laptop environment seldom works well on mobile devices. The user's operating patterns are just too different: what a person wants to do while seated at a desktop or laptop is just not the same as what they want to—or can—do when they are standing up, walking around, or in brief spurts in a conference room, cafeteria, or café. If you're porting from one mobile device to another, it might not be so bad; for example, a developer with a Qt application for MeeGo, Nokia's Linux-based platform, shouldn't have too much problem bringing their application to Qt on Android, BlackBerry, or iOS.
Porting business logic might be a safer bet, assuming that it doesn't make heavy use of the CPU, network, or dynamic or static storage. Qt offers a wrapper for SQLite through QtSql, and many enterprise applications use that for local storage. This is a reasonable alternative for data storage, and most HTTP-based networking applications shouldn't be too hard on the network layer, as long as they have reasonable caching policies and don't make too many requests for data too often. However, if the application uses a lot of storage or has a persistent network connection, it's time to rearchitect and rewrite.
Testing any application is important, but mobile applications require an additional effort in testing, especially Android applications. There's a wide variety of devices in the market, and users expect your application to perform well on any device they might have.
The most important thing you can do is test your application on real devices—as many of them as you can get your hands on—if you're interested in releasing your application commercially. While the Android SDK used by Qt Creator comes with an emulator that can run your Android application on your desktop or laptop, running on an emulator is no substitute for running on the device. A lot of things are different, from the size of the hardware itself to having a touchscreen, and of course, the network connection and raw processing power.
Fortunately, Android devices aren't terribly expensive, and there are an awful lot of them around. If you're just starting out, eBay or the Google Play Store can be a good place to shop for an inexpensive used or new device. If you're a student or a budding entrepreneur, don't forget that many family members might have an Android device that you can borrow; or, you can use the Android cell phone that you already have.
When and what should you test? Often, and everything! In a multi-week project, you should never be more than a few days away from a build running on a device. The longer you spend in writing the code that you haven't tested on a device, the more assumptions you will make about how the device will perform, with most of those assumptions turning out wrong.
Be sure to not just test your application in good circumstances but in bad ones as well. Network connectivity is a prime example; you should test the error handling in cases with no network coverage. If you have a good network coverage where you're working, one trick you can use is to put the device in a metal cookie tin or paint can; the metal attenuates the signal and has the same effect as the signal being lost in the real world (say, in a tunnel or in the subway).