App is on the Play Store

Did the official release of the app Wednesday morning. By Friday I had over 10,000 installs. They did send out a bulk email to our current clients and many of them were hungry for the Android version. Various folks bought an iOS device and used that until the Android version was ready.

Gotta say it is an ego boost to hit 10,000 installs in a few days. I do realize this will taper off now but I am still supporting 10k users as the sole developer, the iOS guy pitched in on some of the code, of the app.

App is not 100% feature matched with iOS as of yet so I am working on adding the final matching features then we will work on improving the app and there are many other new features we will release in sync as time goes on.

Reviews have been pretty positive. Some are having issues with data outside the apps control. They are addressing those issues at the server level. I am using Flurry to track various things and to capture any issues found. The Play Store is also catching crashes. So far there have been about 17 unique crash events affecting just a few people. I have been able to track down and solve most of them. Some have nothing in the stack trace for me to even guess what is happening and a few were in the Flurry Library.

While I like Flurry the documentation is sad. You can't find any one place to tell you the latest version. Most of the official Flurry pages mention some flavor of 6.x but I found one place that said 7.0.0 so that was what I was using. I then decided to go to source, the jcenter repository, and found 7.1.1 was available. Since I had fixed a number of issues I had issues in this library I went ahead and did a fast followup release that I hope will knock things down close to zero other than maybe the issues that don't have a useful stack trace.

I would say our QA department did a bang up job as the issues found have been very obscure and timing based. The app seems really solid.

Excited to get more data out of Flurry as well. I have set up a couple of reports there already but I can tell the data is lagging a bit because I can see a lot more action in real-time than is getting reported in the Explorer. Once we have a good solid week of data it will be more interesting and we can monitor things over time.

So why Flurry? At my last job we started using Google Analytics but it was just not cutting it for Mobile. Reporting with Fabric / Crashlytics did not seem to cover what we needed. Firebase seemed really powerful if you were willing to pay for BigData to do your queries. Flurry seemed to kind of hit the sweet spot for free data analysis. It is pretty easy to implement and a few simple helper bits for Kotlin and I was able to get a decent set of analytics in place in about a day.

Next up on the learning side of things is constraints layouts. I can quickly layout everything I can think up with a mix of Relative, Linear, Table, and Grid layouts but Constraints is the future and the sooner I learn it the better. The conversion tools seems a bit iffy so learning from scratch is probably the way to go.

I did get bit by the Java to Kotlin conversion tool as well. I had written an image cropping custom control in Java. Since I am doing full on Kotlin now and I needed to enhance this custom contol I had Android Studio convert it to Java. It compiled but did not work correctly. It decided to typecast a multiplication for me from Float to Int but I needed the multiplication to happen fully as a Float and the final result to be an Int. It decided to convert the code to case the number I was multiplying by first. Since that number was between 0.0 and 1.0 that cast was pointless. Simple enough to fix and I had a good idea what to do since I wrote the original code.

App released for App Store

It took 13 days to get the app released to that Apple App Store this time. I sent them a note yesterday as I was worried about the "review requires additional time" status. From what I could tell on the web this can be a death knell. It appears to mean Apple does not like something and wants to really review it to see if you are breaking any rules.

I sent them a note explaining we just send the data back to our server for it to be processed by the back office staff. Everything is pretty darn tame. I research everything to make sure I am not using a private API, all the graphics are legal, tool bars are in the correct place, back button works like it should, etc. We do store a lot of data on the phone due to CPT, ASA and Diagnosis codes for quick look up later. I wrote my own pop-up menu system that works on both iPhone and iPad to mimic the one I use on the Android but that is just a custom control. I explained all that in my note and it appears to have worked.

I have a couple of guesses. One they might have accidentally put it in the wrong status. I am sure this is easy enough to do especially if you are just choosing from a combobox. Second they could have been worried we were making money with the app by sending claims directly to insurance and they wanted a 30% cut of that. This app is just a simple tool to get data to the back office for processing. It saves the anesthesiologist time and money by not needing to drive back to the office to drop off paperwork.

In the end it is released and ready for our clients. We will be calling them today just in case they don't notice an update is available via the OTA process. I hope to hear some good news from them as I believe I have fixed all known issues at this time.

Previously it was released in a more timely manner: 5 days, 2 days, 2 days and 13 days for this round. Being in release limbo sucks.

Why you don't get crash reports from Apple

I thought our little app was doing great, never a single crash report but then clients said they are crashing it. So what is the deal? Turns out to get a crash report the end user MUST connect their phone to iTunes and OK the submission of crash reports. Our clients are Doctors, they never connect their phone. They use it for scheduling etc. as a smart phone. We will never see a crash report from them.

I looked in the logs and I see they are running iOS 4.1. Yep pretty old but since Apple did not support OTA (over the air just in case you don't know) OS updates they never update their phone. Now 5.0x is not all that great on old phones, they run pretty slow with it, but since many users never attach their phone they never even see good updates and patches. Face it, iOS is fragmented but in a different way than Android.

On the Android side we see crash reports. When the app dies you are given the choice to send the report over your 3G / Wifi / whatever data connection. Our app is based on being connected so sending this data is no big deal. Apple decided to bundle up all the crashes on the phone and horde them like a dragon. 

When I attach an internal beta testers phone to my Mac I get to see all the crashes from our app and all other apps on the device. Stuff crashes a lot from what I see. Those developers never get to see their crashes either. This is a damn shame and a total false sense of security. I pretty much wanted to scream at how annoyed I am at Apple for not giving me access to crash reports so I can make my app better.

I am now going to have to look into some user written crash handlers. You can catch exceptions at a higher level and then you need to try and save the crash somewhere then write it to your server during the next log in. When your app is crashed you can't do much with the data and since there is no central support you are on your own as to how to handle it. We will need a new API on our server to accept the crash data so I can log in and get it at a later time to analyze the situation. They need to fix this. Apple has been less than developer friendly through this whole process and they continue to piss me off.

On the Android side my Motorola Xoom updated to Ice Cream Sandwich and I am happy with the upgrade. The fonts look a lot nicer and I like the new back / home / menu button look. I don't care for the "clear all" vs. "clear individual" notifications from the status bar. 

I wish my phone could be upgraded but they stopped that at Froyo. This is a big downside on the Android side. Each manufacturer gets to decide how much they want to hose over the phone so it is unique to them but when they do that they can skip all future Android releases. As a developer I want the latest stuff. End users don't seem to care and just want it to run. See the iOS stuff above to find out the a lot of iOS users never upgrade. With OTA maybe that will change on the iOS side but the 4.x to 5.x upgrade was not friendly to me or others causing you to lose everything if you did not back it up first. Doing that OTA is not a good idea.

I understand not getting ICS on my phone but I really want Gingerbread as Google sped up various aspects of the UI with some new memory management etc. Guess I will look into rooting it at some point in the future and if it works for me I will do it on my wife's phone too.

Ouch - App Store rejection!

After a full week of waiting to review our app got rejected by the Apple app store. They found a crash, a legitimate and easy to reproduce crash that should have never made it past me or QA. A crash that occurred in all previous versions of the software. A crash that made it through to the store multiple times. It involved turning off some of the editable sections via the admin tool. I was using a tag as an array offset, if all sections are enabled the tag would equal the offset, but in the one test case this was going to cause an index out of bounds. I screwed up and should have labeled the variable as tag instead of as section. I probably was going to do that at one point but the crappy refactoring support in Xcode means I skip doing work like that from time to time.

It is my fault for not catching this earlier. For the test log in we sent to Apple you had three practices to choose from. The bug only occurred on the third practice in the list and only when you pressed the (+) to add a new image to list. Very glad Apple found this issue. I did not want a crash out in the hands of our users and I am sure many would have run into this issue as the layout of the editable items is totally configuration via our administration tool. That tool is not a mobile app but how each client configures what they want the doctor to enter is totally up to them. Annoying this was not caught by QA. As a developer you don't have time to configure piles of test cases in the admin tool then test things out on the mobile side of things. Something like this I should have tested though as it is pretty easy to configure and verify.

It works just fine on the Android. Due to language and GUI component differences the code is not a direct port between the platforms. Could be I was doing a quick conversion to the iPhone or I did the iPhone side first and caught the issue during the Android conversion or the Android code is so different that bug would not occur or I forget to go fix it under iOS post Android conversion. I was back and forth between the two on a daily basis.

Being the sole developer for two platforms is just not easy. I have no one here that can do Objective C code reviews. Someone could look over the Android Java code but I am the only Android developer so some parts of the API would not be familiar too them. Java tends to be Java so I am sure they could find issues if they looked hard enough. Heck, I could find issues if I gave it all a once over. I fixed the issue, ran some tests and we submitted it again.

Within an hour it was back in "In Review" status so Apple obviously saw we got right on the fix and did not move us back to the end of the line. I really did not want our clients to wait another full week for Apple to just start looking at the app again. I am hopeful it gets through the review process in a few hours and we can contact clients starting Monday to let them know a new version is ready that fixes the camera issues and this new issue.

I just got another note from Apple that they need additional review time but they will keep me posted. Must be time for a real test instead of the past two times where it was just shuffled right out into production.

 We don't appear to be getting crash reports from Apple. When we look in the crash report section nothing is listed even though clients reported crashes. I wonder if it is due to them running 4.1 iOS and the tabs for the crash reports start with the 4.2.x series. Does Apple throw away older iOS reports? We could tell clients to upgrade but we list support as 4.0x and above. Plus upgrading to 5.x series is not for the faint of heart. You darn well better back up everything because I know multiple people that had everything blown away. That was not the case when doing 4.0.x -> 4.1.x -> 4.2.x upgrades and people got a false sense of security. A lot of doctors just get the device and never connect it to a computer. I really don't want to walk them through that process.

Here's hoping the new update is available at the store on Monday!

Android app disappears with slide out keyboard

While checking in with a client on our mobile apps they mentioned that on an Android phone with a slide out keyboard the app disappeared every time they slid out the keyboard. I had not tested on any devices with a slide out keyboard so this was news to me.

One of the ladies in support happened to have a slide out phone at home so she brought it into work today. I set it up for debug and plugged it in to my machine to monitor it under Eclipse. No errors in the log, the app just disappeared. I put in break points and found onDestroy was being called but why?

Searching the web and I found you need to add keyboardHidden to your manifest file so the activity will not be destroyed when that event occurs. All my activities looked like this:

android:configChanges="orientation|keyboard"

Now they look like this:


android:configChanges="orientation|keyboard|keyboardHidden"

This solves the issue. I thought keyboard would handle things but you must have both keyboard and keyboardHidden for it to work on all devices.

Of course you only want to do this if you gracefully handle orientation and keyboard changes in your code. All of my activities are very friendly to orientation changes and to the on-screen keyboard appearing or disappearing. The term keyboardHidden does not say to me "the hardware keyboard is sliding out" making it an very unfortunate term on Googles part. A better name might be hardwareKeyboard. I have a feeling the percentage of users with a slide out keyboard is pretty small too but you want to make sure your app works on as many devices as possible. 

I have run our app on my Xoom with a bluetooth keyboard. Even though it operates to the OS like a slide out keyboard in that the on-screen keyboard does not appear it did not have any crash issues. The slide out keyboard must trigger special events. Glad to have it fixed in our code.