I think it is fair to say that most of us are super happy with how nullability is handled in Kotlin. The overall code that we are writing with nullability in mind is mostly cleaner looking and helps us avoid the pitfalls we saw in Java. Having said that *Platform Types* are a place in particular that I ran into where I feel like the developer experience and the impact to the user is worse. If you are not aware, *[Platform Types][1]* are types that were created when Kotlin cannot infer the nullability of a type from Java.
Gradle 4.1 Task Dependencies
While migrating to Gradle 4.1 an Android Gradle Plugin we discovered and issue that wasn’t documented. I would love to share this issue with you and explain how we fixed the problem.
Re: Chathead Basics
In Pierre-Yves Ricau's blog from 2013 he walks you through how to make a very basic version of Facebook's Chatheads, which if you haven't read is a great read and is yet another reason why I love Android. At the end of his blog he asked the question:
"Does this imply that Facebook Chatheads (or any application with SYSTEM_ALERT_WINDOW permission) is able to conduct keylogging and take screenshots at arbitrary time?"
It was a great question but after trying to explore more with adding views directly to the window I think I found another concern.
Android Studio Tip #001: Bookmarks and Favorites
Chances are if you are an Android developer there are a bunch of really amazing features hiding in Android Studio that you have probably yet to discover. I am definitely not the exception to that and yesterday I stumbled upon (/took the time to understand) a few features that have so far made my life much easier. These features are Bookmarks and Favorites.
Mockito Verify Inconsistency
When I initially set out to blog about Mockito I wanted to write a post where I explained the Verify API. Though there wasn't much in the realm of posts around this topic, I think that the javadocs have ample examples. Maybe the only topic that would be worth covering for a second post would be good places to use Verify. I recently have been working a lot with the Verify API and found some inconsistencies that I wanted to share so that if you are using Mockito you can avoid the pain I had. So here it is two weeks later and here is my post about some caveats while using the Verify API.
What developers should care about at I/O this year
Every year for the past 7 years the tech industry, financial analysts and tech aficionados alike post numerous blogs with rumors about the years I/O. This year is no exception. To give a different perspective, and maybe an altogether different approach, I have decided to come up with a few major things that Android developers should care about this I/O.
How do I develop a watch face for Android Wear?
What I want from Google Maps SDK for Android
For the past two months Google Maps and mapping has consumed a large portion of my life. During this time I have come to love and hate Google Maps V2. Besides just writing up a couple of issue trackers, I figured I would share my findings in hopes that it saves another developer the stress.
Touch Listeners
User input is super critical to be able to build robust mobile applications. The maps SDK falls short at providing developers the ability to differentiate between user input and programmatic camera changes. Currently the only way to tell that the user has interacted with the map is through the onCameraChangeListnener which should be considered a hack more than anything else. The API docs even go as far to say:
During an animation, this listener may not be notified of intermediate camera positions.
The simple fact that it may or may not be notified is a bit irritating to me. I would rather the API draw a line in the sand and either give me all of the changes or just the beginning and the end. I would say for simplicity's sake it would make sense to just give us the update at the end of the animation, then create a new listener for map touch events. Even just the basic touch up and down events would be a huge win.
Markers
A large part of the reason for having a map in your application is to visualize data or information. One tool Google gives us to do this is the marker, in essence a bitmap that represents a location on the map. Though it is probably the most utilized component of the maps SDK it is one of the most underwhelming. Lets take for instance marker animations. If you have done Android development before you would assume that the marker could be animated the same way as any other View. Unfortunately Marker is not a subclass of View so all of the base property animations are off limits. Instead the only field that is worth animating, position, relegates you to simple translations of xy, through the LatLng.
There is also some weirdness when trying to change a markers bitmap after it has been instantiated. The weirdness manifests itself as an IllegalManifestArgumentException when using the setIcon() method. Now Google hasn't officially responded to the issue and the status is marked as needs more info. I am hoping that they will have an answer soon, but until they do I am including this in my wish list. As of the writing of this post, the best way to side step this issue is to remove the marker and re-create the marker with the new bitmap you would like. Not the best of solutions, but I have not seen anything more staright forward.
Overall, a large portion of professional Android development right now is working with 3rd party SDKs and when doing so there is an inherent risk that we as developers assume. For me, the risk of having these issues or deficiencies in Google Maps was not enough to warrant me to look elsewhere for mapping SDKs, but the feature set put before me didn't create that restriction. Though Google Maps is a completely adequate tool, I would love to see more granular control for developers as well as better methods of communicating changes from the user to the developer.