Decompling Failure

My company decided to roll out a product that allows us to take screenshots of key pages on our mobile app.  This in theory gives us a better tool to help us diagnose problems that our clients have.  If a client calls up after having an issue, we can see what they saw.  It gives us a better understanding of what happened without having to go through server logs.  Developers tend to be find looking at logs, but our Tier-1 support, the people who take the phone calls, might not want to look at logs.  We were provided with a jar file, some example code and some documentation.  This seemed like an easy project.  Boy we were wrong.

The first thing most people think would be a problem is bandwidth, but that wasn't an issue.  Keep in mine this is only for a small set of key screens, so it shouldn't take a lot of bandwidth.  The first issue was actually related to scrollable pages.  Now, you'd think a library to that takes screenshots for you would......work.  You would be wrong.  The problem lies in the fact that the tool only takes a screenshot of the visible part of the page.  We put in a support ticket and got a response:  we were doing it wrong!  You see, we should have read the documentation.  What did we do wrong?  We have no clue.  The response just said read the documentation!  We responded back with a politically friendly "WTF" and then they dropped this helpful nugget.  If you want to take a screenshot of the entire page, you have to attach a scroll listener and wait for the user to scroll there.  Now you are taking lots of screenshots with no guarantee that you will see the entire page.  We quickly rejected that.  Thefore, they responded with "read the documentation".  WTF!

One of our developers researched taking our own screenshots of the scrollable view and she figured it out.  We suggested that they add an API call to allow us to send our own screenshot to their server.  We liked this idea since this is actually how the iOS library that the company supports works.  They rejected the request citing the fact that the Android library should already do what we need it to do.  After 7 back-and-forths, they wrote a response saying that it is the responsibility of our developer to take the screenshot at the write place.  They just provide the screenshot tool.  Our product owner (the person in our company that talks to the vendor on a regular basis) forwards that email to a lot of managers, saying it is my fault (they didn't drop my name of CC me in the email, but it was obvious they meant me).  That is when I broke out the decompiler.  I decompiled the jar file into java source code.  I then followed the call stack we were using to take the screenshot.  That is when I find the issue.  The API has us pass in the View that we want a screenshot of.  The screenshot code actually takes a screenshot of View.getRootView(), though.  The support team for this vendor implied I was the idiot, so I had to decompile their code to prove they had no clue what they were talking about.

Our next major issue was with the "kill switch".  The kill switch allows us (in theory) to remotely disable the screenshot library in the event of an unforeseen issue.  If you ever had an issue with an app in the store, then you realize the importance of disabling functionality without resubmitting to the store.  The documentation states that you create a url that returns a single character, a 1 or a 0.  If the webpage returns a 1, then the library is enabled.  If the webpage returns a 0, then the library is disabled.  We enable the kill switch configuration and the library stops working.  It doesn't matter if its a 1 or a 0; it always disabled itself on both Android and iOS.  Then we get a call from our product owner saying we were doing it wrong.  They claimed the documentation said nothing about a 1 or a 0.  They claimed we needed to send either an HTTP status code of 200 or 500 to enable or disable.  We started pouring over the documentation.  What we determined was the Android documentation said to use 1 or 0.  The iOS documentation on the other hand tells us to use the HTTP status code in one place and the 1 or 0 in another place.  The iOS documentation literally contradicted itself.

We ended up ripping the entire product out of the current release, completely wasting my time.  We decided to revisit it for our next release.