Home
Sitemap
Global Network
Android does a lot to simplify mobile-device software development, but it’s still important to understand the reasons behind the conventions. There are several factors to account for when writing software for mobile and embedded devices, and when developing for Android, in particular.
Hardware-Imposed Design Considerations
Small and portable, mobile devices offer exciting opportunities for software development. Their limited screen size and reduced memory, storage, and processor power are far less exciting, and instead presentsome unique challenges. Compared to desktop or notebook computers, mobile devices have relatively:
❑ Low processing power
❑ Limited RAM
❑ Limited permanent storage capacity
❑ Small screens with low resolution
❑ Higher costs associated with data transfer
❑ Slower data transfer rates with higher latency
❑ Less reliable data connections
❑ Limited battery life
It’s important to keep these restrictions in mind when creating new applications.
Be Efficient
Manufacturers of embedded devices, particularly mobile devices, value small size and long battery life over potential improvements in processor speed. For developers, that means losing the head start traditionally afforded thanks to Moore’s law. The yearly performance improvements you’ll see in desktop and server hardware usually translate into smaller, more power-effi cient mobiles without much improvement in processor power. In practice, this means that you always need to optimize your code so that it runs quickly and responsively, assuming that hardware improvements over the lifetime of your software are unlikely to do you any favors. Since code efficiency is a big topic in software engineering. Just note that efficiency is particularly important for resource-constrained environments like mobile devices.
Expect Limited Capacity
Advances in flash memory and solid-state disks have led to a dramatic increase in mobile-device storage capacities (although people’s MP3 collections tend to expand to fill the available space). In practice, most devices still offer relatively limited storage space for your applications. While the compiled size of your application is a consideration, more important is ensuring that your application is polite in its use of system resources. You should carefully consider how you store your application data. To make life easier, you can use the Android databases and Content Providers to persist, reuse, and share large quantities of data. For smaller data storage, such as preferences or state settings, Android provides an optimized framework. Of course, these mechanisms won’t stop you from writing directly to the file system when you want or need to, but in those circumstances, always consider how you’re structuring these files, and ensure that yours is an efficient solution.
Part of being polite is cleaning up after yourself. Techniques like caching are useful for limiting repetitive network lookups, but don’t leave files on the file system or records in a database when they’re no longer needed.
Design for Small Screens
The small size and portability of mobiles are a challenge for creating good interfaces, particularly when users are demanding an increasingly striking and information-rich graphical user experience. Write your applications knowing that users will often only glance at the (small) screen. Make your
applications intuitive and easy to use by reducing the number of controls and putting the most important information front and center. Graphical controls are an excellent way to convey dense information in an easy-to-understand way. Rather than a screen full of text with lots of buttons and text entry boxes, use colors, shapes, and graphics to display information. If you’re planning to include touch-screen support (and if you’re not, you should be), you’ll need to consider how touch input is going to affect your interface design. The time of the stylus has passed; now it’s all about finger input, so make sure your Views are big enough to support interaction using a fi nger on the screen. Of course, mobile-phone resolutions and screen sizes are increasing, so it’s smart to design for small screens, but also make sure your UIs scale.
Expect Low Speeds, High Latency
You’ll learn how to use Internet resources in your applications. The ability to incorporate some of the wealth of online information in your applications is incredibly powerful. The mobile Web unfortunately isn’t as fast, reliable, or readily available as we’d often like, so when you’re developing your Internet-based applications, it’s best to assume that the network connection will be slow, intermittent, and expensive. With unlimited 3G data plans and city-wide Wi-Fi, this is changing, but designing for the worst case ensures that you always deliver a high-standard user experience. This also means making sure that your applications can handle losing (or not finding) a data connection. The Android Emulator lets you control the speed and latency of your network connection when setting up an Eclipse launch configuration. Experiment to ensure responsiveness no matter what the speed, latency, and availability of network access. You might find that in some circumstances, it’s better to limit the functionality of your application or reduce network lookups to cached bursts, based on the network connection(s) available.
At What Cost?
If you’re a mobile owner, you know all too well that some of the more powerful features on your mobile can literally come at a price. Services like SMS, GPS, and data transfer often incur an additional tariff from your service provider. It’s obvious why it’s important that any costs associated with functionality in your applications are minimized, and that users are aware when an action they perform might result in them being charged. It’s a good approach to assume that there’s a cost associated with any action involving an interaction with the outside world. Minimize interaction costs by the following:
Hardware-Imposed Design Considerations
Small and portable, mobile devices offer exciting opportunities for software development. Their limited screen size and reduced memory, storage, and processor power are far less exciting, and instead presentsome unique challenges. Compared to desktop or notebook computers, mobile devices have relatively:
❑ Low processing power
❑ Limited RAM
❑ Limited permanent storage capacity
❑ Small screens with low resolution
❑ Higher costs associated with data transfer
❑ Slower data transfer rates with higher latency
❑ Less reliable data connections
❑ Limited battery life
It’s important to keep these restrictions in mind when creating new applications.
Be Efficient
Manufacturers of embedded devices, particularly mobile devices, value small size and long battery life over potential improvements in processor speed. For developers, that means losing the head start traditionally afforded thanks to Moore’s law. The yearly performance improvements you’ll see in desktop and server hardware usually translate into smaller, more power-effi cient mobiles without much improvement in processor power. In practice, this means that you always need to optimize your code so that it runs quickly and responsively, assuming that hardware improvements over the lifetime of your software are unlikely to do you any favors. Since code efficiency is a big topic in software engineering. Just note that efficiency is particularly important for resource-constrained environments like mobile devices.
Expect Limited Capacity
Advances in flash memory and solid-state disks have led to a dramatic increase in mobile-device storage capacities (although people’s MP3 collections tend to expand to fill the available space). In practice, most devices still offer relatively limited storage space for your applications. While the compiled size of your application is a consideration, more important is ensuring that your application is polite in its use of system resources. You should carefully consider how you store your application data. To make life easier, you can use the Android databases and Content Providers to persist, reuse, and share large quantities of data. For smaller data storage, such as preferences or state settings, Android provides an optimized framework. Of course, these mechanisms won’t stop you from writing directly to the file system when you want or need to, but in those circumstances, always consider how you’re structuring these files, and ensure that yours is an efficient solution.
Part of being polite is cleaning up after yourself. Techniques like caching are useful for limiting repetitive network lookups, but don’t leave files on the file system or records in a database when they’re no longer needed.
Design for Small Screens
The small size and portability of mobiles are a challenge for creating good interfaces, particularly when users are demanding an increasingly striking and information-rich graphical user experience. Write your applications knowing that users will often only glance at the (small) screen. Make your
applications intuitive and easy to use by reducing the number of controls and putting the most important information front and center. Graphical controls are an excellent way to convey dense information in an easy-to-understand way. Rather than a screen full of text with lots of buttons and text entry boxes, use colors, shapes, and graphics to display information. If you’re planning to include touch-screen support (and if you’re not, you should be), you’ll need to consider how touch input is going to affect your interface design. The time of the stylus has passed; now it’s all about finger input, so make sure your Views are big enough to support interaction using a fi nger on the screen. Of course, mobile-phone resolutions and screen sizes are increasing, so it’s smart to design for small screens, but also make sure your UIs scale.
Expect Low Speeds, High Latency
You’ll learn how to use Internet resources in your applications. The ability to incorporate some of the wealth of online information in your applications is incredibly powerful. The mobile Web unfortunately isn’t as fast, reliable, or readily available as we’d often like, so when you’re developing your Internet-based applications, it’s best to assume that the network connection will be slow, intermittent, and expensive. With unlimited 3G data plans and city-wide Wi-Fi, this is changing, but designing for the worst case ensures that you always deliver a high-standard user experience. This also means making sure that your applications can handle losing (or not finding) a data connection. The Android Emulator lets you control the speed and latency of your network connection when setting up an Eclipse launch configuration. Experiment to ensure responsiveness no matter what the speed, latency, and availability of network access. You might find that in some circumstances, it’s better to limit the functionality of your application or reduce network lookups to cached bursts, based on the network connection(s) available.
At What Cost?
If you’re a mobile owner, you know all too well that some of the more powerful features on your mobile can literally come at a price. Services like SMS, GPS, and data transfer often incur an additional tariff from your service provider. It’s obvious why it’s important that any costs associated with functionality in your applications are minimized, and that users are aware when an action they perform might result in them being charged. It’s a good approach to assume that there’s a cost associated with any action involving an interaction with the outside world. Minimize interaction costs by the following:
❑ Transferring as little data as possible
❑ Caching data and GPS results to eliminate redundant or repetitive lookups
❑ Stopping all data transfers and GPS updates when your activity is not visible in the foreground if they’re only being used to update the UI
❑ Keeping the refresh/update rates for data transfers (and location lookups) as low as practicable
❑ Scheduling big updates or transfers at “off peak” times using alarms.
Often the best solution is to use a lower-quality option that comes at a lower cost. When using the location-based services, you can select a location provider based on whether there is an associated cost. Within your location-based applications, consider giving users the choice of lower cost or greater accuracy. In some circumstances, costs are hard to defi ne, or they’re different for different users. Charges for services vary between service providers and user plans. While some people will have free unlimited data transfers, others will have free SMS. Rather than enforcing a particular technique based on which seems cheaper, consider letting your users choose. For example, when downloading data from the Internet, you could ask users if they want to use any network available or limit their transfers to only when they’re connected via Wi-Fi.
Considering the Users’ Environment
You can’t assume that your users will think of your application as the most important feature of their
phones. Generally, a mobile is first and foremost a phone, secondly an SMS and e-mail communicator, thirdly a camera, and fourthly an MP3 player. The applications you write will most likely be in a fifth category of “useful mobile tools.” That’s not a bad thing — it’s in good company with others including Google Maps and the web browser. That said, each user’s usage model will be different; some people will never use their mobiles to listen to music, and some phones don’t include a camera, but the multitasking principle inherent in a device as ubiquitous as it is indispensable is an important consideration for usability design. It’s also important to consider when and how your users will use your applications. People use their mobiles all the time — on the train, walking down the street, or even while driving their cars. You can’t make people use their phones appropriately, but you can make sure that your applications don’t distract them any more than necessary.
What does this mean in terms of software design?. Make sure that your application:
❑ Is well behaved.
❑ Switches seamlessly from the background to the foreground.
❑ Is polite Your application should never steal focus or interrupt a user’s current activity.
❑ Presents a consistent user interface.
❑ Is responsive.