Using HockeyApp analytics in mobile applications

, 4 minutes to read

Pro­gram er­rors are un­avoid­able. No one un­der­s­tands to ev­ery sin­gle line of a frame­work or an op­er­at­ing sys­tem. The oper­at­ing sys­tem can­not af­fect a bat­tery level or net­work over­load. Reach­ing a high avai­l­abil­ity is a pro­cess in which feed­back pro­vides an ir­re­place­able role.

There is noth­ing eas­ier than send a HTTP re­quest when an ex­cep­tion is thrown and log it on your server. At least in the time of C# 6.0 which sup­ports an await in a catch block. In the time be­fore this highly use­ful fea­ture it was wise to use some an­a­lyt­ics ser­vice. The Ap­pli­ca­tion In­sights in Vi­sual Stu­dio On­line was a very ben­e­fi­cial one.

Some­time later the Ap­pli­ca­tion In­sights was moved to the new Azure Por­tal. I would leave it without any com­ment if the hi­er­ar­chi­cal event tree would be kept. You could use a slash in the event name and the name be­fore the slash was be used for group­ing of events. This fea­ture is now out­dated.

An­other amount of time later Mi­crosoft has ac­quired HockeyApp. The rea­son was that Mi­crosoft has been us­ing HockeyApp with many in-house de­vel­oped apps. It was cheaper to ac­quire HockeyApp than in­vest to in-house Ap­pli­ca­tion In­sights.

Af­ter the ac­qui­si­tion, all Ap­pli­ca­tion In­sights cus­tomers were forced to move to HockeyApp. Chang­ing mea­sur­ing codes wasn’t nec­es­sary, but ev­ery de­vel­oper knows that un­sup­ported means dead so the change is just a ques­tion of time. No­body would ex­pect full-fea­tured HockeyApp an­a­lyt­ics any­ways.

I iden­ti­fied two main disad­van­tages of HockeyApp com­pared to Ap­pli­ca­tion In­sights. Af­ter two years of HockeyApp in­te­gra­tion they are still present and un­re­solved (ad­e­qu­ately).

The fist prob­lem is that not all of han­dled ex­cep­tions can be re­ported. Crashes are re­ported by a com­pletely dif­fer­ent sys­tem. Crash data are avai­l­able in the Dev Cen­ter, but two thirds of them are de­scribed as Un­known even if the pro­gram de­bug database file is pro­vided.

The sec­ond prob­lem is that han­dled and un­han­dled ex­cep­tions can­not be dis­tin­guished be­tween each other. Upload­ing a pro­gram de­bug database file sep­arately from Dev Cen­ter app sub­mis­sion is un­com­fort­able. Han­dled ex­cep­tions can be re­ported as events to dif­fer­en­ti­ate them, but it is not pos­si­ble to place ad­di­tional in­for­ma­tion to event prop­er­ties (in fact you can, but won’t see them in the por­tal). All in­for­ma­tion must be placed into the event name, but there is cur­rently a limit of 300 unique event names per app per week.

For­tu­nately, there is a brand new Ap­pli­ca­tion In­sights Di­ag­nos­tics Pre­view. You can see event de­tails there, but so far it looks like this ser­vice is ori­ented ex­clu­sively to web ap­pli­ca­tions. Mean­while Mi­crosoft has re­leased the Win­dows SDK for Google An­a­lyt­ics. If you use Google An­a­lyt­ics, you have to pay Google to ac­cess your own data, be­cause it pro­vides you only a sam­ple.

I won’t pro­vide any qual­i­fied rec­om­men­da­tion here be­cause I don’t know about any­thing sim­ple, fully func­tional and suf­fi­ciently estab­lished. So far, I’m in­ter­ested in post-mortem de­bug­ging for 8 years and it was al­ways a hard work.