How can you include accessibility in your app?

Think about accessibility before the build even begins 

Have you ever seen a building that had a wheelchair ramp added as an afterthought? Think of an all green building with a random red ramp. It looks messy and forced, right? It looks like it’s not supposed to be a part of the building. Adding in accessibility to your app after you’ve finished has the same look to it. So how do you avoid that? 

The best way is to consider the accessibility aspects of your app before you start. This means that accessibility for as many users as possible must be a forethought when creating your app. Ways to make it easier for all people to use your application have to be thought about before the building process even begins and definitely not after. Considering all types of users in your design will allow for a smoother design process and a better-looking design.

Avoid bad design at all costs.

Including accessibility in your application is the right choice, but it needs to be done correctly. Here’s a little secret: people don’t like bad design. Bad design is painfully noticeable. And bad design is usually what happens when accessibility isn’t thought about until after the application is already built (it’s also a way to build up some nasty design debt). Avoid it at all costs by simply including accessibility in the planning process because people will notice. Accessibility doesn’t have to be clunky and awkward. Good design is seamless and accessible technology should be, too.

For the basics on getting started with accessible design, check out Learn the Basics of Accessible Design. 

Understand that accessibility is not one size fits all.

There are a few concepts to consider when planning for accessibility technology. Accessible technologies work across a wide range of differing abilities and work to accommodate as many people as possible. That means it needs to be thought about every step of the way, from text size to application colors. 

Give users the option to enlarge text. This will make your app easier to use for all people, especially for blind or visually impaired individuals. Additionally, a voice-to-text option is very helpful for those who are deaf or hard of hearing but will also benefit a person on the go. Captions are beneficial for those who struggle with hearing but also make for a more enjoyable viewing experience for all people. 

Why is Accessibility so important? 

Accessibility means opening your app to as many people as possible.

So now you know that accessibility means making your application available to as many people as possible. But maybe you still need more convincing on why you should include accessibility in your app. Not a problem. 

For starters, consider that accessibility is a critical aspect of universal design. Universal design is the design of products and environments to be usable by all people to the greatest extent possible without adaptations and special design.  The fact of the matter is that 1 in 4 Americans has a disability. So, including accessibility is not just the right thing to do, but it also opens you up to a whole new customer base. 

Accessibility makes for a great customer experience.

The beauty of accessibility is that each user can interact with your application in the way that works best for them. Remember, first impressions are everything. Once users click out of your application, you want to make sure you did everything in your power to ensure they come back. How do you get users to keep coming back to your application? Great question. 

The answer is simple: excellent customer experience. Customers don’t want to feel frustrated when using your application, and by not including aspects that make for a great customer experience such as accessibility, many customers will be left feeling very disappointed when they cannot use your application correctly and are going to take their business elsewhere. Avoid losing customers by simply keeping customers happy. Keep customers happy by making your application user-friendly for all people.

There is literally money at stake 

Title II and Title III of the ADA requires that software, websites, and apps be accessible to as many people as possible. Not following those guidelines? That could end up literally costing your company money paid out in fines. 

Additionally, if your app leaves out an entire customer base or makes tasks more difficult for certain employees, you’re losing money, both from potential clients and from the time spent having to create workarounds. 

It’s the right thing to do

Bottom line – accessible technology is key for creating a more equitable society and that’s some good stuff for all of us. There’s also a really good chance that you’ll find that the more thoughtful you are about how you build your apps from an accessibility standpoint will translate to being more thoughtful about how you approach different parts of your business.  

Now that you have an understanding of why accessibility is essential and how to get started with accessibility in your app, you may be wondering how you can begin to implement it with actionable steps. Give us a shout and we’ll be happy to talk through all the ins and outs of what makes for a well-built app for everyone.                                                                                                                                                                                                                                 

Resources

https://sopa.tulane.edu/blog/why-accessible-technology-important

https://it.wisc.edu/learn/guides/accessible-content-tech/what-is-accessible-technology/

The post Why Accessibility in Tech is Vitally Important appeared first on Big Nerd Ranch.

1. A commitment to CI encourages good practices

Like any process, CI is, well, a process. Basically, this means that it is something that you and your team will work on together. And that’s a good thing! Because with a good process comes good practices. The more you can solidify good practices, the better your team will work. 

While every project is different, there are some best practices to work towards. These include committing work frequently, communicating with teammates, and holding high-quality standards of the work that is produced. With CI you are continuously integrating code and also continually ensuring that the quality is high through code reviews, automated testing, and manual testing. Doing all of this at the moment allows for problems to be fixed immediately when developers still have the context of their work. The fix is easier to accomplish and it’s fixed before it impacts any users.

2. It helps developers stay consistent

While spontaneity might be the spice of life, consistency is key when it comes to a development project. Being able to get into a groove and knowing what work you have to do and when is a huge plus for engineers—especially as the projects grow in size. 

A solid CI process allows developers to deliver smaller portions of code at a time. This allows for non-duplicative work and for developers to ensure that the code they do commit is as bug-free as possible and in tip-top shape. It also reduces the number of manual and repetitive tasks that developers are faced with, allowing them to focus on leveling-up in their pure development skills. All this equates to a consistent workflow and a better-built product. 

3. It shifts the focus closer to the work, and work closer to the bugs, and communication more centered around the product and results

Context switching carries a hefty burden. If a developer works on fixing a bug with a feature that they implemented a long time ago, they will have to remember and uncover how and why they chose the solution that they did. It takes time to get back into the right mindset to fix the bug.

In a well-built CI process, your team identifies those bugs earlier and your production environment is much more stable. Bugs are fixed as they are created rather than fixed at some point in the future. This leads to less context switching and better solutions to problems. 

4. It increases transparency between team members 

It’s not a secret that communication is vital between developers and teams when working on a project. With continuous integration, work has to be done out in the open among the team. Code is committed often, it’s reviewed, and it’s tested. It’s also important that the team has the mentality of blameless feedback (which is one of our CI best practices). In keeping feedback neutral, you’ll find more positive accountability and a better functioning team.

In fact, consistent and blameless feedback helps to mitigate the damage of future build failures or merging issues. The team should think about feedback as a way to learn and improve rather than something that is negative. If everyone is facing the same way and moving at the same pace, good things happen. 

5. Coupled with continuous delivery, it can decrease time to release and increase the amount of feedback you get from the market

Somewhere, in some promised land, we come up with amazing ideas and develop fantastic builds, all with no timelines or release dates. Just coding to our heart’s content. Until we make it there, however, we have to be aware of our deadlines.

The good news is that in a CI/CD pipeline, the build is developed, tested, pushed, and released in a much faster time frame than if done manually or without a set process. With the right level of quality and process, your product can be updated as often as you like (even many times a day) which means that your changes are making it to users faster. You can delight your users with updates and learn more from your users to find the right product fit.

So what’s next for my project?

At the Ranch, we use CI and CD whenever humanly possible. We find it helps to keep our clients happy and our developers sane. We also know that it helps us to create some amazing digital products that solve problems and keep end-users happy and engaged. Are you curious to learn more about how we go about building amazing experiences? Set up a call and let’s chat!

The post 5 Reasons Why Continuous Integration is Important appeared first on Big Nerd Ranch.

Enter Continuous Integration (or CI if you want to be fancy), a process that will change how you develop apps all while being more efficient and effective. 

So, what exactly is Continuous Integration? 

In a nutshell, CI is the “software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run.” In essence, it’s an opportunity to have consistent validation of work done throughout the project instead of at designed endpoints. 

Before we get into the details of CI, it’s important to understand what we’re solving for by putting Continuous Integration into place. At a high level, what we’re hoping to avoid is what’s known as “integration hell,” or the influx of a massive amount of disparate changes all integrated at once at the end of a project. 

Buggy builds 

The risk that companies always run when multiple developers are working on a single project is competing code merges creating bugs in the application. This often happens when merges occur at the end of sprints or, heaven forbid, the end of the project. That lapse in time allows for bugs to accumulate and, when combined with other merges, creates a nightmare of a bug-hunting situation. 

The most common result from such an outcome is a product or update that is delivered behind schedule and one very unhappy QA person. That means frustrated employees and unhappy users. 

Frustration due to duplication of work

Another downside of waiting to merge until the end of a project is the risk that developers might unknowingly duplicate their efforts in the project. On bigger projects with multiple, complicated areas developers will often work on their sections without a lot of communication with their coworkers only to find that they’ve completed near-identical pieces of work. Due to the time-consuming nature of coding, this can be quite frustrating for your developers and has the very real possibility of delaying the project. 

Overall lack of communication

As we mentioned above, on larger projects developers may default to work on their portion of the project in a silo. During that work, developers may move in different directions and won’t communicate as proactively as they should. Not only can this cause the problems we discussed above, but it also can create a feeling of isolation amongst your team. 

Developers are working independently and not really sure what the others are working on where they are in their portions of the project

So How Can Continuous Integration Help? 

Great question. Let’s dive in. 

So again, CI is the practice of developers merging their code at regular points throughout the entire project. So, instead of waiting until the end of a sprint or the project, they will frequently commit their work to a shared repository. From a developers’ standpoint, that’s broken up into three stages that are repeated throughout the project—Build. Test. Merge. 

Build

Of all the different parts of the CI process, this is probably the most straightforward. It’s here that the developer works on the code for the application. On some projects, that is one developer. On others, it’s a team of developers working independently on several portions of the same project. 

Test

Once a developer is done with their set portion it’s time to test to ensure the build is solid and that there aren’t any bugs hidden in the code. Testing can be done manually or automated, depending on what your company has available and what your developers are most comfortable with. We recommend automated tests that run automatically by the CI server when code is submitted for review.

The beauty of CI is that since the developers are testing at more frequent intervals the changes that they are working from are smaller than if they waited. That means that any bugs that do pop up are easier to locate and remedy. 

Merge

Once satisfied with the build, it’s time to merge the code to a shared version control system such as Git. Again, because this step is done more often throughout the project it reduces the chances of duplicate work, unforeseen conflicts, and an overload of bugs. 

Then, rinse and repeat! 

What are the advantages? 

Identify and resolve conflicts early 

One of the biggest advantages of Continuous Integration is that your team is constantly checking their code for bugs before merging. That means a collection of cleaner code throughout the entire project. In addition, because of the frequent nature of merges, your team will be in better communication, meaning fewer duplications of effort and a better-shared understanding of the codebase.   

 Developers are more productive

With clean code and the knowledge that the portion they are working on is theirs alone, developers can free themselves up to focus on what really matters—building the best product possible for the client and end-user. After all, any time spent chasing bugs or untangling similar changes is time not spent building out new value for your users. 

Deliver your product and updates on time

At the end of the day, app development is a business. Because of that, it’s important that milestones are met throughout the engagement. Otherwise, you will lose the trust of your client, and that’s one of the hardest things to gain back. By utilizing Continuous Integration and solving problems early, you’ll find that your team is able to deliver a well-built app on time. 

CI at the Ranch

The ideal payoff of a properly implemented CI solution is a satisfied client. That means a well-built digital product delivered on time and an experience that’s sure to wow the users. 

While it’s a process that can take time to get right, it’s one that is worth the effort. At the Ranch, we’ve incorporated CI into our digital product development process not just to maintain a tight process, but to also ensure that the goals of our clients are met throughout the project—even if those goals change. 

If you have questions about how we manage CI in our projects or would like to chat about a potential project, don’t hesitate to reach out! 

Source: Atlassian

The post What is Continuous Integration? appeared first on Big Nerd Ranch.

Last week, Google announced official support for the Kotlin programming language on Android. Now, developers can write their apps in either Java or Kotlin.

Developers are excited about this news, but what does it mean for business owners? Is this a positive change—or a burden?

First things first: Kotlin is optional, and you can continue developing your Android app in Java, just as you always have. So why would you switch to Kotlin? We think there are a number of benefits.

Less Code and Built-In Conveniences

Kotlin is a modern language that was created to improve some of the pain points that developers have learned over the many, many years of using Java and other languages.

This means that the language has many conveniences built in. Something that used to require hundreds of lines of code may now require just a few lines in Kotlin. Not all updates will be as drastic, but Kotlin does often allow you to do the same thing that you are currently doing in Java, but with less code.

And the less code your developers have to write, the better. Additional code takes more time to write, has a higher chance of bugs and requires more time to manage in the long run. In essence, Kotlin means less code and less code means fewer problems.

Fewer Bugs

Kotlin helps reduce bugs in your code because it forces the developer to make certain decisions about their code as they write it.

In Java, many of these decisions are implicit, or default to the most permissive option. This means that those decisions are often an afterthought. Delaying these decisions can lead to crashes in your app—and you find out only after your app is in the hands of your users as they begin experimenting with it.

In contrast, Kotlin allows you to discover some of these issues as soon as the code is written. You will find and fix these kinds of issues before they end up affecting your users, ultimately leading to a better user experience, higher Play Store reviews and more downloads.

Kotlin and Your Existing Code

Kotlin works with Java, but it was designed to improve the experience developers have when writing their code. Because of its flexibility, you can start by converting a single file to the Kotlin language mid-project without having to rewrite the old Java code, meaning that you don’t have to switch everything over, at least not immediately.

That being said, the transition to Kotlin should be fairly easy for developers since it is a comfortable transition for people who already know Java. And once the language is learned, it’s bound to save time and headaches, ultimately freeing developers to improve current projects, create additional projects and experiment with the ever-growing Internet of Things across Google’s array of platforms.

The Future

Google values developer feedback; official support for Kotlin is here because the community demanded it. Android developers at prominent companies like Basecamp and Pinterest have already switched over to Kotlin and have seen benefits in their projects. As more and more companies make the leap, you can expect to see Google (and the entire Android community) continue to promote Kotlin and place less emphasis on Java.

All of this means that now is the time to plan for Kotlin. While Google is unlikely to completely drop support for Java in the near future, Kotlin is here and will quickly become the preferred language going forward.

Ready to get started with the transition? We’ve been writing code in Kotlin for years, and we have the expertise to help your team embrace this change. If you’d like to learn more about Kotlin, contact our sales team for more information on how we can help you move your business forward into this new era of Android development.

Learn more about what Kotlin means for your Android apps. Download our ebook for a deeper look into how this new first-party language will affect your business.

The post What First-Party Kotlin Support Means for Your Business appeared first on Big Nerd Ranch.

I’ve been lucky enough to read the 3rd edition of Android Programming: The Big Nerd Ranch Guide early (because I helped write it) and now I have the opportunity to tell you about it.

You’ve seen what we planned to write about. You’ve seen how the writing process works. Now, you will see what actually made it into the book.

The List

If you came here looking for a skimmable list instead of detailed descriptions of each point, here it is:

• ConstraintLayout
• Localization
• Accessibility
• MVVM
• Data Binding
• Unit testing
• FileProvider
• Permissions
• Simplified RecyclerView coverage
• More challenges
• Adjusted the minimum SDK to KitKat
• Updated for the latest Android Studio

Plus hundreds of smaller improvements thanks to feedback from our students and our forums.

Now, let’s break this down.

New Layout Tools

You could feel the earth shake when ConstraintLayout was first announced. Is this the UI tool that we’ve been waiting for? Good performance and complex layouts made easy with a graphical tool? You be the judge. We have done our research and you can see how to use it in the book.

Read all about our decision to include it in the book in our post about the writing process.

Reaching More Users

At Big Nerd Ranch, we make the effort to support as many users as possible in the apps that we build and you should do the same. After reading the book, or joining an Android-specific bootcamp, you will have the skills needed to make that happen. We’ve always talked about how language is part of the device configuration, but now we have a dedicated chapter to walk you through the details of that process.

You will also learn about accessibility. Kristin Marsicano has written a chapter that discusses the most important accessibility considerations that you will come across and points you toward other areas of concern.

Modern Android Development

We also talk about emerging techniques in Android. Of course, we still talk about the model-view-controller architecture, but now we also cover the model-view-viewmodel architecture, which we have grown to appreciate. You will learn how to use Data Binding to support an MVVM architecture. Finally, you will write unit tests to verify that your view model classes work.

Iterative Improvement

With every update to the book, we look out toward the future. The minimum SDK throughout has been updated to KitKat (API level 19) and this edition addresses any concerns you would have supporting Nougat and beyond.

Learn Android

Now, the call to action. You can pre-order the book through Amazon or InformIT before it is officially released in mid-February. If you can’t wait that long, sign up for one of our Android classes. In every class we teach, you will receive the latest version of the book taught by an expert instructor.

Our five-day Android Essentials course is based off of the book. As students work through the class, we see where they run into snags. This shows us what is easy, and what takes a little more explanation. We use the feedback from our courses to make this book buttery smooth.

In everything we do at Big Nerd Ranch, our goal is to be genuinely useful. To empower others to make great things. I believe that we’ve done that and I’m excited to see what you can do.

The post What’s New In Android Programming: The Big Nerd Ranch Guide appeared first on Big Nerd Ranch.

When the Android design support library dropped a few months ago, developers were given all kinds of goodies. Most of these goodies are self-explanatory: The floating action button, you’ve seen that. Snackbars and Tabs? Everyone knows what those are.

But there is also something mysterious lurking in the design support library. Something that has its tentacles throughout. This mysterious thing is known as the CoordinatorLayout.

CoordinatorLayout

You don’t hear much about CoordinatorLayout, probably because when you use it, you generally don’t need to know many of the details. Things just work and they just work well. However, CoordinatorLayout is more powerful than it first seems.

Take a snackbar and a floating action button as an example. Using a CoordinatorLayout, you can ensure that your floating action button will move out of the way when the snack bar pops in.

Just throw a CoordinatorLayout in your layout file:

<android.support.design.widget.CoordinatorLayout
  android:id="@+id/container"
  xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:app="http://schemas.android.com/apk/res-auto"
  android:layout_width="match_parent"
  android:layout_height="match_parent">

  ...

  <android.support.design.widget.FloatingActionButton
    android:id="@+id/fab"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_gravity="bottom|right|end"
    android:layout_margin="8dp"
    android:src="@drawable/abc_ic_search_api_mtrl_alpha"/>

</android.support.design.widget.CoordinatorLayout>

Then show your snack bar:

Snackbar.make(findViewById(R.id.container), "Hey there!", Snackbar.LENGTH_LONG).show();

Magically, your floating action button will move when the snack bar shows up. That’s it!

Out of the box, CoordinatorLayout can also increase the size of your toolbar based on scroll position or hide your toolbar when the user is scrolling down a list. You can customize it with your own behavior, too.

So how does CoordinatorLayout know what to do with the floating action button? How does it know that it should move up the screen when the snack bar comes in?

CoordinatorLayout makes this happen by making use of a CoordinatorLayout.Behavior implemented and declared by FloatingActionButton.

CoordinatorLayout.Behavior

Views within a coordinator layout can specify a Behavior that defines how that view interacts with other views.

@CoordinatorLayout.DefaultBehavior(FloatingActionButton.Behavior.class)
public class FloatingActionButton extends ImageView {
  ...
}

If you look at the source for FloatingActionButton, you will see its Behavior defined with an annotation on the class declaration.

FloatingActionButton uses FloatingActionButton.Behavior as its default behavior unless you set it to something else. The default knows how to get out of the way of the snackbar when it shows up.

Custom Behavior

So, how do you customize this behavior? You define your own Behavior subclass.

Let’s create a Behavior that shrinks the FloatingActionButton instead of moving it up the screen when the snackbar shows up.

First, in your layout file, use the app:layout_behavior attribute to point to your Behavior subclass:

...

<android.support.design.widget.FloatingActionButton
  android:id="@+id/fab"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:layout_gravity="bottom|right|end"
  android:layout_margin="8dp"
  android:src="@drawable/abc_ic_search_api_mtrl_alpha"
  app:layout_behavior="com.bignerdranch.android.custombehavior.ShrinkBehavior"/>

...

Then, create your class:

public class ShrinkBehavior extends CoordinatorLayout.Behavior<FloatingActionButton> {

  public ShrinkBehavior(Context context, AttributeSet attrs) {
      super(context, attrs);
  }

}

When you define your own behavior, there are many methods that you can override. For this example, there are two that are necessary:

@Override
public boolean layoutDependsOn(CoordinatorLayout parent, FloatingActionButton child, View dependency) {
    return dependency instanceof Snackbar.SnackbarLayout;
}

The layoutDependsOn method is CoordinatorLayout’s way to see which views your floating action button are dependent on. In this case, if the view is a snackbar, set up a dependency by returning true.

The Android documentation indicates that by setting up this dependency, you will receive calls to onDependentViewChanged when a dependent view changes its size or position. This is true, but CoordinatorLayout’s source provides more detail. onDependentViewChanged is called whenever ViewTreeObserver.OnPreDrawListener.onPreDraw is called or when a scroll or fling action occurs.

@Override
public boolean onDependentViewChanged(CoordinatorLayout parent, FloatingActionButton child, View dependency) {
  float translationY = getFabTranslationYForSnackbar(parent, child);
  float percentComplete = -translationY / dependency.getHeight();
  float scaleFactor = 1 - percentComplete;

  child.setScaleX(scaleFactor);
  child.setScaleY(scaleFactor);
  return false;
}

As the snackbar moves up the screen, this method is repeatedly called. You can do a little math to determine how far up the screen the snackbar is and change your floating action button’s size as a result. You can see the full implementation of this ShrinkBehavior class on GitHub. You can find the source for this sample and another custom Behavior that rotates the floating action button there as well.

The post Customizing CoordinatorLayout’s Behavior appeared first on Big Nerd Ranch.

Android developers spend a lot of time developing tablet versions of their applications.

OK, maybe they don’t, which is probably why there was a big push at Google I/O this year for developers to optimize their apps for devices larger than phones. Google even announced a featured section of the Google Play Store for tablet-optimized apps. Of course, Android developers have powerful tools that can be used to create applications that gracefully scale to different screen sizes. Last week, Google added another tool to our arsenal: SlidingPaneLayout.

Sliding What?

You may have seen the new Hangouts application released last week. This app is designed around the SlidingPaneLayout, which is a new addition to the support library.

A SlidingPaneLayout consists of two panes: the master pane and the detail pane. In the Hangouts application, the master pane contains a list of ongoing hangouts and the detail pane contains the actual hangout conversation. Selecting an item in the master pane will update the detail pane.

The really cool thing about SlidingPaneLayout is that the rightmost pane, the detail pane, can be dragged horizontally to uncover the master pane below. On a screen that is large enough to display both panes, the user will see both simultaneously. On a small screen, the user will see a single pane at a time and can slide the detail pane to reveal the master pane.

I’m Sold, How Does It Work?

Good news! SlidingPaneLayout is incredibly easy to use. SlidingPaneLayout is a ViewGroup, so it is designed to contain child views. However, this particular ViewGroup is intended to have only two children. To make use of this Layout, simply add its tag to your layout XML file for an Activity:

<android.support.v4.widget.SlidingPaneLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
    <textview android:layout_width="250dp"
        android:layout_height="match_parent"
        android:background="#CC00FF00"
        android:text="Pane 1" />
    <textview android:layout_width="400dp"
        android:layout_height="match_parent"
        android:layout_weight="1"
        android:background="#CC0000FF"
        android:text="Pane 2" />
</android.support.v4.widget.SlidingPaneLayout>

That’s it. You are now using SlidingPaneLayout and you have a tablet-optimized app!

There Must Be More

Of course, a real app would have something more complex than two TextViews in each of the panes. Fragments would be a great fit here.

A master Fragment and a detail Fragment could be used, and would encapsulate all of your app’s custom controller code into reusable classes. If requirements change and you decide to do things the old-fashioned way (without SlidingPaneLayout), you would have to change only the Activity that is hosting your Fragments, not the Fragments themselves.

The Catch

As you would expect, SlidingPaneLayout works just fine with Fragments. I highly recommend using a Fragment for each of the panes.

However, there is one problem. Options menus (the items that show up in the Action Bar or when hitting the menu hardware button on some devices) do not work correctly. Since the SlidingPaneLayout is just a ViewGroup, it is not in control of the options menu and the user will always see the menu items from both fragments, even when you’re looking at just a single pane.

In an ideal world, I would like to see the SlidingPaneLayout show only the options items that are available for the currently selected Fragment in the layout (of course, seeing menu items for both fragments is fine, if the user is on a device that is large enough to show both panes). Obviously, there are ways to implement this yourself, but it does require a little extra work. The Hangouts application is clearly doing that extra work to update the options menu and the rest of the Action Bar when panes become selected.

What’s The Verdict?

SlidingPaneLayout is not a natural fit for all applications, and it’s certainly not a replacement for the new Navigation Drawer paradigm. It is a handy Layout, though, especially when creating applications that work well on any size device. Of course, there are downsides, like the Fragment options menu problem from above. SlidingPaneLayout is also marked as experimental in the documentation, so its future is uncertain. Like ViewPager, though, this will cause a problem only if/when you decide to update to a new version of the support library.

I’m excited to see the Android team take components that they use internally and encourage developers to include them in their own apps. Components like these as well as those contributed by other Android developers allow us to make better Android apps with less work.

The post Exploring SlidingPaneLayout appeared first on Big Nerd Ranch.