SWE2008 ANDROID

PROGRAMMING
Module – 5
SOFTWARE METHODOLOGY
Introduction
• An Overview of the Mobile Development Process
• Choosing an appropriate software methodology
• Understanding how target devices dictate the functionality of your application
• Performing thorough, accurate, and ongoing feasibility analyses
• Mitigating the risks associated with preproduction devices
• Keeping track of device functionality through configuration management
• Designing a responsive, stable application on a memory-restrictive system
• Designing user interfaces for a variety of devices with different user experiences
• Testing the application thoroughly on the target devices
• Incorporating third-party requirements that affect where you can sell your
application
• Deploying and maintaining a mobile application
• Reviewing user feedback, crash reports, and ratings, and deploying timely
application updates
Choosing a Software Methodology
• Understanding the Dangers of Waterfall Approaches
• The short development cycle might tempt some to use a waterfall
approach, but developers should beware of the inflexibility that
comes with this choice
• Changes to target devices (especially preproduction models, though
sometimes shipping devices can have substantial software changes),
ongoing feasibility, and performance concerns and the need for
quality assurance (QA) to test early and often on the target devices
themselves
• Understanding the Value of Iteration
• Because of the speed at which mobile projects tend to progress,
iterative methods have been the most successful strategies adapted
to mobile development
Gathering Application Requirements
• Despite the relative simplicity of a mobile application’s feature set
compared to a traditional desktop application, requirements analyses
for a mobile application can be more complex
• The mobile user interface must be elegant and the application must
be fault tolerant, not to mention responsive in a resource-
constrained environment
• Having great variation in target platforms can make development
assumptions tricky
• It’s not unlike the differences Web developers might need to
accommodate when developing for different Web browsers
Determining Project Requirements
• Each approach has its benefits and its drawbacks.
• There are two main approaches they are
• The lowest common denominator method
• The customization method
• Taking Advantage of the Best of Both Methods
In truth, mobile development teams usually use a hybrid approach,
incorporating some aspects from both methods
Determining Project Requirements
• Developing Use Cases for Mobile Applications
• Incorporating Third-Party Requirements and Recommendations
Assessing Project Risks
• Mobile projects need to be aware of the outside influences that can
affect their project schedule
Identifying Target Devices
• Each device has different capabilities, a different user interface, and
unique limitations
• There’s a popular “killer” device you want to develop for
your initial target device (or class of devices) figured out. In the second
instance, you want to look at the available (and soon-to-be-available)
devices on the market and adjust your application specifications to
cover as many as is reasonably feasible
• You want to develop an application for maximum coverage
• In this case, your application would probably not be use ful for a
smartphone or tablet; on the other hand, if your application is more
general, such as a game, you should make every effort to determine
the different targets and types of devices your application will work
on, such as smartphones, phablets, tablets, and TV
• Understanding How Manufacturers and Operators Fit In
• Understanding How Devices Come and Go over Time
• Acquiring Target Devices
Determining the Feasibility of Application
Requirements
• Mobile developers are at the mercy of the device limitations, which
vary in terms of memory and processing power, screen type, and
platform version
• Android devices have some hardware flexibility, such as the ability to
use external storage devices such as SD cards
Understanding Quality Assurance Risks
Testing Early, Testing Often
Testing on the Device
Mitigating the Risk of Limited Real-World Testing Opportunities
Configuration Management Systems
• Choosing a Source Control System
• Mobile development considerations impose no surprise
requirements for source control systems
• Ability to keep track of source code (Java) and binaries (Android
packages and so on)
• Ability to keep track of application resources by device configuration
(graphics and so on)
• Integration with the developer’s chosen development environment
(the Android IDE, Android Studio, or Eclipse)
Implementing an Application Version System
That Works
• Developers should also make an early decision on a versioning
scheme that takes into account the device particulars and the
software build
• Mobile developers often combine the traditional versioning scheme
with the target device configuration or device class supported
Designing Mobile Applications
• Understanding Mobile Device Limitations
Applications are expected to be fast, responsive, and stable, but
developers must work with limited resources
Exploring Common Mobile Application Architectures
Mobile applications have traditionally come in two basic models:
standalone applications
Standalone applications are packaged with everything they require and
rely on the device to do all the heavy lifting. All processing is done
locally, in memory, and is subject to the limitations of the device
Network-driven applications
Network-driven applications provide a lightweight client on the device
but rely on the network (or the cloud) to provide a good portion of
their content and functionality
Designing for Extensibility and Maintenance

• Applications can be written with a fixed user interface and a fixed

feature set, but they need not be. Network-driven applications can
be more complex to design but offer flexibility for the long term
• Designing for Application Interoperability
• Mobile application designers should consider how they will interface
with other applications on the device, including other applications
written by the same developer
Developing Mobile Applications

• Mobile application implementation follows the same principles as

other platforms
• Write and compile the code.
• Run the application in the software emulator.
• Test and debug the application in the software emulator or test
device.
• Package and deploy the application to the target devices.
• Test and debug the application on the target devices.
• Incorporate changes from the team and repeat until the application is
complete
Testing Mobile Applications
• Testers face many challenges, including device fragmentation (many
devices, each with different features and handling real-world events
(device calls, loss of coverage). Gathering the devices needed for
testing can be costly and difficult
• Android SDK includes a number of useful tools for testing
applications on both the emulator and the device. There are many
opportunities for leveraging white-box testing
Supporting and Maintaining Mobile
Applications
• Even the simplest of applications likely requires some maintenance
and the occasional upgrade
• Carriers and operators generally serve as the front line of technical
support to end users
Track and Address Crashes Reported by Users
Google Play—the most popular way to distribute Android
applications—has built-in features enabling users to submit crash and
bug reports regarding an application
Testing Firmware Upgrades
Android handsets receive frequent (some say too frequent) firmware
upgrades. This means that the Android platform versions you initially
tested and supported become obsolete and the handsets on which
your application is installed can suddenly run new versions of the
Android firmware
Maintaining Adequate Application
Documentation
• Maintenance is often not performed by the same engineers who
developed the application in the first place
• Here, keeping adequate development and testing documentation,
including specifications and test scripts, is even more vital
Managing Live Server Changes
Always treat any live server and Web or cloud service with the care it
deserves
This means you need to appropriately time your backups and upgrades
Identifying Low-Risk Porting Opportunities

• You might discover that an application was originally developed for a

specific class of device, but now several popular devices are on the
market with similar specifications.
• Porting an existing application to these new devices is sometimes as
straightforward as generating a new build (with appropriate
versioning) and testing the application on the new devices.
Application Feature Selection
• When determining what features your application will support, make
sure to think about the costs versus the benefits of supporting a
particular feature
• Adding new features is always the easy part, but removing them from
your application is not. Once users become accustomed to a feature,
if that feature goes missing, your users may never use your
application again