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.

Hey, I want to be an Android programmer. Tell me what to do.

How many times have you seen a post on various forums about someone wanting to be an Android programmer? Is there a simple answer? Of course not, programming is not easy and there are piles of things you end up doing during any given day.

Wait a minute there! Isn't all I have to do is learn Java and some Android libraries? Oh, how we all wish but there is a lot more going on and that is just the start. Yes, you need to learn Java (or Kotlin) and you need to learn about the SDK as well but there is a ton more.

Today it hit me I had been in the following in just one day:

1. Java writing the main app code
2. Kotlin working on a utility program to convert iOS plist to Android format
3. Groovy because I was editing the gradle build scripts
4. Bash as I updated my Java version and needed to change my .profile 
5. Various Linux terminal commands
6. Various Git commands on command line and in Source Tree
7. Vector Graphics as I was working on a new image I needed
8. XML for the Android layout manager, string tables and color tables
9. PNG images for new icons
10. REST calls
11. JSON parsing for REST call responses
12. Sublime text editor creating and running macros against text files
13. File manipulation in Finder
14. Looking at ObjC in Xcode that I am converting to Android
15. Using IntelliJ, Android Studio and Xcode

It is not just learning Java and an API. I could not get Adobe Illustrator to do exactly what I wanted to I directly edited the SVG file. How many languages and file formats have I been in today already? Piles of them and I was able to quickly do the list above and I am sure I missed stuff.

Obviously Java, Kotlin and Groovy have a similar syntax so it is not like I am switching from assembler to JavaScript mentally but there are differences so you do have to perform a mental switch.

I don't mess with graphics every day but we have been setting up a number of build flavors this week so I have been doing a lot of graphics work along with "normal" programming. Honestly there is no such thing as normal. I shift around all the time. I decide to write the utilities in Kotlin as something new to learn, it was not required by my job. Glad I did, gives me a better appreciation of the language. Really want v1 to move out of beta before I use it for my Android apps.

Developers have to understand more than just the language they are using. You end up using a lot of tools like Git, Paint.NET, Adobe Illustrator, Adobe Photoshop, different IDEs, text editors and various utilities. Plus you get to keep the OS on your machine updated along with IDE, SDK, Language versions and tools.

Never know when the boss will need your help on a spreadsheet, document or power point as well. You have to be able to run at least a minimal feature set in a ton of tools just to keep up with life as a developer.

I am unsure how a new developer even gets started. I have amassed a large quantity of knowledge over the years. I can apply that to Kotlin when I experimented with it this week. I already knew the IDE, the .plist file format, XML, how to use collections, etc. I was picking up a new syntax but when you start from scratch you are tossed into a tank of sharks. The only way is to start small. Just work on one concept then move on. If you try to do an entire game or program with multiple screens you will go nuts before you get very far.

An interesting side project that ended up in main project

We are getting PDF files from a client. They contain medical records with one of the items being the patient ID. My initial task was to find PDF parsing code on the web to pull the patient ID from the file then rename the file to include that as a prefix.

A quick search turned up PDF Box from Apache http://pdfbox.apache.org/ which sounded like it would do what I needed. Grab the download, whip up a simple Eclipse project and I have the text extracted. Very easy to use and understand API.

Of course the next part is where the real work comes in. Have the program respond to command line parameters and if none are provided a GUI is presented to the user. Let them pick the source and destination directories then process the files. Save the last used directories to an INI type file so they don't have to pick the directories every time they start the program.

Once that was working I was told they would really love to have the PDF pages converted to a JPG so they could be imported into our software. Turns out PDFBox can convert to PNG which we can also import. Update the code to handle the conversion. They also wanted to copy the originals of properly converted files to an archive directory. Added that to command line processing and GUI.

I asked since I know now how to use the library to convert PDF to PNG why don't we just import PDF files directly? Sure, why not, do that. I updated the main code base to allow user to choose PDF files along with other image formats. Next I changed the processing loop to handle the page count of each PDF for the import status and did all the code to write the converted pages to the temp directory and then import them as PNG files. All pretty easy stuff and it turns out this is something the clients have asked for over the years.

Before we did not want to import straight PDF files as then we would need a PDF viewer in the code. Adobe used to be pretty good for a C/C++ developer allowing you to embed the viewer using OLE and other API calls but that came to a halt I think around version 9. It has never been a fun task in Java. With the conversion to a normal image format I don't have to worry about any of that. Each page can be rotated, annotated, redacted, etc. using our basic image tools.

Now I asked about the original utility program I wrote. Seems pointless for it to convert the PDF to *page#.png files now that we can import things. This morning I am going to add a checkbox to the GUI and another command line parameter to allow you to control the export of page files which will be off by default. They still need the patient ID extract and rename but probably will not use the page extract. With the code already written it might as well stay in as an option.

Funny how a one off request can turn into something that benefits every customer. There are days you just need to do a little research to find really cool simple solutions to problems. I also got to learn about a new library that may come in handy for other projects. The JAR file is not small but what it does is pretty powerful. We added it as a lazy load JAR to our JNLP file. Hopefully QA does not find any massive issues with the conversion. It worked fine on all the PDF files I tried it on but I know there are a lot of ways for those to be messed up.