Skip to main content

7 Key Android Concepts

Image
By

 



Although the Android platform is open and customizable, Android users have become accustomed to constructs developed by Google for Android devices.


Although the Android platform is open and customizable, Android users have become accustomed to constructs developed by Google for Android devices. Moreover, the use of these Android concepts is vital in developing an application quickly – custom Android designs can take up to 10 times longer!

Android UI Controls

Android provides a number of standard UI controls that enable a rich user experience. Designers and developers should thoroughly understand all of these controls for the following reasons:

  • They are faster to implement. It can take up to ten times longer to develop a custom control than to implement a user interface with standard Android controls.
  • They ensure good performance. Custom controls rarely function as expected in their first implementation. By implementing standard controls, you can eliminate the need to test, revise and improve custom controls. Moreover, while designers will spend a great deal of time thinking about how a control should look, they may not always consider the many ways in which a custom control will behave in the user’s hands. Items on a mobile device often need to grow and shrink in size as they are pinched, or scroll if they are part of a list. As a result, creating a “clean” custom control from scratch can take a significant amount of design and development time. Google, however, has already thought about these interactions and developed standard controls to properly address them.
  • Android users expect standard controls. Through their interactions with other Android apps, users become accustomed to Android’s standard controls. Deviating from the standard Android user experience can confuse and frustrate users, making them less likely to want to use your app and incorporate it into their daily activities.

With a solid awareness of Android’s standard controls, designers and developers can speed app development while offering users an intuitive experience that feels instantly familiar.

Activities

Android applications are composed of “activities” which are unique, focused actions a user can take. Because it can be difficult or time-consuming to scroll, zoom in, or click links on a small screen, it is recommended that an app display only one activity per screen. This practice presents the user with only the most relevant information and allows them to launch a new screen for additional information, or click the “back” button to view the previous activity. While a screen can expose multiple tasks, it should help the user complete just one activity at a time.

In Gmail for example, a user can only read the body of an e-mail (right) once he has clicked the relevant message (left). This layout reduces the amount of information displayed on each screen and allows the user to easily navigate between the Inbox and the message text.

User Interactions

When a user first downloads your application, he will make snap judgments on the usability and intuitiveness of the application within the first few minutes of use. It is, therefore, crucial to balance the creativity of your app with the standard user interactions Android users have come to expect. These include:

  • Hard buttons: including Back, Menu, Home and Search buttons. Soft buttons that duplicate these features will only confuse or frustrate Android users. Moreover, back button behavior can be tricky and needs to be defined up-front for every screen, as it is not always as simple as returning to the previous activities. Most mobile phones, for example, offer both an “incoming call” activity and an “active call” activity. Once a user has answered and completed the call, the user would not expect to return to the “incoming call” activity upon pressing the “back” button, but rather to the activity that occurred before the incoming call. If the app offers only one activity, the back button should return the user to the device’s home page.
  • Long press elements: Items of a list can be long pressed to open a context menu that provides secondary information. “ToDo” list apps, for example, often use a touch interaction to mark a task as completed and a long press interaction to display a menu with “edit” or “delete” functionality.

Layouts

Android UI screens are frequently resized, both on the fly via pinch and zoom as well as at startup when Android adjusts the size of the UI to fit the screen size of the mobile device on which it’s running. In order to make the most of the screen size and handle this resizing gracefully, Android provides a number of screen layout options.

First, Android developers must specify whether each screen should follow a linear layout which manages controls in a horizontal or vertical fashion or a relative layout which manages controls in relation to one another. Linear layouts are the most common, as in the example below. At left, the controls only stretch to accommodate the text and are positioned in a horizontal line. In the middle image, the same rules apply but in a vertical layout. At right, the vertical layout is maintained but the middle button stretches to accommodate the screen rather than the text.

A relative layout defines the position of controls by their relationship to other components on the same screen. In the example below from the droidcake.com blog, the “OK” button was specified to be set below the radio button group. The “Cancel” button was specified to be set to the right of the OK button with its right edge extended to the edge of the screen. This relative layout positioning ensures the position of the buttons remains constant across a variety of screen sizes.

Android also offers specific layout properties to control the way in which screen elements are displayed across Android devices and during use:

  • Weight: The weight property allows the developer to determine how free space is divided on the screen.
  • Gravity: Gravity is the term used for control alignment (right, bottom, top, or left) on an Android device.
  • Density independence: Your application achieves “density independence” when it preserves the physical size (from the user’s point of view) of user interface elements displayed on screens with different densities. Without density independence, a UI element (such as a button) will appear larger on a low-density screen and smaller on a high-density screen.

So who specifies all of these properties?

If an Android application is designed in a vacuum and then “thrown over the wall” to the development team, you must rely on the developers’ interpretation of the design which may vary significantly from the original intent. On the other hand, the development team shouldn’t be expecting the designer to specify the weight, gravity and other layout properties of each screen and control.

In our experience, the best practice is to have the designer document the layout and resize behavior of each screen to the development team via a series of wireframes, if not a full style guide. The designer should then stay in close communication with the development team as the developers work to determine the right combination of Android layout properties to realize the design.

Screen Size

A common misconception is that an Android app should be designed to support only a specific set of Android devices. Many teams assume their app will only look right on a screen of a particular screen size and limit their design to suit only a handful of devices supporting that size. In reality, Android offers you tools needed to develop a visually impressive interface that supports the full range of devices and screen sizes on the market.

To help you accommodate the range of Android screen sizes, Android recommends designing four versions of the application UI:

  • A small version for screens under 3”.
  • A normal version to accommodate 3” to 4.5” screens.
  • A large version for viewing on 4.5” to 10” screens.
  • An extra large version for devices with screens larger than 10” (tablet).

It is not strictly necessary to create a design for all four versions – in some cases; one “normal” and one “extra large” version may suffice. If, however, you need to display a large number of controls on your screen, or your organization wishes to ensure perfect consistency across screen sizes, you may decide to accommodate all four size categories listed above.

Fragments

A smartphone should only display one activity per screen due to its small screen size. Tablet devices, however, offer additional screen real estate and are often used in a similar setting as a desktop or notebook, meaning the application could show more information at once on the screen. Using an Android construct called fragments, designers and developers can merge portions of the UI onto one large screen or split them into individual screens for use on small screens. This can help to reduce the number of interactions a user must perform on a device with a large screen and eliminate wasted space.

The example below shows a Gmail interface on a tablet display. This design uses fragments to display both the navigation list at left and the Inbox content at right. The design reduces the number of screens that must load before the user reaches the desired message.

If you anticipate your app will someday be used on a tablet device, we strongly recommend you incorporate fragments into your design. Designers need to be aware of the concept of fragments in order to design by fragment, and developers also need to be aware of this concept and its implementation details.

By designing custom, reusable fragments for each screen activity at the beginning of the project, you can eliminate the need to create an entirely new layout for a tablet device.

Intents

Android applications typically borrow from other applications already on the device. Using intents you can simplify both the programming requirements for your app and offer simpler, less cluttered screens.

If your app needs to perform a function beyond its core abilities such as opening a photo, looking up a contact, or playing a video, the team should investigate whether a tool that can perform that function already exists in the OS or in a popular third-party app. If so, you can leverage that functionality using intents.

For example, if your app accesses user contacts, you can use intent objects to launch the device’s existing Contacts application. This will eliminate programming duplication and speed up the user’s interaction with the device since the user will not need to re-learn how to add a contact to your particular app.

Android offers specific UI controls, activities, interactions, layout and resize options, as well as special constructs like fragments and intents. While on the surface these appear to be things that the design team needs to work with, we contend that the entire team must be immersed in Android to coordinate design, workflow, and execution into a single, intuitive application — one that grabs users’ attention and draws them into the real value of your product. 

Comments

Post a Comment

All Post

When to Use Waterfall vs. Agile

By
  We compare the benefits and drawbacks of using two well-known software development methodologies, Waterfall and Agile, and lay out when it might be more suitable to use one over the other – or combine practices of both – for your product initiative. When developing a new software product, your team will need to navigate which development methodology is right for your initiative. In the world of managing  software development  projects, the topic of Agile vs Waterfall is widely debated. Many thought leaders and Agile enthusiasts in the industry have argued Waterfall is dead, however, traditional organizational environments and processes have led to it still being widely used today. A 2017 report from the Project Management Institute shows that  51% of the organizations surveyed use Waterfall either often or always . The reality is, each software development project poses its own unique challenges and requirements. It’s not a matter of deciding which development methodology is “the bes
Post a Comment
Read more

Flutter form validation: Full guide for you to make Flutter form

By
  Flutter form validation Getting started with form validation in Flutter The Flutter SDK provides us with an out-of-the-box widget and functionalities to make our lives easier when using form validation. In this article, we’ll cover two approaches to form validation: the form widget and the Provider package. You can find more information on these two approaches in the official Flutter docs. Creating a form in Flutter First, we are going to create a simple login page that has the following fields: Email Name Phone number Password For the validation, we want the users of our app to fill in the correct details in each of these fields. The logic will be defined as such: First, for the name field, we want the user to enter a valid first name and last name, which can be accompanied by initials. For the email field, we want a valid email that contains some characters before the “@” sign, as well as the email domain at the end of the email. For phone number validation, the user is expected to
Post a Comment
Read more

How to change the language on Android at runtime and don’t go mad

By
  How to change the language on Android at runtime and don’t go mad TL;DR There is a library called Lingver that implements the presented approach with just a few lined of code.  Check it out! Introduction The topic is old as the hills, but still is being actively discussed among developers due to frequent API and behavior changes. The goal of this post is to gather all tips and address all pitfalls while implementing this functionality. Disclaimer Changing the language on Android at runtime was never officially encouraged or documented. The resource framework automatically selects the resources that best match the device. Such behavior is enough for common applications, so just make sure you have strict reasons to change it before proceeding further. There are a ton of articles and answers on Stack Overflow but they usually lack enough of explanation. As a result, when this functionality gets broken, developers can’t easily fix it due to the messy API and lots of deprecated things. We
Post a Comment
Read more

How to them the background of the Android options menu items

By
  “What we’ve got here is… failure to theme. Some views you just can’t reach. So you get what we had here last project, which is the way Android wants it… well, it gets it. I don’t like it any more than you men.” – Captain, Road Prison 36 Some of you might recognize the previous paragraph as the introduction of Guns ‘N Roses’ Civil War or from the movie Cold Hand Luke starring Paul Newman. This is the feeling I get when I try to create a custom theme for an application on Android. The Android SDK does permit some level of theming, which is not really well documented to start with. Other things are hard-coded, “so you get what we had here last project”. Now, one of the things your application will most likely use is the Options menu, which is the menu you see when you press the hard menu key. It is kind of… orange. In our last project, we had to completely remove the orange in favor of our customer’s color scheme, which is on the blue side. I couldn’t find a way to change the menu item
Post a Comment
Read more

Clean Code and the Art of Exception Handling

By
  Clean Code and the Art of Exception Handling Exceptions are as old as programming itself. An unhandled exception may cause unexpected behavior, and results can be spectacular. Over time, these errors have contributed to the impression that exceptions are bad. But exceptions are a fundamental element of modern programming. Rather than fearing exceptions, we should embrace them and learn how to benefit from them. In this article, we will discuss how to manage exceptions elegantly, and use them to write clean code that is more maintainable. Exceptions are as old as programming itself. Back in the days when programming was done in hardware, or via low-level programming languages, exceptions were used to alter the flow of the program, and to avoid hardware failures. Today, Wikipedia  defines exceptions as: anomalous or exceptional conditions requiring special processing – often changing the normal flow of program execution specialized programming language constructs or computer hardware m
Post a Comment
Read more

Android Jetpack Compose

By
  Jetpack Compose Tutorial for Android: Getting Started Jetpack Compose is Android’s modern toolkit for building native UI. It simplifies and accelerates UI development on Android. Quickly bring your app to life with less code, powerful tools, and intuitive Kotlin APIs. At Google I/O 2019, Google first announced  Jetpack Compose . Jetpack Compose is Google’s response to the declarative UI framework trend, which the Android team is developing to fundamentally change the way developers create UI, making it easier and faster to write, and more performant to run. It is a part of the Jetpack suite of libraries and as such should provide compatibility throughout platform versions, removing the need to avoid certain features, because you’re targeting lower-end devices or older versions of Android. Although it’s still in an alpha , Compose is already making big waves in the Android community. If you want to stay up-to-date on the latest and greatest technology, read on! In this tutorial, you’
Post a Comment
Read more

Loops in Dart 💪💪💪😎😎😎

By
       Loops in Dart   💪💪💪😎😎😎 Dart Loops In Programming, loops are used to repeat a block of code until certain conditions are not completed. For, e.g., if you want to print your name 100 times, then rather than typing print(“your name”); 100 times, you can use a loop. There are different types of loop in Dart. They are: For Loop For Each Loop While Loop Do While Loop Info Note : The primary purpose of all loops is to repeat a block of code. Print Your Name 10 Times Without Using Loop Let’s first print the name 10 times without using a loop. void main() { print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); } Show Output
Post a Comment
Read more

MVVM architecture, ViewModel and LiveData (Part 1)

By
  MVVM architecture, ViewModel and LiveData (Part 1) During Google I/O, Google introduced  architecture components  which includes  LiveData  and  ViewModel  which facilitates developing Android app using MVVM pattern. This article discusses how can these components serve an android app that follows MVVM. Quick Definition of MVVM If you are familiar with MVVM, you can skip this section completely. MVVM is one of the architectural patterns which enhances separation of concerns, it allows separating the user interface logic from the business (or the back-end) logic. Its target (with other MVC patterns goal) is to achieve the following principle  “Keeping UI code simple and free of app logic in order to make it easier to manage” . MVVM has mainly the following layers: Model Model represents the data and business logic of the app. One of the recommended implementation strategies of this layer, is to expose its data through observables to be decoupled completely from ViewModel or any other
Post a Comment
Read more