Why I Use Crashlytics – Part 2

Why I Use Crashlytics Part 2

In Part 1, I discussed how to set up Crashlytics to get intricate data about the crashes, devices, and how to easily view this data from within Android Studio. In this article I’m going to discuss how this data can help you fix the most critical crashes with minimal effort and create happy users and customers for your business. I’ll also talk about how I use Crashlytics in an application that is very large in scale.

 

The Beauty is in the Details

 

One of the great things about Crashlytics is the level of detail you’re given when a crash occurs. As a product manager, dev lead or engineer you’re able to quickly assess the risk the crash poses to your overall install base. With the device and operating system breakdown you can determine if a particular crash is only occurring on Android 2.x or everywhere (or another version). You can determine if the crash is affecting only a particular device manufacturer. This is a tremendous help.

 

One of the things I’ve done with my clients to help assess the risk of a particular issue is to juxtapose the issue statistics vs. the statistics from Answers by Crashlytics, Crashlytics’ new mobile analytics service (as shown below). Using this information I can determine if the majority of my users are exposed to this issue simply by looking the users count from Crashlytics’ crash reporting as well as the daily active users count for the OS version and the daily active users count for device from Answers. This data will provides me with the insight to determine if the issue is severe or just an edge case that is rarely hit (the issue count really helps here and is covered in the next section in more detail).

 

A sample screenshot of Answers by Crashlytics providing the Daily Active Users by Operating System (OS).

 

 

A sample screenshot of Daily Active Users by Device Type.

 

These charts provide tons of great info that you can compare to the issues in Crashlytics. If your app is generating an error occasionally it’s easy to determine what to fix, how to fix it, and when to fix the issue. However, when your app is at scale (millions of users on thousands of types of devices) then this process gets a bit more involved. I’ve learned to rely on Crashlytics in helping to determine what issues need to be resolved quickly. In doing so we have developed a set of steps that help us mitigate risk when new issues arise on the MyFitnessPal app.

 

App Scale and Implementing Post Release Risk Mitigation

 

Crashlytics is good for small and large apps but it really starts to shine when it’s run in an app that is at scale (millions of users/installs) because you start seeing issues you’ve never experienced or even thought could occur in your app. You will get reports of crashes in 3rd party frameworks (like ad frameworks, etc.) as well as other libraries along the way.

 

At MyFitnessPal Crashlytics has helped us catch an enormous amount of issues. Because Crashlytics exposed the issues quickly and accurately with a lot of details we have been able to assess the issues sooner and with greater confidence. Using the tool has also cut costs dramatically as well since it is a free product. Our risk analysis process helps us determine if the issue needs to be immediately fixed via hotfix or if the issue is mild enough to wait for the next dot release (a dot release would be moving from 3.0.1 to 3.0.2 or from 3.0 to 3.1 – it varies from company to company).

 

The Dashboard and Risk Review

 

I feel it’s important to see the Crashlytics dashboard for an app that has millions of installs because that level of detail that we have that helps determine our next course of action. The screenshot below is the Crashlytics Dashboard for the MyFitnessPal Android App as of the latter half of May 2014.

Crashlytics dashboard for the MyFitnessPal Android Application

 

 

The dashboard view provides a great number of details as outlined by table below.

 

 

1.

App / Package Name

The application name and package name.

2.

Version Selector

Select a version to inspect or view all versions of your app in aggregate. I have selected version 3.1.1 (4685). This is the  version name (3.1.1) and the version code (4685) that is in your AndroidManifest.xml. The selected version relates to #12 below.

3.

Open / Closed issues

Toggle between open and closed issues or display all.

4.

Crash / Non-Fatals

Toggle between Crashes and Non-Fatal issues.

5.

Date/Time Selector

Select a time or date range for the issues that you want to inspect.

6.

Search

Search for logs, keys, issues, etc.

7.

Issue Total

Total number of  issues that have been created as a result of various crashes and non-fatals for the selected version / total of number of  issues for crashes and non-fatals for the entire application if ‘All’ is selected.

8.

Total Crashes and Total Non-Fatals with User Counts

The total number of non-fatal crashes and the total number of users affected by the non-fatal crashes. Directly beneath this is the total number of  crashes and total number of users affected by the crashes.

9.

Time / Date Range Chart

A visual chart representation of the number of crashes over a given time.

10.

Issue List Count for Severity / Select All

The total number of crashes for the given severity. The severity of the issue is ranked by Crashlytics on a 1-5 scale. In this screen shot you will notice 5/5 bars are blue. This means this issue is a severity level 5 (highest severity). You can also use the checkbox next to the issue count to select all issues in the list and perform mass editing.

11.

Issue

This is the issue line. It shows the issue ID (#26909) as well as other info about the issue. The root source code cause is shown with line number.  Click on this to visit the issue detail page as shown earlier in this article.

12.

Version Number

The version number of the application when the crash occurred. If you have ‘All’ selected in the version selector, you will see various values in this column in the list. Since I have selected ‘3.1.1  (4685)’ in the version selector all of the issues in the list will have the same value here.

13.

Crash Count

Total number of crashes this issue has caused.

14.

Affected Users Count

The total number of users that this issue has affected.

 

Using the data above along with the data in Crashlytics Answers you can gauge your risk quite easily. An additional bonus that you get for free by using Crashlytics is that their severity ranking on Crashlytics is pretty accurate and is a good place to start when assessing risk. I’m not sure of the exact implementation of their severity algorithm but it seems to be a combination of crash occurrence/issue persistence (does it continually keep happening) and breadth of the crash across Android OS and devices combined with affected users.

 

The risk analysis is pretty simple. Once you release a new version of your app. Check the Crashlytics dashboard daily and perform the following review:

 

Look for the highest occurring crash across the breadth of installs across the various OS’s.

 

Example: If a crash is only affecting Droid Razr devices running Android 2.3.9 and our install base says 0.03% of our users use this device and that accounts for .001% of our total users  … well .. its probably not that big of an issue. However, if we see that we have a crash occurring on all Samsung S3 and Samsung S4 devices with Android 4.+ and our install numbers prove that this accounts for 60% of our install and/or user base, then that means we have a higher priority issue that probably needs a hotfix. We’ll need to be ship the hotfix as soon as possible in order to mitigate the risk of loss of existing and new users.

 

Below is how I perform a risk analysis for a crash. Please note, the first time you do this it will take a few extra minutes because you are cross-referencing data, but after you do it a few times the process will become VERY quick and you probably won’t need to reference Crashlytics Answers for the statistics as often. I do recommend that you still review your statistics in Crashlytics Answers every few weeks and at least once a month to make sure your heuristics are kept up to date (not to mention all the other great info in there – which should be a post in itself).

 

Crashlytics Issue Risk Analysis Steps

 

  1. Review the issue list and the following metrics:

    1. Severity (Crashlytics usually nails this pretty well). I always look at the 5/5’s first.

    2. Total number of crashes this issue has caused.

    3. Total number of users affected.

  2. Choose an issue you want to drill down into. Once the issue is opened in the issue details screen (as shown in the sections above) review the following metrics:

    1. Android Operating System Exposure – How many different OS’s are affected?

    2. Android Device Exposure – Percentage of various devices affected?

  3. Now cross reference these metrics with your current Crashlytics Answers statistics to find the most popular Android Devices and Android OS’s for your app. Do not skip this step!This is different for every app and every market!

    1. Record/Remember the Top 80% of Android OS: Usually the first 3-5 are going to represent your 80%

    2. Record/Remember the Top 10 Android Devices – As your app grows in install base (especially when you trend into the millions of installs) you will see that your top devices are usually around 100K installs to 1M+ installs on a particular device. Really pay attention to these devices because you’ll want to be able to quickly identify your top devices that might be affected.

  4. Determine if it’s a hotfix issue (an issue that needs to be fixed right now or can wait for the next release). Please note, each company’s risk tolerance is different than the next. Adjust to your own risk tolerance as you see fit. MyFitnessPal has a different risk tolerance than my news reading app. The numbers below are generalizations.

    1. If the issue is affecting more than 1% of your users, it’s definitely a hotfix issue.

      1. Again, this is highly subjective. If you have 10 users out of 1000 getting some really obscure error that rarely happens then you may want to hold off on fixing it. This is up to you. But at least you now have the data to come to that conclusion.

    2. If the issue is affecting one of your top devicesby more than 10% of the issue device ratio (Issue per device type) it’s probably a candidate for a hotfix release.

  5. If hotfix is necessary, simply update the source and ship an update and start this process again.

 

Caveat: If you feel the issue at hand is something that needs to be fixed immediately (metrics aside) then by all means, fix it. This is only a rough process which I use to help determine if I should fix an issue immediately or later. This is a general guideline I use, feel free to adjust accordingly.

 

 

Crashes at Scale

 

Another thing you’ll notice when your app gets to scale is that you start getting crash reports for your app that happen in parts of the code that you do not own. Examples of this include ad frameworks, open source libraries or commercial third party libs (charting, etc). When you encounter issues like this you have a few options:

 

  • Extend the class that is causing the issue (if possible) and fix the issue.

  • If the code is open source, fork it and fix it, submit a pull request to the open source project and ship the app with your forked code until the fix is in the open source project.

  • Contact the vendor and have them fix it.

 

I’ve used all three of these with mixed success. However, sometimes there is an error you simply cannot fix; for example, a bug in the Android framework (yes this does happen). Your best course of action is to try to catch the error in your source and gracefully handle it as Android OS updates do not happen that often on devices (unless the user is fortunate enough to be running a Nexus device – but even that gets limited and is slow).

 

 

Logging Exceptions with Crashlytics

 

Ok, the reports and data are great, but how do I log these exceptions!?!

 

Crash monitoring in Crashlytics is built in. You simply add it to your entry point of your application (as was done in the installation portion of the app via the plugin) and at that point crash reporting is handled for you. The reports are delivered over SSL so you don’t have to worry about the security of the information transmitted. The source for Crashlytics is quite small (~45kb) and minimally affects the startup time of your application. However, this is not the end of Crashlytics reach. It can do much more.

 

 

Logging Caught Exceptions

When writing an app you sometimes have to wrap your code in a try/catch. Maybe it’s a network failure you’re expecting, maybe it’s a file read/write issue or maybe it’s a null that sometimes happens when the app is in a certain state. These exceptions should not happen, but sometimes they do. You and your team do your best to handle these issues gracefully so that the app doesn’t crash. Unfortunately at the end of the day you don’t really have any idea how many times a particular exception is being caught. Crashlytics allows you to log caught exceptions like this:

 

Crashlytics.logException(e);

 

This will log the exception as a non-fatal exception in Crashlytics. You can review this data as you view a normal crash. All of the same data is displayed. Error line number, stack trace, OS, Device type, etc. This is shown below in a recent screenshot of a cross platform game I helped develop, QONQR.

 

Screenshot of the non-fatal exception details for the QONQR Android app. Here we have a problem with our onPause event inside of our QonqrMap activity in Android. We have since fixed it (as there is no data in the date chart) yet we leave it open for review as we’re making changes still.

 

User Information

At times in the debugging lifecycle you’ll find that particular crashes are only occurring for particular users. These issues can be especially hard to squash. To help track users and crashes Crashlytics allows you to log user information to help you identify a user. This is done with one of the following methods:

 

  • Crashlytics.setUserIdentifier(String identifier);

  • Crashlytics.setUserName(String name);

  • Crashlytics.setUserEmail(String email);

 

You can use the setUserIdentifier method to set a id, number or hashed value that uniquely identifies the user of your app without disclosing or transmitting any of their personal information. You can also use the other methods listed to send up data about the user.

 

Custom Keys

 

On top of user information it is also useful to keep track of context when a crash occurs. Context can help you pinpoint the root cause of an issue fairly quickly. Crashlytics allows you to log contextual data by using custom keys as such:

 

  • Crashlytics.setBool(String key, boolean value);

  • Crashlytics.setDouble(String key, double value);

  • Crashlytics.setFloat(String key, float value);

  • Crashlytics.setInt(String key, int value);

 

A couple example of how you could use this:

 

  • Crashlytics.setInt(“health_points”, 1337);

  • Crashlytics.setString(“last_action”, “logged-food-entry”);

 

This data is sent with the crash to Crashlytics and you can view it in the issue details screen. Please note, Crashlytics limits you to 64 key/values pairs though might allow more if you contact support.

 

Tips and Tricks

Below are a few tips and tricks I usually share with folks when they first start using Crashlytics. I hope they help you out.

 

Gradle Build Variants for Debug and Release Builds

Crashlytics apps are added automatically to the Organization via the package name. You can add some logic around the Crashlytics initialization so that it only runs during release mode. If you don’t do this you’ll run into some false positives in your Crashlytics dashboard. To get around this,  I use Gradle and build variants. Therefore, in debug mode my package name is com.donnfelker.myapp.debug and in release mode it is com.donnfelker.myapp. This helps me keep my development crashes out of my release crashes.

 

You can implement this with a simple build variant in Gradle like with this code (edit/remove the proguard config if you need to):

 

buildTypes {

       debug {

           packageNameSuffix ‘.debug’

       }

       release {

           proguardFile ‘proguard-project.txt’

       }

   }

 

Now when you build ‘.debug’ will be appended to the package name for debug builds. Please note, you will notice I have ProGuardincluded above. Crashlytics plugin will automatically upload the ProGuardmapping to Crashlytics so that your stack traces are not obfuscated! Awesome!

 

Fragment getActivity() is at least 50% of the Errors at First

This is an easy one. Over 50% (I’d go as far to say 80%) of the apps that use Fragments do not check for null when the getActivity() method is called. This results in a ton of NullPointerExceptions being thrown (this causes the app to crash).

 

Your new rule of thumb should be: getActivity() will ALWAYS be null. If you think that way, you will change the way you code when using getActivity() and in doing so you will always be checking for null. Doing that will save you a ton of crash reports.

 

NullPointerException is your Best Friend

Speaking of null pointer exceptions … As I’ve said in many of my presentations – expect everything to be be null especially getActivity() in a Fragment. The NullPointerException is one of the easiest exceptions to fix (when it’s in your code). These ones are quick hits – simply fix it, test it and ship it. These are real easy ones to do. But please note, at scale you will see more NullPointerExceptions than you ever thought you would, and a lot of them will be in places you least expected them to happen. Happy hunting. :)

 

Wrap Up

Since Android was introduced to the public in 2008 I’ve been developing apps for the Android platform. Many of my original apps were in the first 1000 published to the Android Market (now known as Google Play) and even during those times my major concern was around crash reporting. I’ve used a slew of tools over the years and while some have come close to the usability, cost, and feature set of Crashlytics none has yet to surpass it. Crashlytics is the first library I install on any app that is going to be released on Google Play or the Amazon App Store. It probably should be yours too.




Made possible by … 

A huge thank you goes out to Hemal from the Crashlytics team for all the help with the Crashlytics products, I couldn’t have done it without you. Thanks again!

 

FYI – Crashlytics also offers beta distribution through Beta by Crashlytics (kind of like Testflight, but its by Crashlytics) and mobile analytics with Answers by Crashlytics (which we briefly touched on in this article). Similar to the experience they deliver with crash reporting, these new services were a great tool to have in my toolbelt. If you use beta distribution or are looking for a strong mobile app analytics tool, you should definitely check them out.

 

Learn more about Crashlytics for Android.


This article was also posted in the Product Showcase section for sponsors at CodeProject. This review is intended to provide you with information that is considered useful and of value to developers.

Why I Use Crashlytics

I often get asked what libraries I use when writing new greenfield Android apps or what libraries I introduce when I start working for a new client when helping them with an existing application they already have in production. Of course I always rely on a few key libraries such as Dagger, Otto/RxJava, Retrofit and a few others but one I absolutely always use is Crashlytics.

 

Crashlytics is a free service offered by Twitter that collects your crashes and various other bits of information. Its very easy to setup and install and it instantly starts providing value as soon as you install it – yes, even in development. Its completely free, unlimited apps, unlimited users, unlimited crashes, unlimited keys, etc – its all free. I’m not joking when I say its the first thing I install. Without crash reporting I have no idea whats happening to my app in the wild (production).

 

Why Crash Reporting is Important

When your app crashes in production on a users device you need to know. The reason is simple – something happened that you did not expect. Perhaps you used an API that was not supported for your release (such as using Renderscripts InstrinsicBlur on API level 15 when that API was not released until 17). When this happens over and over, your users start to lose faith in your application and then the bad reviews start rolling in.

 

When you’re monitoring your crashes you’re able to assess the risk level that a particular crash is causing. For example, let’s assume that you release version 2.0 of your application. Upon doing so you introduced a bug on a particular screen. During development and testing you never ran into this issue but as soon as you released the update to your existing users you start getting inundated with crash reports. With a crash monitoring tool you can then observe that the crash is occurring on a particular screen because you’re given the stack trace of the crash. For some reason the crash is occurring on the getActivity() call of a Fragment – a NullPointerException to be exact. Upon further investigation you realize/remember that all getActivity() calls in Fragments can return null (and in production and at scale they will). You then implement the null check, and ship a hot fix version to address the issue at hand. This is a real world case I have witnessed many times for various clients. We would have never caught it without a crash reporting tool.

 

Not All Crash Reporting Tools are Created Equally

 

Prior to Crashlytics I installed various other crash reporting tools such as Bugsense, Crittercism, ACRA, HockeyApp and some others. The problems I encountered with these services were numerous and were different for each tool I used. Some of the issues I encountered included:

 

  • The tool was was hosted and the fees were outrageous

  • The tool was free, but did not scale unless I built out a backend API to support it

  • The integration was rather cumbersome

  • Account management was painful if not non-existent

    • eg:

      • Teams

      • organizations

  • Sharing bug reports was difficult

  • IDE integration was non-existent

  • If I used Proguard my stack traces were obfuscated so I could not fix the issue.

 

I usually ended up working with either ACRA or Bugsense prior to Crashlytics. ACRA for smaller apps that did not have much of a budget or very low user base and Bugsense for larger clients. I attempted to use HockeyApp a couple of times but my clients never got around to setting up accounts and found that they liked Bugsense more or prefered the cost of ACRA – FREE.

 

ACRA worked good, but one thing I noticed was that I never checked in on the Google Sheet where the crashes were sent. Unfortunately due to the way the crashes were stored in Google Sheets I found that they were not optimal for reading. The process of checking for new crashes was very poll based and I found this unfortunate. Sure, there were tools that did help in solving some of these problems but the solution was far from perfect, elegant or quick. I also did not have the statistics that I wanted, such as percentage of Android 2.x users affected vs Android 4.x users, etc. This kind of data really helps identify the impact of the crash. If your user base is 95% Android 4.x and the crash is occurring on Android 2.x  then your impact is rather low. When flipped in the other direction though, you have a very large set of users whom the crash is affecting and at that point different decisions need to be made (hot fix, etc). The key point here is that ACRA is not a fully baked solution in the way other advanced crash reporting tools are.

 

Bugsense and Crittercism (and other services) solved a lot of the issues I had with ACRA, but I found that the price point was a huge turn off for almost all of my clients. One of the great features of these services was a pushed based system that would notify you of when a new crash occurred. This could be via email, etc. Not having to log in and check manually was a huge time savings. My clients have either very large Android Apps (millions upon millions of installs/users) or very small (new startup, etc). The price point bodes problematic for both. On the lower end of the spectrum the new startup is trying to save money at every area possible and they don’t want to pay for crash reporting. Every penny affects their runway. Therefore we usually ended up with a sub-par solution like ACRA. On the upper end of the spectrum we had a different problem – application scale. These clients are at such a scale that the pricing tier they fall into simply says: “call us for a quote”. This usually equated to tens of thousands of dollars per month in licensing fees. While these larger clients could pay for it (and some  did) they really didn’t enjoy paying that much for a crash reporting solution.

 

When Crashlytics was announced for Android last year it seemed too good to be true, but it wasnt. Seeing that Crashlytics is a free solution that can handle large scale applications and provides the metrics that I need for both large and small clients – it was a no brainer. User management was super easy with Crashlytics too. Being that I’m a consultant I am able to be part of many Crashlytics ‘Organizations’ at once with one login. At this time I have one login and I’m part of seven different teams with different apps in different verticals. Crashlytics provides a push based mechanism (in the IDE and email) to notify me of new crashes as they occur.

 

Luckily I was invited to participate in the Android private beta for Maven users and Android Studio users last year. I jumped at the opportunity and brought my client, MyFitnessPal (#1 Free Health and Fitness app in Google Play) along for the ride. At MyFitnessPal we now use Crashlytics as our primary tool for managing crashes and assessing risk during post release of a new version.  

 

 

Working With Crashlytics in Production

Upon working with Crashlytics we were given access to their private portal (now public) for Android developers. This gave us access to the area where we were given instructions on how to install the plugin. Normally these types of instructions are provided via  webpage and a few steps to follow. Not the case with Crashlytics. They provide a full powered walk through on their site at www.crashlytics.com/downloads/plugins. You can choose your IDE or your build tool as shown in the figure below:

 

The Crashlytics guided installation tour

 

I either choose Android Studio or IntelliJ as these are my preferred IDE’s. Depending upon what client I’m working I may be working with a different IDE. Its important to note that if you do not use one of these IDE’s you’re not out of luck, you can choose the build tool of your choice as shown below:

 

You can also choose a build tool to help with set up.

 

The nice thing about choosing an IDE is that you get to install a plugin for that IDE and Crashlytics is nice enough to guide you through the process per IDE. Here’s a sample screenshot from the Android Studio walk through.

 

The Android Studio plugin installation walkthrough

 

Once plugin is installed you can view the plugin by opening the toolbar in Android Studio by ensuring that View → Toolbar is selected (for other IDE’s please see the documentation). Once this is open you will see the Crashlytics landing page as shown below:

 

The Crashlytics plugin landing screen.

 

Select the power button and the Plugin will detect which application you currently have open and at that point you will be walked through the setup process. One very important thing to note is that since I’m a consultant it’s very important for me to be part of multiple teams (known as Organizations in Crashlytics). While setting up a project I’m asked what organization I want this new application I’m setting up to be part of. As you can see from the list below I’m part of a few organizations. I can select which one I’d like this app to be listed in and then I’m ready to go.

 

The organization selector in the Crashlytics Plugin.

 

After you’ve selected your organization Crashlytics will inform you that its going to update a few files for you. This is great! I get to preview the changes and Crashlytics implements the changes for me, awesome! Here’s what it looks like when setting up an application:

 

The Crashlytics Plugin informs you that it will be making changes to your application code for you.

 

One important thing to notice here is that the Crashlytics plugin was able to detect that I’m using Gradle as my build tool for this project and is implementing the correct Gradle syntax for me! I did not select Gradle from the choices when setting up the IDE, I simply chose ‘Android Studio’ and Crashlytics did the rest.

 

Once you hit the next button you’ll be informed that you need to launch your app so that Crashlytics can detect that it’s running.

The Crashlytics Plugin waiting to hear from your app.

 

Once the app is built and is deployed the Crashlytics Plugin will recognize the app and will display the crash interface to you as shown below.

 

 

The Crashlytics Plugin interface analyzing the current app with installed.

 

Once Crashlytics recognizes your application they even give you instructions on how to force a crash if you’d like. Once crashes start showing up you can see them via the plugin as shown below.

 

As crash shown in Crashlytics plugin.

 

Upon clicking on the issue (the crash on MainActivity.java as shown in the figure above) you’re taken to the web based issue detail screen where you get a plethora of information about the issue that caused the crash. On this screen alone the following data is provided to you:

 

A screenshot of a Crashlytics Issue page on the Crashlytics site.

 

 

1.

Application and Package name

The application and package name of the app that has this issue.

2.

Error Location

Where in the crash occurred in the source code.

3.

Total Crash Count

The total number of crashes reported for this issue.

4.

Total User Count

The total number of unique users that have experienced this issue.

5.

Open / Close Switch

Toggles the issue as open or closed for this particular version of the app. If another crash for the same version of the app comes in after you close the issue, the issue will remain closed. However if you release a new version of the app and the crash occurs a new issue will be opened.

6.

Crash Graph

This graph displays the number of crashes on each given day over a period of time.

7.

Share Options

Options to tweet, email/copy the short issue link to send to another person for review.

8.

Android Device Breakdown Charts

These charts show the various devices affected by this issue.

9.

Android Operating System Charts

These charts show the various Android Operating systems that are experiencing this crash.

10.

% Rooted

Displays the percentage of rooted devices that are experiencing the crash.

11.

Free Space

The average free space on a device that has had this crash occur.

12.

Free RAM

The average amount of free RAM on a device that has had this crash occur.

13.

App In Focus

The percentage of times that the app was in focus when the crash occurred.

14.

Proximity On

The percentage of the devices that had their proximity sensors on when this crash occurred.

15.

Expandable Crash Stack Trace

A expandable stack trace explorer for the crash. You can inspect the various aspects of the code that was executing that caused the crash in this area of the issue report.

16

Notes Field (not shown)

At the bottom there is a notes field where you and your teammates can add various notes to the issue.

 

 

Using this data you can determine if this is a critical crash and if it should be fixed. I tend to particularly review the crash count, affected user count, device and OS breakdown initially. Crashlytics does provide each issue with an automatic severity level assignment that will help you determine what to do.

 

So what can you do with all this data from Crashlytics? In Part 2 of this series, we’ll do a deep dive on how this data helps you fix the most critical crashes with minimal effort and create happy users/customers for your business. We’ll be releasing Part 2 sometime next week — stay tuned!


In the meantime, learn more about Crashlytics for Android.

 

This article was also posted in the Product Showcase section for sponsors at CodeProject. This review is intended to provide you with information that is considered useful and of value to developers.

Your Desk Job is Killing You and Your Posture Sucks

Stop, right now, look how you’re sitting. You’re probably leaning in towards the screen with your shoulders hunched. You probably look like you’re hugging a beach ball. You’re killing your back, neck and spine in the process. It is what it is, but it doesn’t have to be.

I have something to admit – my posture sucks (but its getting better).

I’m relatively healthy. I eat as much organic foods as I can. I eat leafy greens a lot, I exercise 4+ times a week using weights and various forms of cardio in my home gym and during the summer I swim almost every day with my kids. I go to the doctor and they say my blood pressure is fantastic and that everything looks “excellent”. But, my posture sucks and the middle of my back hurts a lot.

Why?

My posture sucks.

I’ve become slightly kyphotic from my desk job. What does someone who is kyphotic look like? This:

 

NewImage

 

They hunch forward, their shoulders lean forward, neck protrudes forward a bit. This can cause all kinds of back, neck, spine, etc issues. Does your back hurt after sitting at a desk? Do you have a knot in your neck or back that no masseuse can seem to get out? Yeah, I have one of those still. I still work on getting it worked out. I constantly catch myself leaning over, shoulders rolled forward in a bad position while compromising my back.

Injuring your back is no joke (ask anyone who has). You literally cannot do crap. You can’t stand up without pain, you can’t sit down without pain, you can’t get out of bed without pain, you can’t twist, etc. You have no idea how much you use your back until you injure it. If you’re like me, you probably thought you sat up tall and then one day you looked in the mirror or saw a picture of yourself and thought “Why the hell am I leaning over like that? Do I really look like that?”

Chances are, you do … and that sucks. But, you can most likely fix it.

Fixing Your Posture

I’m going to address the #1 problem I that bugs me. The statement of “Sit up Straight”.

What the hell does that mean anyway? What is straight?

No one seems to know, well … they think they know. But the definition is so sparse and obtuse that some people sway their back (Lordotic) when attempting to “Sit Up Straight” and that causes problems as well. Understanding what “straight” is a different kind of beast. This image from Esther Gokhale’s great book 8 Steps to a Pain Free Back. This book has transformed the way I think about sitting, standing, sleeping, walking and general movement in general.

 

straight

Most folks would look at the silhouette on the right and feel that this person is “sitting up straight”, but thats not the case. The person on the right has what’s known as a retroverted pelvis and over time it can lead to tense back muscles or slumping. The person on the left has a anteverted pelvis which helps facilitate a healthy posture.

For me, this was my first realization in that I was thinking “sitting up straight” meant retroverting my pelvis and pushing my chest out. I thought I was sitting up straight but I was just causing other issues.

After delving into kyphosis I found that there was a ton of other information about sitting, standing and movement that was causing my back to curve. The slight curvature limited me from doing some basic exercises during my workouts, pinched certain nerves during common movements and gave me odd feelings in my arms after long periods of time at my desk. Thankfully I found some great, cheap, easy tools to help fix my posture and lately my life has been much better because of it.

Tools To Fix Your Posture

  1. Buy Esther Gokhale’s book: 8 Steps to a Pain Free Back
  2. Make a Standing Desk (for only $22)
  3. Implement a Daily Mobility Routine (5-10 minutes a day)

 

Buy The Manual For Your Back

Just save yourself the research and just go buy Esther Gokhale’s book: 8 Steps to a Pain Free Back

8steps

This book helped identify the various reasons why I was having problems with my posture. My standing position was incorrect. I realize I was always sitting with a retroverted pelvis and that was a big issue. I realized when I stood my pelvis was retrofitted. I realized I was being told to “sit up straight” all my life and that meant nothing after reading this. You’ll learn how to sit, stand, sleep and walk better which will improve the overall health of your back and posture significantly.

I love this book. I have it on my desk, I refer to it often. After reading it (and re-reading and using it as reference) I no longer tell my kids to “sit up straight” I tell them to “sit tall”. I do this so that this is not confused with what they will hear out in the world from everyone else who says “sit up straight”. This is based on Gokhale’s “Stacksitting” method she covers in her book.

Start Using a Standing Desk

NewImage

I started using a standing desk about two years ago. Since doing so I’ve noticed dramatic differences in my posture, energy and work performance and output.

You can build a cheap 22$ standing desk by following the instructions here. Its simple, you purchase a couple of things from IKEA  and build it. This is the exact standing desk I use and it works great. Since its a low cost and easy to transport you can build this at home and bring it into the office or use it in your cowering space or home office with little issue.

Arm & Hand Positioning

Simply using a standing desk is not sufficient. It needs to be set up properly. Your arms need to be at the proper angles and if they’re not you’re just going to cause other types of back/neck and mobility problems in the long run. Standing desk ergonomics is pretty simple and its best outlined by the image below. Desk height should be just below the elbow.

Standing Desk Ergonomics

 

Img:

Finding arm and shoulder placement is key too. Kelley Starrett explains it perfectly in this video:


A couple of caveats with a standing desk  though …

You may notice that your feet and legs get fatigued after a while. This usually happens when you start standing. You’re using muscles that you haven’t used before or haven’t strained that much in the previous years. There a couple of ways to combat this. I’ve found that the best way to combat this is to wear comfortable shoes and use an anti-fatigue mat. The best one I’ve found is the GelPro. Its pricey, but its worth it if you can afford it.

NewImage

 

Secondly I sometimes feel that my legs are getting tired and I want to change it up a bit. Perhaps my lower back is starting to complain, or I’m just getting antsy. I find that if I can place one of my feet raised on a stool of some sort I can relieve pressure from one of my legs and then I can get some alternative standing positions. Others find that kind of standing/sitting by leaning against a tall chair can really make a big difference.

Lastly, sitting at a desk can cause all kinds of problems and one of which is mobility. You’ll get tight in the hips. After watching the video below, I found myself stretching a lot, everyday while I was working. 2 Birds. 1 stone.

You can stretch while you stand by doing a couple of exercises as outlined by Kelley here:

Lastly, I work 2/3 of the day standing and 1/3 of the day sitting  because I tend to workout around 12PM for an hour almost every weekday. After working out I’ll stand until around 2pm and sit for the rest of the day (I start work anywhere from 5-7am everyday).

 

Implement a 5-10 Minute Daily Mobility Routine

Disclaimer: As with any physical exercise, consult with your physician first. 

Foam roll for about 5-10 Minutes each day.

5-10 minutes isn’t much.

You can usually do this kind of stuff when you’re working, getting ready for bed (this is actually the best time as it relaxes you), etc. You can pick up a foam roller from play it again sports for under twenty dollars or at a local sporting goods shop for a bit more. They also sell them online and look like this:

NewImage

Here’s a good video on how to get into foam rolling. Its easy: Roll until you find a place that hurts and hang out. You can roll your legs, back chest, etc. A roller is a great tool.

For those that really like to test their pain threshold or would like to expand their mobility, integrate a lacrosse ball into your mobility.

Lacrosse Ball

Simply take a Lacrosse Ball (pick one up at a sporting goods store for a few bucks or online) and put it on the ground, lay on the ball. Find a place it hurts and just hang out there for 60 seconds. Then find a new place. That red thing is the Lacrosse ball that is being used to “mash” or massage out the kinked muscles.

NewImage

Lacrosse ball mobility on the back. 

or this … 

NewImage

Lacrosse ball mobility on the chest.

Tight chest muscles can be one reason your shoulders hunch forward, here’s a great video of Kelley Starrett of Mobility WOD showing you how to roll them out.


You can also take two Lacrosse balls and tape them together to create a spine roller.

NewImage

Stand up or lay down and put the taped set on your spine. The space between the Lacrosse balls provides a space for your spine to move while you roll up and down.

NewImage

 

The Lacrosse ball will test your willingness to test your own pain threshold, its the great equalizer. After awhile, you get used to it and its a “good pain”.

The reward of mobility is immense. From being able to move more effectively and live a happier life to being able to play with your kids with no (or less) pain is great. I find that I’m extremely happy that my mobility work is over with immediately after I’m done. This i because: a) I’m happy as hell that its over. b) I feel amazing

 

Wrap Up

You don’t have to do everything thing here to fix your posture. But just doing one of them will help. They’re all gateway drugs into the world of wellness for desk jockeys. If I were to recommend something for under fifty bucks? I’d say buy the book, read it at your leisure and buy the parts for the standing desk and try it for 30 days.

Those things alone will change your life, for the better.

Until next time.

Inspiration is Perishable

I just got done with my mastermind meeting that takes place every other week and I was reminded of a key concept that I had forgotten in the recent years.

Inspiration is Perishable.

As I write this, I find myself having to create this entire post “right now” and not later because, well, I’m inspired to write about it at this moment. Currently, right now, I’m realizing that my inspiration to write this post is perishable. The concept and idea of inspiration is perishable was solidified from the writings in the book ReWork by Jason Friend and DHH. Its a great read, check it out.

Peak Inspiration has a Short Shelf Life

The concept of “inspiration is perishable” is simple and very easy to understand. Just as fruit in the basket on your kitchen counter has a shelf life, so does your inspiration. Unfortunately inspiration for a developer, designer, writer, engineer, entrepreneur, musician, videographer or anyone creative is very brief compared to even the short shelf life of a banana. You have to take advantage of inspiration when it hits and just ride the flow that it provides. Once its gone, its gone – it rarely (if ever) comes back in the same form. Right now, is right now and it will never happen again – take advantage of it.

Inspiration sometimes peaks for an hour. Sometimes it peaks and holds at that level of intensity for 4 hours. But it rarely lasts a full day. Exploding an utilizing that peak inspiration can be exhausting and draining but the results of what you can create during that peak inspiratory time block are usually spectacular. The best things I’ve ever created have been during peak inspiration. This includes my best selling Android Development book, my top blog posts and some of the best product features and code I’ve created or designed. All created during peak inspiration.

Its important to note that I’m not talking about the evergreen inspiration that some of us possess to become a successful or to complete a marathon project that has a lofty goal. Examples of lofty long term evergreen inspiring goals would include:

  • Launching a new SAAS product
  • Creating a new full length audio album
  • Training for a 26 mile marathon race
  • Producing a hit indie movie

The type of inspiration I’m referring to is the inspiration to create a portion of content in a short of amount of time when that inspiration is at its peak. The content could be a one of the following:

  • A blog post
  • A new feature for your product
  • A design for your app/client/etc
  • A new cool design in Photoshop
  • A new track for a new song (think guitar track or drum beat, etc)

Usually you’ll find these these bursts of inspiration are very short.

So how do you know when this type of inspiration is going to hit?

You don’t.

Peaks of inspiration do not come with a warning or any precursorsthey just hit you like an avalanche of emotion that overwhelms all of your available thought processes. You’ll know when it hits. Its the feeling you get when you feel so passionate about something that you immediately feel the need to create something because of it. This happens a lot in many creative types such as musicians, engineers, entrepreneurs, artists, designers, etc.

If you’re a musician, you’ve had it hit at random times. You hear a tune, you get off the phone with someone, you see something in person that affects you – feel a certain way – then it hits … and it hits hard. You get inspired. You pick up the keyboard or guitar (or whatever you play) and you just start magically making something phenomenal with minimal effort. This, is the inspiration I’m talking about.

If you’re a tech/engineering/design type of person you’ve had this happen when you’ve realized you know how to solve a problem and you feel the overwhelming feel to drop everything you’re doing to go implement what you’re thinking about. You cant get it out of your head, it makes sense, its “flowing” and the thought consumes you. You’re excited about it beyond comprehension. This, is the inspiration I’m talking about.

Sure, you can escape and deflect your peak inspiration if you want – but you shouldn’t. Peak inspiration is where the magic can (and usually does) happen. Don’t ignore it. Your inspiration will perish. Don’t say “Wow, this is a great idea/etc, I’ll do this later”. Chances are, you wont. At that point you’ve let your inspiration perish. Take advantage of it and ride the wave of inspiration, you’ll be surprised at what you create and share with the world.

Remember, inspiration is perishable – take advantage of it while you can.

 

 

A side note about inspiration and “The Madness” …
“The Madness”
Understanding the idea of peak inspiration is easy, but relating it can be hard at times. Thankfully Jason Roberts and Justin Vincent coined the term “The Madness” on their podcast, TechZing. “The Madness” is a form peak inspiration. Its when you’re so inspired that you can’t get the thought out of your head and you have to work on it. You become consumed and work at a blistering pace and produce amazing things in fractions of time that it would normally take you. This is called “The Madness”. You become overly consumed with your work through your inspiration and it consumes you. If you’ve fallen into this realm of peak inspiration and you’ve taken advantage of it and come out the other side amazed at the items you’ve created then you’ve had a case of “The Madness”.

Android From The Trenches

I recently was slated to present at Philly Emerging Tech last week. Unfortunately a few things came up and I was not able to make it at the last minute. However, I did record my talk and send it to the Philly Emerging Tech team to distribute to their attendees. They have since uploaded the talk to their Vimeo page for everyone to view. Below is that talk. The talk covers my experience in having two apps in the top 100 free category in Google Play. Enjoy.

ETE 2014 – Donn Felker – Android From The Trenches from Chariot Solutions on Vimeo.