Styles and Themes are a great thing. They allow us to abstract common view properties into a single location, making the look and feel of our application UI more consistent and easier to maintain. If you look at Google’s UI guide for Styles and Themes, it mentions the motivation behind this as a separation between design logic and content.
In the last post, we walked through the core functionality necessary for building a RecyclerView LayoutManager. In this post, we are going to add support for a few additional features that the average adapter-based view is expected to have.
By now, if you’re an Android developer paying any attention, you’ve at least heard of RecyclerView; a new component that will be added to the support library to facilitate custom implementations of high-performance view collections by facilitating view recycling. Others have already done a remarkable job describing the basics of how to use RecyclerView with the built-in pieces already provided, including item animations.
WWDC 2014 was packed with new features for developers to take advantage of in iOS 8.
Among them were technologies that present new opportunities for accessory manufacturers, but often the technical side of that development doesn’t get the coverage it deserves. What follows is a discussion of what accessory manufacturers should be excited about (we certainly are!) as we look forward to the iOS 8 release.
Digging into ActivityManagerService reveals a bit about how applications are killed.
Between process management of the system at large and user behavior, there are a handful of methods through which your Android application process may terminate. The additional effects on your application code (based on the method) may have consequences for you as a developer.
I have been focused primarily on the Android platform for about 5 years, so the Intents framework is pretty much a part of my DNA at this point. When Twitter went aflame with “iOS has Intents! #WWDC” tweets during last week’s keynote, I sat up and took notice. Could it be? What follows are the things I have observed about what the two frameworks now have in common, and where they divide.
Much has been said lately about Android’s external storage in the tech press. I’ll be the first to admit that what we have now seems like a bit of a mess at first.
With all the interest focused on the subject, I felt it an opportune time to take a moment and explain in detail exactly how external storage permissions work, both in the past framework versions and today in KitKat.
The skill that separates good Android developers from great ones is the ability to understand how the platform works through an ability to efficiently navigate through the source.
Say what you will about open vs. closed systems and their associated pros and cons, but one of the most instructive tools that you have at your fingertips as an Android developer is the fact that the source code for the framework you are interacting with is readily available. You need look no further to answer the question “I wonder how they did that?”
The ability to create a new Home/Launcher application for your Android device is not a new concept. There’s even a sample application in the SDK that shows you exactly what needs to be implemented in a 3rd party application that wishes to act as the Home/Launcher of the device.
Until now, we could expect that the Home/Launcher application on the Android images for the Nexus devices would be the open sourced Launcher package in AOSP (Launcher, Launcher2, or Launcher3 depending on Android version). But, when the Nexus 5 device shipped recently (and subsequently factory images for the rest of the Nexus line to get Android 4.4), all of that changed.
Bluetooth Low Energy (or LE) is a very cool technology. The possibilities it enables for the connected world via mobile devices are simply amazing. Thanks to my friends over at NewCircle, we recorded a video tutorial for building this new technology into your Android applications.