I was talking with friends about the upcoming FIFA World Cup 2014 and we wanted to look up some facts online to settle an argument using the official FIFA Mobile App. When we noticed the official FIFA app in the Google Play store, I was curious why so many of the recent reviews were poorly rated. While the app still had an overall decent average rating, upon further investigation it appeared that a recent update has been tanking user experiences.
As my field of interest (private and professional) is mobile user experience, I continued to install it against the recommendations of many users, as I wanted to learn more about the actual problems. It would also be a great test bed for the new Auto Instrumentation feature our APM team is working on that makes it easy for anybody to monitor Mobile Real User Experience. It allows you to not only figure out visit duration, and user actions, but also performance, and functional errors as well as crashes.
As a fan of the game, I hope that with this post, FIFA might feel enabled to identify and analyze these problems in preparation for the fast approaching World Cup. I performed the tests you’ll see below just using my Samsung Galaxy S2 and a performance management tool to identify why the app keeps crashing.
Like many of the recent user complaints, I experienced force-close issues upon initial start-up.
Since I couldn’t get the app to start properly on my device, I decided to rerun the app, but this time including our Mobile Agent hoping that it will crash again so I can learn more about the actual root cause. To my surprise the app crashed consistently at different crash locations. Let’s take a closer look at them:
CRASH 1: IndexOutOfBound Exception when viewing the team of Brazil
It looks like the first crash occurs when someone tries to access the first element out of an empty list, or tries to access an element by index without checking the array size. The developers are definitely not using an iterator because this would have done the check for them. So – first thing to do is check your array size before accessing elements.
I was so excited about the first crash that I forgot what the exact steps were to reproduce it after the first analysis session. The only thing I remembered was that it had to do with checking out the Brazilian Team. Fortunately our solution captured all the user actions I executed before the crash occurred. So I had all the steps protocoled for me to reproduce it. The following screenshot shows these steps which I simply followed. Executing them resulted in yet another crash.
CRASH 2: java.lang.NullPointerException due to old third party Library
This crash was an interesting one where Stephan BrunnerAndroid Head Developer at Runtastic helped me with the analysis. He immediately said: “We had that problem a while ago as well, due to a bug in a third party library. You should no longer use that library as it is deprecated and the main developer of the library Chris Banes points to the Google Support Package that holds the better implementation now.”
CRASH 3: SQLiteDatabaseLockedException after trying to get some “news” from within the app
The app also failed to load the news on the initial page. I thought to give it some more time and wait – maybe it was caused by a slow connection with the server. After a while I clicked on the News button which caused the app to crash again. I also tried to reproduce this and found out that it only happens when I wait for about 30s before clicking the News button. I discovered that by looking at the visit duration captured for all of my attempts and analyzing the time difference between the initial loading and the touch on the News.
As I cannot take a look at the source code I cannot say for sure what is going on but it seems that there is a background job doing something with the SQLite database. The touch triggers some activity to the
database that finally leads to a SQLiteDatabaseLockedException. This could be a multithreading issue when both the initial page request and the request triggered by my click on the News try to access the database. Other than on common databases used on server-side implementations (MySql, Oracle, MS SQL, etc.) the SQLite database itself is not aware of multithreading and the development team has to take care of this.
A mobile user’s experience is not all about crashes, but also about the performance and responsiveness of the app. As the app has to load a lot of content (images, videos, statistics, etc.) FIFA should also look at key performance timings of requests executed by the app. The following screenshot shows the distribution of the Response Time of all executed requests grouped by host domains. We can see that most requests are executing under 1 sec – that’s considered fast.
What surprised me was the sheer amount of requests executed during my tests, which reminded me of a problem pattern that is common in Web Development. Here is an example: When viewing the list of teams the country’s flag gets requested for each team individually instead of downloading the 32 flags as a single “sprite.” This might become a problem during peak times for the mobile app as well as for the datacenter that needs to serve a much higher number of requests as necessary. Details on this will be discussed in the next blog.
In preparation for an event like the FIFA World Cup the IT behind the event has to be prepared in order to have happy fans before and throughout the event. Make sure that when you create an app for the event it comes equipped with a Real User Monitoring solution so that you can react to functional and performance issues quickly.
I hope that the FIFA and their contractors are using the time left to fix most of the problems and are ready when the World Cup 2014 kicks off. The Clock is ticking! I’m happy to discuss things further, feel free to contact me in the comments or at @kenzenhofer.