Google+ Badge

Friday, October 20, 2017

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.

Friday, October 13, 2017

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.

Wednesday, August 30, 2017

Updating to be more in compliance with Oreo ProgressDialog deprecation

Oreo deprecated the progress dialog. That big fun thing that would dim the screen, pop-up, show the spinning circle then disappear when whatever operation was done.

The Google Material team is saying that is bad and users should be able to keep using the UI and cancel stuff. Once you target Android 26 any progress dialog usage gets flagged as a warning.

At first I was thinking "Oh man this is going to suck, I can't do that" but then I started to try getting rid of it in a few places and by damned things look a lot better. You don't have that flicker effect where the screen dims, see dialog even if for a fleeting moment, the screen brightens again. I have removed calling the progress dialog from all the places that load data so far. It is only actually referenced in one helper area. I have also replace how that helper area works and I am showing a custom dialog fragment. It looks pretty much exactly like the old ProgressDialog but now I have no warnings in my code.

The big benefit is user can cancel out of an operation if it is taking too long and move to another part of the app.

Using Retrofit was a huge advantage here as it supports cancelling network calls. Really had to tweak just a little bit of code for that to work nicely. 

Finding the proper place to put the busy indicator in the UI takes a little bit of thinking. I use Recycler Views instead of List Views so I made a very simple recycler view adapter that hosts a piece of text and the horizontal indeterminate progress indicator. I set that as the recycler view adapter while I am busy doing network stuff such as loading the details I really want to show. The user can hit the BACK button on the action bar or the button on bottom of device and I exit the activity with no issues as I just cancel network operations in onDestroy. Otherwise once I have the data I swap in the adapter that shows it.

It is really nice and clean looking and gives the user much better flexibility. Most of our network responses are pretty fast. There are a few areas we have to chain them to get all the data. It is funny watching QA hit something to start an operation then quickly try to pound the back button to make sure things cancel properly. I have some debug logging code in there so they can watch the output log to see if they truly did if fast enough. 

I am going to leave the progress dialog in place for credit card transaction processing and a few other key areas. I just can't have the user doing other things during that time. 

At first I was kind of pissed off at Google but once I got in there I totally see why they want you to stop using this UI freezer. The whole app feels cleaner and snappier. Very happy I tackled this area per the push from Google. Would love to kill it everywhere but some operations really do need to block the user from moving on.

I also cleaned up some code where the user was entering things such as an order number for look up. If they entered an order number that did not exist in the system, easy to mistype this sort of thing, they got a big pop-up "Order Not Found" dialog. I got rid of that too and just show the order was not found in the existing UI, highlight the text and have it ready for them to retry. So much less jarring to the user and it just seems so much friendlier. You are not being yelled out, just told can't find it and right back to trying again without needing to hit a CANCEL button on some dialog that is yelling at you.

Friday, July 28, 2017

Over a year in with Android watch and how it works with new phone

I have had my Huawei Android watch for over a year and now have a new HTC U11. I have worn a watch since I was in grade school so getting used to that part of the watch was super easy. My big concern was daily charging. I only need to charge it every two days and since I have multiple chargers at home and one at work that has not been an issue. Sure, it would be great if it lasted many days or had solar charging but it has not been the hassle I thought it might be.

When I had my Note 4 running Marshmallow the watch always won when it came to bluetooth which was annoying when I got in the car. With the HTC U11 the phone lets the car win when I start it up. That is great as I want to make and receive calls on the hands free BT in my car always. I don't know if this magic is due to the phone or Nougat but I am darn happy it works.

My watch updated to Android Wear 2.0 some time back. I was using Coffee for SMS support but no longer need to use that. Nice to have a keyboard right on the watch for quick replies. I have tested the drawing aspect as well and it works for sending back an emoji. Rest of the notifications work as expected and that is my favorite part of the watch. See the notification quickly and decide how much attention it needs.

Both of my sons have Zen 2 watches and get a lot of use out of them as well. I have found the watch to be a solid purchase and would dearly miss it should it decide to stop working.

Both the watch and phone have been solid in their pairing. I have not rebooted the watch since I got the new phone. I have rebooted the phone once outside of installing updates when it got overheated on a super hot day where I was also getting sick from heat stroke nearing conditions.

Friday, June 23, 2017

New HTC U11 to replace my Note 4

I have been running the Note 4 that a previous company bought for me. Previous to that I had a Note 2. While I really like the Note series I was ready to be done with Samsung and the slow to never Android OS version updates. Newer Samsung phones are not cheap either and I buy my phones outright, not on a payment plan with the carrier. Personal choice.

I researched what was out there and made some guesses about what was coming up. The HTC U11 seemed to hit the sweet spot for me. So far I have been very happy with the purchase.

Pros of the U11

  • Much faster. Pretty obvious that is is a newer device + processor so it should be
  • Nice to not have to look at USB cable every time you plug it in - no upside down mode
  • Responsive - I am not seeing lag when starting apps etc.
  • Solid sound. Note 4 was tinny at best and easy to block speaker when holding it normally
  • Rounded - easier on all parts of the hand to hold this device
  • Fast charging
  • Solid battery life even with lots of screen usage
  • Can finally do slo-mo videos 
  • Solid camera
  • Comes with noise cancelling ear buds - sound good and do block the noise
  • I have Nougat
  • Squeeze to access camera. I think this is a handy usable gimmick.
Cons of the U11
  • Lost my Stylus - did not use it a ton but when I did it was very helpful
  • Screen is not as vibrant with its colors - everything is crisp though
  • Non-removable battery. I did replace the battery on the Note 4 as it aged
  • No headphone jack but I rarely use headphones and it did come with a dongle to use with older headphones / earbuds.
  • No IR blaster. Another thing I used from time to time but did not rely upon.
The pros greatly outweigh the cons. This was a great upgrade and I am super happy with my purchase. Ordered off Amazon along with a few extra USB-C cables. We had some in the house for my wife's Axon 7 but not enough as I needed one in car, one at work, one for laptop and one for computer room where I use phone for debugging.

Surprised I had to install the HTC software on the Mac to be able to debug over USB. Mac usually does not care about drivers. Once configured it worked great and beats the heck out of using Android file transfer crap when I do want to get photos off the phone. APKs push so much faster to the device as well. Probably a mix of USB-C and faster device.

I don't have any complaints about the phone. It has taken everything I have tossed at it. 

I did switch from Llama to Automagic. Llama was free and worked for years but it has not been updated in years and it was showing some issues with Nougat. Since Automagic is not free I tried the 10 day trial version off their website. After a day I paid for the full version. It has worked like a champ. I had to configure more to get my standard flows to work but it is more powerful. Wife was ready for a change as well so she is running Automagic now too. 

My setup is pretty basic:
Enter house -> enable WiFi and connect to it
Leave house -> disable WiFi, set phone to normal sound
Enter work -> enable WiFi, connect, set phone to vibrate
Leave work -> disable WiFi, set phone to normal sound
10:30 PM -> set phone to vibrate only mode
6:30 AM -> set phone to normal sound

As for other phones I considered:

Waiting on Pixel 2. I knew it would get near instant Android updates but the current series was hard to find in stock, had crappy speakers like the Note 4 and probably would cost a couple hundred more than the U11. Plus my birthday / father's day was great time to do a phone upgrade. The wait was going to be for longer that I was willing to hold out.

OnePlus 5. I am just iffy on their long term support. After it came out I was happy I skipped this one. I like the quad res screen over 1080 especially for Google Cardboard.

Newer LG phones. Seems the boot loop issue and other quality issues around LG continue to haunt them. Nothing on the phones really jumped out at me.

Friday, June 2, 2017

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.

Saturday, May 13, 2017

2 months into Kotlin and the app is in Beta

I have not quite been at the new job 2 months yet and I submitted the app to a closed Beta on the Google Play Store. First interaction with the new Play Store UI which was a bit frustrating. I got all the pieces in place finally. You have to jump around a lot between the app and managing the Beta email list.

Feels darn good to have the app out there. It has been a bit of a challenge due to server side fun. There were some REST calls that seems quite silly and they worked them over so I sent / received a lot less traffic to do the work I needed.

Learned how to use a 3rd party UPC scanner, credit card swiper and credit card signature control. The CC swiper was the hardest as the documentation was lacking and so, thanks to the fine decompiler in Android Studio, I ended up sniffing around the API the hard way to find what I wanted.

Basic stats on the app

26 Activities
 9 Fragments
11 Dialogs
15 Adapters (ListView or RecyclerView)
 5 Custom controls written by me
59 Layouts (lots of row types)
48 unique REST calls

Not a small app but not massive either. All the code I wrote was in Kotlin, no Java on my side. For my first full Kotlin app I am very happy with the language. I would not switch back to Java at this time. I learned a ton and refactored a lot during the app development cycle. I kept finding better ways to do things in Kotlin saving even more lines of code. Support for round icons for Nougat and above. Making all the special permission asking calls as well. Not too many of them but the CC swiper needs to have access to the microphone, I need access to external storage and locations services.

QA has been pretty smooth too. They are finding the edge case stuff because we have a great QA team. I just don't see NPE things which were always frustrating when doing Java coding. I have been able to knock out the bugs within an hour of them showing up in most cases.

There is more to do on the app to get it in feature sync with the iOS version. What is there is very functional and fully usable by the target audience. It is also only being released to a small Beta team to start. I will continue to add the other features with a planned full release in early June. I need to deal with returns, some image capture and manipulation, and tie in to social media apps. There are parts of the Android app that are cleaner and easier to use than the iOS app so it also needs to get in sync with Android on that side. Good to have each team member push the other one.

Late in testing we were having some timeouts with the credit card processing. 3rd party service we use. Default timeout is 10 seconds for Retrofit + OKHTTP. Upped that to 30 seconds and things went smoother. Very happy with Retrofit, OKHTTP and Moshi. Had not used them before. I was on Volley + GSON in the past. Don't miss Volley at all. Retrofit makes it super easy to set up the REST calls with annotations. Using Moshi because it is already being used by the OKHTTP stack so what the heck. No need to toss in another library.

Time to enjoy the fact it was released and then start hammering away at the next parts of the app. Will be interesting to see what feedback we get from the Beta group. QA, other staff and myself had beat on it pretty hard. I pulled it into DDMS and went to each screen and did a kill process to make sure it survives that. Couple of tweaks there and all was fine. My first proguard configuration worked as well. I was able to run every part of the app. Hopefully this works fine on all the devices out there - looking at you Samsung.

Went minimum SDK level of 19. I have tested on 480x800 displays as well. Figure that covers a massive majority of phones. My guess is most real world devices with be above 19 and with much larger screens. QA did testing on 7" tablets as well. No special tablet code in there as far as bonus layouts. I see some places that would be handy though.

I have a Note 4 running Marshmallow and have been testing on that when not in an emulator. Good to have a Samsung Device for testing but I really want to upgrade my phone. Waiting for the new Pixel 2 and OnePlus 5 to arrive before I pull the trigger