Coming Up for Air

Android App Development Quandary

Monday, January 11, 2016 |

I have a grand total of one Android application in the Play Store, Cub Tracker. It serves two functions for me: it helps me manage my sons' Cub Scout den, and it gives me a means for experimentation in the mobile realm. For the most part, it has done well for me on both counts for the past few years. I am currently faced with an issue of new functionality (which is mostly irrelevant for this discussion) that has brought up a question in the realm of experimentation. This post is a discussion of my options which will allow me to think out loud, if you will, as well as getting (I hope) some feedback on my options.

In a nutshell, I need to add data synchronization to Cub Tracker to allow users to share data amongst themselves (or simply across multiple devices). While there are certainly a number of architectural choices, my current line of investigation uses Google Drive and JSON data files. I have looked at other options — REST, for example — but I’m looking at Google Drive as it seems like it might be the simplest solution. Time will tell, of course.

That said, I’ve started working with the Google Drive Android APIs and was making pretty good progress until I ran into a huge roadblock: the Android APIs currently only support accessing files created by your app, which means I can’t access files and folders shared with the user by someone else, which kills the whole point of the exercise. Two options are to use the Drive REST APIs directly, or use the Java APIs. The latter sounds like a better solution, from a type safety and simplicity perspective, and it also opens up a number of other options, which is the point of this whole rambling affair:

Options

  • Implement a "native" Android solution (basically what I have now + the Google Drive Java APIs)

  • Implement a "native" Android solution in Kotlin. I’m really enjoying Kotlin, and, so I’ve heard, the Kotlin team has put out a nice library to simplify Android development.

  • Reimplement the application completely using a cross-platform library.

  • Reimplement using a cross-platform application…​in Kotlin.

Native Android Solution

This is certainly the easiest solution. I already have an existing project, so all I would have to do is add the Google Drive support. It’s also the most boring. :P As I’m sure you’re aware, the wow factor of a solution is the primary consideration when making architectural choices.

Native Android Solution in Kotlin

This is an incremental change, sort of. The structure of the app, in terms of classes and resources, is the same. The only difference is the language, and the IDE would do most of the work for me in converting the existing code. Making it idiomatic Kotlin might take a good deal of work, but that’s technically not necessary. I could also rewrite the app from scratch in Kotlin, which might clean up some semi-ugly legacyish code as well.

Cross-platform Solution

There are, of course, a number of options for this, but, since I’m primarly a Java/JVM guy, I’ve narrowed it down to two options: CodenameOne and JavaFxPorts. I haven’t used either enough to have an opinion on which is easier. Either or both may require a recurring cost for building and/or licensing, neither of which is enticing, given that my app is free. I can’t justify paying good money to give something away.

The other downside is that resulting app doesn’t really feel like a normal $PLATFORM application. That may not a very big deal, though. There are enough apps out there that have the same problem, that I’m mostly numb to that "problem", but there are others that are not. Gluon Charm would help with that, but while I don’t want a nag screen, I also can’t justify $23/month on a free app. :\

Cross-platform Solution in Kotlin

Are you sensing a theme here? This gives me the cross-platform support I’d like, in a pretty cool new language. The biggest issue here is that it’s almost 100% new (ish) technologies at work. I don’t want to be working on this next release forever, so this might be biting off more than is reasonable. That doesn’t mean it won’t happen, though.

There you have it. I’m sure there are other options, but I’m trying not to be too wide open. You have to limit your options somewhat, and these are the boundaries I’ve chosen. Hopefully, having typed all of this so I can stare at it will help me reach some sort of decision soon. The next step, I guess, is some proof-of-concept work. If you’ve read this far, I’m guessing you’re at least quasi-curious, so I’ll report back here once I have something worth saying ("unlike this post!").

Search

    Quotes

    Sample quote

    Quote source

    About

    My name is Jason Lee. I am a software developer living in the middle of Oklahoma. I’ve been a professional developer since 1997, using a variety of languages, including Java, Javascript, PHP, Python, Delphi, and even a bit of C#. I currently work for Red Hat on the WildFly/EAP team, where, among other things, I maintain integrations for some MicroProfile specs, OpenTelemetry, Micrometer, Jakarta Faces, and Bean Validation. (Full resume here. LinkedIn profile)

    I am the president of the Oklahoma City JUG, and an occasional speaker at the JUG and a variety of technical conferences.

    On the personal side, I’m active in my church, and enjoy bass guitar, running, fishing, and a variety of martial arts. I’m also married to a beautiful woman, and have two boys, who, thankfully, look like their mother.

    My Links

    Publications