Toward the end of the Android Essentials bootcamp, students learn to load images from the web into a RecyclerView. As an instructor, it’s one of my favorite chapters because it teaches some of the fundamental pieces of Android including Handlers, HandlerThreads and Loopers.

However, I also warn students that it is not meant as a complete guide for loading an image in an Android app. It doesn’t cache images, barely supports request cancellation, and the solution is too complicated and custom for what is a very common task in Android. Four years ago, we wrote a post on Volley vs. Picasso, but today there are newer options and limitations that we should consider.

In this post, I’ll be comparing the three most popular image loading libraries: Picasso, Glide and Fresco. All three have very similar features but differ from each other in small ways. This post aims to show you what each is capable of in order to help you confidently choose the right one for your needs.

Loading An Image

Let’s first take a look at what it’ll take to load an image with a placeholder in each library. We’ll talk about the differences in more detail. You can see this code running in an adaptation of our PhotoGallery exercise from the book here.

Picasso and Glide are very similar and use a simple syntax to load the image:

Picasso.with(getContext())
        .load(galleryItem.getUrl())
        .placeholder(R.drawable.placeholder)
        .into(mImageView);

GlideApp.with(getContext())
        .load(galleryItem.getUrl())
        .placeholder(R.drawable.placeholder)
        .into(mImageView);

In order to access request options like placeholder() in the new Glide 4.0, you will also need to add a generated API and declare the following class:

@GlideModule
public final class MyAppGlideModule extends AppGlideModule {}

And that’s all! Compared to the 100+ lines of code we cover in Android Programming: The Big Nerd Ranch Guide, this is a wonderful improvement. Both Picasso and Glide first fetch an instance of the library and then allow you to specify the URL of the image to load, a placeholder while loading, and your target ImageView. From there, the libraries will handle spawning a background thread, loading the bitmap, and displaying the image it in your ImageView when it’s ready.

Fresco requires a couple more changes to your layouts and code. To start off with you’ll need to initialize the library in your application subclass by calling:

Fresco.initialize(context);

Next you will need to use their special view class, called SimpleDraweeView. In your XML layout it would look something like this (notice that we can specify the placeholder in XML):

<com.facebook.drawee.view.SimpleDraweeView
    android:id="@+id/simple_drawee_view"
    android:layout_width="match_parent"
    android:layout_height="120dp"
    app:placeholderImage="@drawable/placeholder"/>

Finally, in your code you can simply set the SimpleDraweeView to load in your image:

mSimpleDraweeView.setImageURI(galleryItem.getUrl());

Loading Extras

Where all three of these libraries shine is in the features provided behind the scenes. They all keep a local cache of images downloaded, allowing subsequent requests to the same image to simply load from memory or disk instead of incurring another network hit. They each have their own implementation of an LRU cache for in memory and local storage that will clear out entries as memory or storage space is required. Fresco, on Android API level 19 (KitKat) and below will store the bitmap cache’s data in the ashmem heap, not in the Java heap, according to their documentation. “This means that images don’t force extra runs of the garbage collector, slowing down your app. Android 5.0 has much improved memory management than earlier versions, so it is safer to leave the bitmap cache on the Java heap”. That being said these implementation details are largely behind the scenes, and if you require customization, all three provide an API to supply your own cache implementation.

In our PhotoGallery example we use all three in a RecyclerView which adds another problem to image loading. If the user flings very quickly, views will be recycled and reused for rows further down the list. What happens if a view has multiple calls to load a URL to the same ImageView? All three libraries here will manage this case for us. This means keeping track of requests made to the same target view and canceling any previous request made so as to not waste network resources on an expired request. What would previously be a multithreading nightmare is now automatically handled using these libraries.

Finally, all three libraries have image transformation support. If you want to apply a resize, crop, greyscale, etc. to your image as it loads, they each provide an API to define your own transformation to the loaded bitmap. Picasso and Glide each have examples of how to use their transformation APIs, and due to their popularity, you can usually find an example of a transformation you need. For two examples, check out here and here. Fresco has a little more built in when it comes to simple transformations, but if you need more, take a look at their documentation on postprocessing.

Learn how a design audit can help you see the most success from your mobile or web application.

Where They Differ

The libraries begin to differ in the image formats they support. Glide and Fresco allow you to load in a GIF image and have it animate in your image view, while Picasso will simply load in a static bitmap of your GIF. Fresco is also the only library that supports WebP images on older versions of Android where support is not natively available. Glide and Picasso only support what is natively supported by the OS; take a look at the documentation for more information on what is available in Android.

Glide adds in some extra support around the Android lifecycle. Glide’s with() method can take more specific fragment or activity instance, which will tie the image loading call to that lifecycle in order to intelligently stop, start and restart requests. Glide recently released a major version change from v3 to v4, so samples may need to be migrated according to the changes outlined here.

Fresco was created as a result of Facebook’s Android development work, which required a large amount of image loading and better performance on low end devices. We mentioned the difference in image caching locations for Android versions below 5.0 that help achieve this improved performance. Fresco also supports the streaming of progressive JPEG images, which allows a low resolution version of an image to load first and gradually improve the quality as more information is downloaded.

The method count of each library can also be a deciding factor for your project. Android applications have a method limit of 65,536 methods before things start to get messy, requiring multidexing of your app or applying proguard to your application. Picasso is quite concise, adding only ~850 methods to your application. With Glide we start to see a bigger footprint, adding ~2,800 methods to your application. Fresco has the biggest impact of them all, as ~5,800 methods are included with the dependency. This can be one of the more important factors in choosing a library, so if you don’t need animated GIFs or some of the other Fresco features, Picasso may be the right choice with its smaller method count.

All three also differ in how they are licensed. Picasso uses the Apache License 2.0, common to many Android 3rd party libraries and used within Android itself. Glide uses a BSD 2-clause. Finally, Fresco uses what Facebook has been calling the Facebook BSD+Patents License. This combination of license and patent declaration has been under close scrutiny recently by the community; here is an article that explains Facebook’s point of view.

And the Winner Is…

You can probably guess by now that I do not have an answer to this question. Each has its strengths and features for you to consider. In our consulting projects at Big Nerd Ranch, we find ourselves using different libraries for different applications depending on what the needs of the client may be. Take a look at the PhotoGallery sample showing each one in action, tinker with it a little bit and see which one fits you best.

For more information on how this works within your Android app, consider enrolling our Android Essentials bootcamp. We host one a few times a year at our Ranch locations, or we’ll bring our instructors to teach your entire team through our corporate training program.

The post Solving the Android Image Loading Problem: An Updated Guide appeared first on Big Nerd Ranch.

Recent versions of Android have focused on improving device performance, and one of the biggest improvements came with the addition of Doze Mode in Android Marshmallow and Nougat. In a previous post, we talked about background schedulers in Android, briefly mentioning the effects of Doze Mode in Android Marshmallow. This post will cover Doze Mode in more detail, the changes that are coming with Android Nougat and what you can do to correctly adapt to Doze Mode.

What is Doze Mode?

Doze Mode focuses on improving battery life on Android by cutting down on background network activity when the device is not in use. Background updates by apps are instead grouped into controlled maintenance windows, allowing for data freshness when the user comes back to their phone and exits Doze Mode.

Developers usually have control over opting into changes to the Android operating system by incrementing the target SDK level of their applications. However, in order for Doze to have a real impact on the battery life of the device, Doze Mode changes are applied to all apps regardless of target SDK level. The good news is that if you are using the framework properly there probably won’t be much you will need to change in your application. This blog post will cover when Doze is activated, what restrictions are applied, how to work around Doze (if necessary), and how to test your app for Doze effects.

When Does Android Doze?

The first concepts we need to understand are the various “stages” of Doze Mode and when they will be active on devices in Android Nougat. The main stage of Doze (referred to as Deep-Doze in this article) was introduced with Android Marshmallow and is activated when the device is not charging, the screen is off, and the device is completely stationary. Android checks for when these conditions were met, waits roughly 30 minutes to be sure the phone does not change conditions, and then jumps into the Deep-Doze battery saving mode. When any of these conditions change, the device will exit Deep-Doze Mode and restrictions will be lifted. In order to still give users a pleasant experience when they come back to their phone, Deep-Doze provides short maintenance windows where apps can sync up their latest data. These maintenance windows are spaced out further and further the longer a user is in Deep-Doze, increasing power savings. The following diagram visualizes these effects in Android Marshmallow:

The orange bars represent network activity on the device, and the green section when Deep-Doze restrictions are being applied. The “barcode” appearance of the orange bars represents network activity launching at seemingly random points in time from various applications on the phone. However, in Deep-Doze Mode there are more controlled maintenance windows in which apps background work is bundled together to run in a more compact period of time.

Android Nougat changes this formula with the addition of a more lightweight version of Doze that does not require the device to be completely stationary or wait as long to activate. I will be referring to this lightweight version of Doze as Light-Doze here. Light-Doze starts to kick in shortly after both the screen is off and the device is not charging, waiting only a couple minutes before applying the restrictions just to make sure the user has stopped using their phone. Light-Doze has fewer restrictions placed for battery savings, so the period between data-syncing maintenance windows is shorter. The goal is to provide a quicker step to Doze Mode with a smaller impact before initiating Deep-Doze Mode.

While in Light-Doze Mode, if the device has remained stationary, the system will drop the device into Deep-Doze Mode and its corresponding maintenance windows. Similarly, Light-Doze will be interrupted when the device is plugged in or the screen is turned on. It is also important to note that Deep-Doze can be interrupted and stepped up to Light-Doze if the device stops being stationary but still not charging with the screen off.

Google has provided a couple of diagrams to help visualize some of these situations, the first of which visualizes Light-Doze becoming active and inactive:

In this diagram we are stepping into Light-Doze after a couple of minutes, and the maintenance windows are more frequent than what we saw with Deep-Doze. This diagram shows Light-Doze as a slightly taller and lighter shade of green to signify the lesser restrictions compared to Deep-Doze. The more interesting situation is how the device will step into Deep-Doze with Nougat:

Even though the device is meeting all three of the criteria (screen off, on battery and stationary) the OS will first step into Light-Doze while it confirms that the device has indeed been stationary for enough time.

This time period matches the second group of “barcode” activity that we saw in our first Deep-Doze image from Android Marshmallow. Once that period has passed, Deep-Doze Mode is initiated and we start to see the greater battery-saving restrictions applied.

What does Doze do?

So now that we have covered when Deep-Doze and Light-Doze come into effect, we need to take a look at the actual limitations it places on apps in the device. Light-Doze behaviors are a subset of Deep-Doze behaviors— network access is cut off for all applications and Jobs will be deferred from JobScheduler and Syncs from Sync-Adapters.

These restrictions are lifted when maintenance mode begins, and any deferred Jobs and Syncs will be started at that point. If you are using AlarmManager for your recurring background work those will continue to kick off, but it is important to note that you will not have network access in that time. If this is a deal breaker for you, it might be time to migrate your background work into JobScheduler so that you only start up when the network is available in the maintenance windows.

When the device enters Deep-Doze Mode, a couple of additional restrictions are applied. AlarmManager alarms will be deferred just like Jobs and Syncs are in Light-Doze—held onto until thedevice goes into a maintenance window or exits Doze entirely. The operating system will also ignore any wakelocks attempted by the application, which means work must be completed within the maintenance window as your wakelock will ignored when it jumps back into Doze. Finally, Deep-Doze will also stop the system from making Wifi and GPS scans, reducing location events from the device detecting WiFi hotspots.

Interrupting Doze

So now that you understand the effects Doze can have on your app, you may be thinking, “How will the user survive if I’m not allowed to run background work and notify the user of events whenever I want?!”

This shouldn’t be the case, as Light-Doze has minimal impact given that the maintenance windows occur frequently and Deep-Doze only affects your app when the user is not using their device at all (think sitting on a desk overnight, or left behind in another room while cooking). That being said, there are still some situations where you need to get around Doze’s effects, and there are a couple of options for what you can do.

If you need to make sure a notification is delivered immediately, then Firebase Cloud Messaging (FCM, formerly known as Google Cloud Messaging) can do so without you having to change your app’s source code.

FCM has the ability to send a notification to the device while in Doze Mode simply by setting the message to a high-priority message. Google warns that this should be reserved for “only if the message is time-critical and requires the user’s immediate interaction,” as this will interrupt Doze Mode and grant temporary access to network services and partial wakelocks for your app only.

If you want to have some background work run while the device is in Doze Mode and not yet in a maintenance window, then AlarmManager also has some options for your app. The methods AlarmManager.setAndAllowWhileIdle() and AlarmManager.setExactAndAllowWhileIdle() will allow the PendingIntent to fire even if the device is in Doze Mode (“idle” is considered to be the time in which Doze Mode is active).

It’s important to note that this will not lift network restrictions and will give you a 10-second window to capture further wake locks in which to complete your work. Again, Android documentation warns this should only be used in when absolutely critical, as it will affect the users battery by interrupting Doze Mode and this will be reflected in the battery stats.

AlarmManager.setAlarmClock() will also ignore Doze Mode and fire as normal, with the added effect of exiting Doze Mode completely shortly before your alarm fires (allowing the app to have fresh data before the user picks up their phone). This should not be used for your normal background work alarms, as AlarmManager.setAlarmClock() is intended to be used for what the user perceives as an alarm clock—a scheduled time at which the phone will alert the user (not just a calendar event). An icon is even displayed in the status bar as a physical alarm clock face, and many lockscreens will also inform the user of when the next alarm is scheduled.

Finally, if high-priority FCM messages and while-idle alarms are not enough, you have the option of having the user opt you into a whitelist of apps that are partially exempt from Doze restrictions. A whitelisted app can access the network and hold partial wakelocks, but the rest of Doze restrictions will still apply (notably the deferring of Jobs, Syncs and Alarms). There is no way to programmatically toggle your app to be part of this whitelist, but you can prompt the user to add you in one of two ways.

You can launch an Intent with the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS action and take the user to the Battery Optimization page where they can search through a list of all apps and turn off optimizations for your app.

Or, if you have requested the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission, you can directly prompt the user with a dialog to turn off optimizations for your app without needing the user to search for your app by launching an Intent with the ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS action.

Note that in the Android Nougat Developer Preview 4, the Settings app requires a force close to reflect changes made from this dialog. Also note that these are only for extreme cases and are discouraged by Google. The Doze documentation states: “Note: Google Play policies prohibit apps from requesting direct exemption from Power Management features in Android 6.0+ (Doze and App Standby) unless the core function of the app is adversely affected.”

That said, be sure your application requires whitelisting before prompting the user. Android documentation contains some guidance found here.

One last case which is not mentioned in the Android documentation is an app using a foreground service. Any process using a foreground service is exempt from Doze Mode effects, which is key for long-running applications that you may want to run even if the user has put their phone down for a long period of time—like a music app, for example.

There is, however, a bug in Android Marshmallow which requires a foreground service to be in a separate process from all other activity code, documented here. It is planned to be fixed in Nougat.

The important takeaway here is that in most cases you shouldn’t need to interrupt or get around Doze, thanks to the provided maintenance windows and the fact that the user is not actively using their phone.

The next step is to verify that your app works correctly under Doze without needing to use any of the workarounds mentioned above.

Testing Doze on your device

Now that you have more context on Doze and what effect it has on your device, you may want to test your app to make sure your device is behaving properly. Fortunately, Android has made it easy to do so without having to wait around for your device to settle into Doze Mode by using a couple of adb commands. Listed below are the steps for testing your device. Note that these assume a device running the Android Nougat Developer Preview 4 or later for access to Light-Doze:

1. Connect the device to your development machine and install your app.
2. Run your app and leave it active.
3. Shut off the device screen. (The app remains active.)
4. Force the system to cycle through Doze Modes by running the following commands:

$ adb shell dumpsys battery unplug
$ adb shell dumpsys deviceidle step [light|deep]

The first command will allow the system to think it is unplugged for you to continue testing while connected to USB for further adb commands (otherwise Doze Mode will never activate). The second command will step your device through each of the checks before being idle, printing out the current state after each step. By default, the command will step through the full Doze states and not bother with Light-Doze. You can add light or deep at the end to specify that you’d like to step through the corresponding Doze Modes. Once the device reaches IDLE, the step function will go back and forth between IDLE and IDLE_MAINTENANCE with each step.

You can query the current state at any point by calling:

$ adb shell dumpsys deviceidle get [light|deep|force|screen|charging|network]

As of the Android Nougat Developer Preview 4, Doze has the following states:

Light: ACTIVE -> IDLE -> IDLE_MAINTENANCE -> OVERRIDE
Deep: ACTIVE -> IDLE_PENDING -> SENSING -> LOCATING -> IDLE -> IDLE_MAINTENANCE

The OVERRIDE state is activated when Deep-Doze is either in the IDLE or IDLE_MAINTENANCE modes because Light-Doze has no effect once the device has gone into Deep-Doze Mode. The device will exit Doze when you turn the screen back on, but be sure to run the following command so that your device correctly displays your battery percentage and USB connection state after you are done testing:

$ adb shell dumpsys battery reset

More Information

I’ve written a quick little logging app that will display some of the effects of Doze Mode on Jobs and Alarms. The app will simply log out the current state when a Job/Alarm is kicked off, as well as logging when the device has stepped into idle mode. All of the log statements are written to disk so that you can view them in the app if you wish to test your device in real world usage. Otherwise, simply keep track of the log statements in the device log.

Looking for more information related to Doze? Here are some resources I found helpful in my dive into Doze:

• Doze Documentation: Explains Doze Mode and the related restrictions App Standby applies to unused applications on the phone.
• Doze Behaviour Changes: Changes to Doze Mode coming in Android Nougat.
• Android Nougat: More dozing without more code A brief video from the Google Developer Relations team covering the changes coming in Android Nougat.
• DeviceIdleController.java: Internal hidden class the system uses to drive through the different states of Doze Mode.
• Doze Google+ Post: Quick summary of Doze Mode by Joanna Smith of the Google Developer Relations team.
• FCM/GCM and Doze: Google Blog post covering how Google Cloud Messaging handles Doze in Android Marshmallow.

Hopefully I’ve demystified what Doze brings to the table and the new optimizations added in Android Nougat. I am a huge fan of what Doze Mode has done for my device’s battery life, and I can’t wait to see what comes next!

The post Diving into Doze Mode for Developers appeared first on Big Nerd Ranch.

Another Google I/O keynote has come and gone, and we’ve been given a peek into many of the new products and technologies Google will be focusing on for the next year. If I had to give this year a theme, it would be a focus of joining and evolving existing technologies into new products and features.

AI is Taking Over the World

Well not yet, but you might have had that takeway after the first 40 minutes of the keynote. We were introduced to Google’s rebrand of rich search results, Google Assistant, with the aim of leveraging significant breakthroughs in machine learning and voice recognition to help in your everyday life. Google Assistant has been improved to feel more conversational, with knowledge graph of over 1 billion entities (people, places, things), so that it can provide the information you are asking of it without feeling like you are talking to a computer. Many of these services have been available for a while in Google search, but where they shine is in the interactions with the two new products Google announced.

The first had been rumored for the past week: Google Home, a voice controlled speaker fully hooked into Google Assistant and other Google technologies. Being called a response to the success of Amazon’s Echo, the Google Home is an evolution of voice search allowing for quick interactions from anywhere in your home. Allowing for activities like setting alarms and timers, controlling smart devices, sending playback to your Chromecast devices, and in future releases integrating with developers to integrate their own services. The biggest feature is how Google has applied advances in natural language processing so that queries to the device are more like a conversation, less like a structured search query. Unfortunately a release date has not been announced, but I can’t wait to see it in action soon.

Google also announced a new messaging platform called Allo, together with some unique integrations into existing Google technologies. Allo has all the features one would expect from a chat client: emojis and stickers for fun communication, image sharing, encryption and more. Where it begins to stand out is with the quick reply integrations Google has pulled in from Inbox. Just like Inbox, Allo will read the last message sent to you and offer three replies based on chat patterns seen in your conversations and other similar conversations it has seen before, perfect for a quick acknowledgement to a message. More impressive, quick reply will also apply to respond to images, applying Google’s vast image processing knowledge to quickly identify what has been sent to you and how you might reply.

Android Has Evolved Yet Again

Though we didn’t get a reveal as to what Android N will be named, we were given a nice overview of the new features coming available in this next version of Android. On the developer side we were introduced to a new layout, ConstraintLayout, that allows for flexible grouping of views that can adapt to size changes with less programming effort than previously required. Currently in Alpha, ConstraintLayout will be coming to the support library for easy integration across API levels.

At a quick glance, it seems like Android developers may be needing to support many new features, however when you take a closer look many of these features are leveraging existing frameworks within Android. Multi window mode is finally official on Android after being previewed last year, allowing users to resize their apps into smaller windows and have multiple applications running at once. From a developer perspective this is just a smaller screen size that they may have to support and always have the option to opt out of. Similarly, users will have an additional accessibility setting that allows for increasing the size of the entire UI, a much better solution for those hard of sight users than just increasing the text size, but only a change in screen density for the developer.

The announcement of Android Instant Apps was perhaps the biggest change announced to the Android platform. Developers can now segment their apps into modules. These modules can be used without ever downloading the full app from the Google Play Store. Details are still scarce on how this will work on the developer side, but the impact is huge for the user and applications. Users will be able to quickly open up an app that they do not currently have installed but may have come up in a search or from a chat with a friend, and get the full experience without having to go through the painful process of installing the app first. Hopefully leading to more installations if you have proven to your users how great life is with your app after small taste of it.

There are many more features coming with Android N: Java 8 language support (lambdas!), Doze mode on the go, bundled notifications, notification quick reply, quick settings, multi-locale, Firebase integrations and more! I know all of us here at Big Nerd Ranch will be eagerly exploring these APIs and hope to bring you more in depth looks at how you can leverage more of these new features in your apps.

Want to know more about the latest and greatest from Google? We’re looking forward to a lot of great new things from Google I/O 2016, and we want to share them with you. Fill out this form and we’ll be in touch with updates.

The post Google I/O 2016: Joining and Evolving appeared first on Big Nerd Ranch.

I was one of five lucky Nerds who got to attend Apple’s WWDC this year, and it has been a blast so far. The keynote was probably the most exciting in terms of the big-picture changes coming from Apple. Interestingly enough, the big picture means focusing on the little things.

The small details

iOS 7 brings a whole new interface, one that pays attention to the small details that define the total experience. The new look is centered on the idea of simplicity and efficiency, bringing order to complexity, as Jony Ive said. What this has served to remind me of is the complexity involved in making an app feel and look easy to use.

By now you’ve probably seen images of Apple’s re-design of several of the apps. Gone are the days of faux leather; instead we now have a systemwide flatter, more minimalistic look. As with any change, opinions on this shift will range from extremely negative to very positive, but one thing is for certain: it’s here to stay.

Changes for developers

Apple has gone all in with these changes and in a way forced the hand of developers from here on out. Consistency is one of the pillars of the iPhone/iPad ecosystem, and users enjoy having a common look, feel and experience across all of their apps. With Apple updating all of the stock apps, users will become accustomed to the new way of interacting with apps. Going back with the edge of the screen, fluid transitions between screens, and translucent views will all become second nature to the user. This means that users will begin to expect the same from third-party apps.

This doesn’t mean developers should immediately freak out and start working weekends to revamp their apps to match the new look. On the other hand, if your app has a custom UI that you’ve worked on over the years, you may be telling yourself, “I don’t need to make any changes. My app already looks great.”

I feel that these are both the wrong approach.

A deeper look

Instead, iOS 7 warrants a deeper look at the app and its functionality. One of the things that Apple made clear was that they did not simply go about changing how things look. Instead, they focused on the experience and how things feel for the user. The word game Letterpress was given a 2013 Apple Design award because it “stands out for its beautifully understated game interface, simple gestures, subtle animations and restrained sound design.” So you can see that it’s not just changes in appearance that are important.

In all, I love Apple’s new change in design, and not entirely based on they way it looks. More importantly, I like the fact that the platform is evolving and changing, instead of clinging to what has worked in the past. Apple is forcing developers to look at their apps once again, and to think about how they can improve their experience. Developers will look at what Apple has done and “steal” certain features, but also will improve upon others, helping sustain the rich environment of apps that the iOS platform is known for.

The post WWDC 2013: Focusing on the little things appeared first on Big Nerd Ranch.