Going full ConstraintLayout

Started a new project and decided to go full ConstraintLayout. I figure it is the future so I might as well use it. I used AutoLayout when I was doing iOS work so I have the general idea down.

First off I am using 1.1 because it has Barriers, Guides and Groups. To properly replace TableLayouts you need Barriers. This allows you to say "Hey, here are X controls, I want an edge to be based on the longest one". This is what happens with stretched TableLayout columns. It also means your layout will adjust if you change text label widths which can easily happen in other languages. Trying to stay on top of the internationalization game.

Group is nice if you need to hide a group of controls which you may need to do if you have a Switch that toggles visibility of a number of items.

Guides allow you to do percentage layouts. This gets rid of that deprecated layout.

Now my layouts are nice and flat. I went back to previous app and converted most of those layouts as well. The conversion tool in Android Studio is hit and miss. If you have just a RelativeLayout it will probably do a decent job converting it but you may have to set a width to 0dp here and there as the control may be set to start / end against another control but have a width of match_parent.

I also find you have to put in spacer controls at the bottom of some layouts, especially row layouts used in a RecyclerView, as the bottom margin is ignored for the lowest item in a layout. Did not cause too many issues.

I recommend you give this a shot as well.

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.