Today’s tip is going to be short and sweet. I was testing an internal library that I had little experience with a few days ago, when I noticed that for one method invocation I had reversed the inputs. This was partially to do with the lack of documentation and the fact that this legacy library lacked human readable parameter names, but I digress. The problem I had was that this method invocation was used enough that I didn’t want to swap all of the values by hand.
It's no doubt that Android Studio gets better with every version. Who doesn't love Instant Run? There is one thing I am sad to see change without mention. Test Artifacts are merged together by default now.
In October of 2014 a friend and past colleague of mine, Mustafa Ali, wrote a great Medium article to help solve a problem that many Android developers have encountered at one point in their career. The Dex method issue in short is a limit to the amount of executable methods allowed in Android's Dalvik Executable file (the one used to execute Android code). Shortly after writing his guide Google did the unthinkable... they released a support library. The library creates multiple dex files to help apps that are large get around the single dex file limit issue. Though this is a great solution for large apps Google suggests to use Proguard to strip your app of unused code or to reduce your dependency on libraries as a whole. The former is much easier than the latter.
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.
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.
“We can just port this from iOS to Android” If you are an Android engineer then chances are you have heard this phrase many times in the past few years. It may even be because of this phrase that you are here today. I am no exception to this quandary, numerous times in my career I have found myself responding to this question or others like it. The first time I heard this I became irritated because certainly any designer working in the mobile industry already knew everything about Android. I quickly realized that this wasn’t one person neglecting the beloved Android platform. The problem is a lack of day to day experience with the platform. From that day forward I decided I will not contribute to the growing divide between the Android organization and the rest of my company. That was the day I became an advocate for Android.
I am not one to generally praise Fragments, its mostly the navigational stack that always seem to give me a plethora of issues. Having said that, its comforting to find something that works the way you would expect. A few days ago I found that at the intersection of the Fragment and the Toolbar (formerly known as the Actionbar).
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.
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.
Process can be a double edged sword for many developers. I know personally the first time I learned about the different processes for making software I had tons of questions and also thought, “Why the hell do I need this?” After I realized the power that process had in making development more efficient and effortless, I noticed this process wasn’t only helpful for teams building software, but also for helping one tackle day-to-day tasks. Speaking with some of my friends and co-workers I discovered that most people have unknowingly created the same type of personal process to handle their work, which isn’t heavily rehearsed or planned. For a long time this was how my process was, finish a task move on to the next and triage any larger issues as they arise. About a year ago that changed and my process not only started to fail me, but I started to drown because my process didn’t allow me to scale easily. That being said, I set out to improve my process to help scale with the new responsibilities that I have.
My personal process started out very lightweight, as a contributor to a project my day-to-day was taking task from Jira, developing them and then putting them up for code review. Outside of that I would normally have to triage handling code reviews for other members of our team. This was the extent of my day-to-day and because my team’s process limited the amount of work we could do per two weeks I never felt overwhelmed or stressed.
This worked until I started to take on more of a leadership role for the project. My day quickly became more involved with juggling the release of our app to the play store, working with our customer’s dev and server teams for services and tools updates and outages, all the way to helping guide our customer for product decisions and technologies to use. Not to mention my usual day-to-day development and now meetings…way too many meetings.
This didn’t leave time for me to explore new technologies, develop prototypes or expand my development chops. I had emails I had to respond to, Jira tasks to finish, Google docs I needed to respond to or review, Confluence pages to update, builds to fix and technologies to investigate for my customer. In many ways this problem could have been solved simply by having enough people to split all the tasks amongst. However, as these things usually go, we were down a developer, had a tight deadline and a new team that had less context of the project.
How did I transform my process
I realized that I didn’t have one place to aggregate all of my tasks and because of that I was juggling numerous software sometimes just to get minor updates for portions of my tasks. So one of the first things I did was try and group my tasks together so that I could tackle numerous things each time I went into that specific software. For instance, when I went into Jira not only did I respond to any comments left for me, but I checked on everyone elses tasks to see if there was anything blocking them. I also looked at any new bugs that came in and triaged those, as well as got a general overview of our Jira boards. When I checked my email I tried to respond to everything in my inbox and sift through any crap that was just sitting in there. I found that this helped, but only if I had enough time to devote to each of these tools to keep the proverbial inbox from becoming too full.
I knew I was on to something though so I took another step back after setting up this initial process and I saw something interesting when I did. I could easily group these tasks (generally through email) into groups and even sub groups which I could prioritize based on more contextual knowledge of what is important to get done for each day. So for instance, I could group all my Jira emails for my project and then sub group those based off things like tickets I have been mentioned in, new tickets that have been created, etc. This meant that I could easily see from these folders the areas that I needed to attack at that moment, versus things that I could wait until later in the day.
I finally settled on a process that was starting to work for me. All of these tools sent email to my work account which were then filtered out of my inbox into their specific folder leaving my inbox to one off emails or things that require more immediate response. I accomplished this through using search queries in Gmail to be the backbone of each of my folders. Thankfully Google has a list of advanced search operators you can use which proved helpful in creating these.
After a few weeks of tweaking these queries and finding my sweet spot, I still had a major issue. The issue was that there was still this unnatural flow that using Gmail caused which didn’t allow me to prioritize items for each day. I had to understand what from each label was created on that day or before and that required a mental mapping that seemed a bit unnecessary. So after searching high and low I found a task application that seemed promising. Before settling on Todoist I tried almost every other under the sun including: Gmail Tasks, Google Keep, Anydo and GTask. The reason Todoist became the frontrunner for me were a few simple things that most task software didn’t have.
Integration with IFTTT (If This Than That) which allowed for me to trigger task creation when a new message was added to a label in gmail Tracking tasks for projects and tagging There is a mac app, web app and android app
This meant that IFTTT could do all of the heavy lifting for getting my emails into tasks and I could use email for its original intention… to communicate with others. Now in a perfect world I wouldn’t need Gmail to be the bottleneck for all task creation. I could write plugins for all of these tools to achieve the same results. Besides the fact that this would mean creating, maintaining and integrating with IFTTT my own custom code, all of these tools I am using are my customer’s and they have a fairly strict policy as far as custom integrations on their tech stack. So for all intents and purposes email can act as the middleman for me and also demonstrates how easy it is to take your email account back from the all of these constant automated messages.
So rather than just tell the story of my journey, I figured I would also give some examples for developers like myself to help possibly make your day-to-day better.
The build system my project is currently using is Jenkins. Jenkins will send out emails to any person who breaks a build or when a build is back to normal. I set up a few IFTTT triggers for this because not only did I want to make sure I had a task, but I also wanted to make sure my team was aware of the break or when the build was back to normal.
Google Filter Query:
New Builds are Ready
As you could probably tell from my previous example our team uses Slack as our means of communication. We all really dislike email so we have explored every option possible and finally ended up on Slack. Thankfully Slack integrates well with IFTTT so I came up with our new build trigger which happens when a new build is ready via Hockey App.
Google Filter Query:
You are mentioned in Jira
This was a really important one for me. When you subscribe to a jira task you will generally get a notification or email for every single note added to the ticket. This is great if you care to get every notification, but if you don’t and only want one when you are mentioned this is the IFTTT for you.
Google Filter Query:
This is nowhere near an exhausted topic and I am sure I will do a follow up as time goes on and things change for me and my process. The important thing I learned from this whole experience is that having and constantly updating a personal process is key to be successful at handling information overload.
I would love to hear about your process and what you have done so leave a comment below or tweet me @Echenger.
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.
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.
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
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
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.