Moved from minimum SDK 19 to 21

Looking at our Flurry stats we had zero uses on SDK 19 so it was time to make the switch. Happy I did. I was able to delete a bunch of resolution dependent PNG files and move to vector based XML files.

One minor issue, drawable start / end for a TextView, even the AppCompat version, does not support tint color until API 23. Easy enough, just did a separate ImageView and TextView to get the same look. Very few areas needed this change.

I was also able to kill some code that was checking for older SDK versions. Nice to be able to clean up all that crap as well.

Impact on final APK was minimal but I sure like the clean up in the resource area.

I also started to use the applicationIdSuffix ".debug" in the build file. Now you can have the Play Store Version of the app and a new debug version on same device. Lets me see if I screwed up the look of things when I play with layouts.

Decided to update the tint color for the status area of the screen as well. If you are running a debug version it is purple, light blue for release versions. Lets you instantly see what version you are running. Of course the launcher icon has a big BETA banner on it as well so you know at launch time which one you are using.

Knocking off some technical debt while I wait on server to have new features in place. Good to see some progress in this area.

Removing ListView and PercentRelativeLayout

For my tech debt I am removing all ListViews and Percent RelativeLayouts. List View has been replaced with RecyclerView. When I started the current app I did ListView, bad Kevin, because it was easy to pop into place especially since I was just learning Kotlin. Now that I have a lot of Recycler views and I can really use their power it is time to replace all the ListViews. I only have two left to go after swapping one out today. It was much easier than I set myself up for it being and since I now know to use multiple adapters instead of trying to cram everything into one adapter with crazy boolean logic it because super easy.

One of the last two that needs replacing is of the infinite scroll variety so I will have to get that working. I have not done an infinite scroll for a RecyclerView yet.

For PercentRelativeLayout I am swapping in ConstraintLayout. The auto conversion, at least with Android Studio 2.3, gets you 80% of the way there. I had to get the rest of it tweaked to look like it did before but it was not too bad. I can see the power of ConstraintLayout but the IDE has too many issues for me to want to switch everything to it. My understanding is AS 3.0 is much better but I will wait until that hits release. Did not want to have deprecated layouts in the code. I know Google will leave them around for a long time but learning ConstraintLayout was a good mental exercise. I have used auto layout for iOS development and MigLayout for desktop Java which made wrapping my head around ConstraintLayout pretty easy. A couple of videos to learn some tricks and I have not run into something I can't make it do. Looking forward to using the Group functionality in the 1.1 release as well.

I have tested my code under AS 3.0 Beta. I had to replace one control I was using. It was from GitHub and has not been updated in a long time so chances of it getting fixed are slim. The replacement was not too hard to write and works out well plus I have a lot more control. Always happy to get rid of a 3rd party dependency especially when I get more power out of the end result.

I tried using the ThreeTenAndroid library for time / date management but it was broken for Korea. After the start up crashes started to pile up it was time to switch. I am now using JODA Time. Was a pretty easy swap out. Not using standard Android Calendar / Date/ SimpleDataFormat as I was running into thread safety issues and was tired of screwing around with that. I know I added a bit to the size of my APK but working code is the best kind of code.

Added more Flurry event calls for even more analytic reporting. I do find Flurry very handy for both our Android and iOS products. You only get as much out of it as you put into it. The Flurry webpage interface can be frustrating for sure but when it does work and the data comes back you get solid results. It does let me know when a new feature is being used. I have also found some features that are never used. Painful as that might be knowing the answer is good. I really wish they did a solid Android App so I could monitor error reports on my phone. Using the website on a phone sucks at best. The Android App is super limited in functionality to be nearly useless.

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.