Swift on Android?


I spent some time a couple of months ago catching up on Kotlin, the new programming language from Jetbrains. For those who don’t know, Jetbrains is the company behind IntelliJ Idea, which is the technology that powers Android Studio and a whole bunch of other Integrated Development Environments (IDEs) on the market.  Now news has it that the Swift programming language is coming to Android. The headlines I’ve recently seen say that Google may be considering supporting Swift on Android.  I just searched the web and found this pull request from a day ago. Hi I’m Cliff. You’re here because you don’t know which programming language to learn to start your new career as a software engineer. I’m here because I’m having a blast following the excitement around this new Swift movement.

If you’re new to programming this may all sound like Greek to you. After all, who cares about a Swift, Kotlin, and who even knows what’s Groovy these days? You just want to make the next killer app, or possibly get an icon in the various mobile stores for your business, right? Now you have all of these choices. You can currently write Android apps in Java, C/C++, Go, Groovy, Kotlin, and now Swift is becoming a reality? It can definitely feel overwhelming! Let me assure you that each of these options are certainly important and it doesn’t hurt to do a bit of research before jumping in any boat. I’ll explain some of the more popular choices at a high level then briefly speculate on what the introduction of Swift could mean.

If you are brand new to programming you can’t go wrong choosing Java for your Android app. It is one of the more ubiquitous languages out there and it doesn’t take too much effort to master. Java is supported not just on Android, but also on a myriad of platforms from Mac OS X to Windows and Linux. Java has been around for decades and is currently supported and maintained by Oracle. Java would be the best fit for a brand new Android developer because Android has been designed around this language since the very beginning. All other languages require special features, runtime supporting libraries, and/or work arounds. Almost all of the information and tutorials you’ll find online at the time of this writing is based on Java. All of the Android development editors and tools directly support Java as a first class citizen which makes life painless when you create apps. You get features like auto-completions, syntax-aware editing, and more out of the box when you choose Java. With other languages you only get a limited sub set of these features, if any and many of these features may only available as a bolt-on addition provided by a 3rd party. Java programs currently cannot be used on iOS. (Technically there are ways to make it work but these means go far beyond the scope of what most would consider officially supported.)

Why on Earth would anyone want to choose C/C++ for writing an Android app? I’ll tell you why! With C/C++ you get raw speed and your code runs directly on the hardware. If you are new to programming you need to understand how many modern programming languages work. Many program languages are compiled (or, in simpler terms, translated) into raw instructions that a computer processor can understand. These raw instructions are actually random collections of 1s and 0s and referred to as machine code. Languages like Java, Groovy, Kotlin, etc. are not actually converted into machine code, rather they are converted to almost a pseudo code and they use a virtual machine. This is like a mini program that runs your translated program. Both C and C++ compile, or convert to machine code and can be loaded and executed directly by the processor on your phone. This not only makes them run faster, but they tend to consume less memory and have the ability to perform tasks that other languages are restricted from performing. Java is actually somewhat exceptional on Android as the virtual machine it runs on is so highly specialized that it can run at near identical the speed of machine code in some cases. (I don’t have benchmarks, I only go off what I’ve learned from various sources.) Still C and C++ give you the option to interact directly with video and audio hardware on the device. These are also the two programming languages on which many other languages are built. One major reason to choose these languages is that they can be used on just about every platform from Android to iOS, to Windows to even non-standard computing devices like Arduino boards. That said, it requires non-trivial effort to create a program that can be ported to different platforms. Still these languages are more complex than many others and are usually considered for specialist tasks, such as high speed graphical or audio processing, low level network data streaming, etc.

Kotlin and Groovy are two powerful scripting languages I have been sporadically experimenting with. They compile, or translate, to Java byte code, which is the same code that Java itself compiles to. They both have advantages over Java in that they are more expressive in terms of the amount of code you need to accomplish a specific task. Where Java tends to use a moderately verbose syntax, these languages pack in incredible amount of power in relatively few verbs and commands. They are also quite flexible in terms of the rules of their syntax. One particular example would be the rules around type checking. Some languages, like Java, C, and C++ enforce rigid rules that type identifiers must be used wherever data is sent around or recorded. Also, in some languages the rules around what constitutes a program statement, or single line of code can be verbose and somewhat unfriendly. Some of these rules are somewhat relaxed and more flexible when using either Kotlin or Groovy and they allow you to combine expressions and statements in an intuitive way to make your logic appear more natural. If you have familiarity with one or more languages or are slightly more than a novice it may be to your advantage to give these languages a shot. It should be noted that these languages are not yet supported on iOS.

Kotlin is developed by Jetbrains, the company behind the technology that powers Android Studio. This gives Kotlin a unique advantage over many of the other choices in that it is treated like a first class language. You get all of the tooling support you would expect from a Java based project when you choose Kotlin. Indeed, there would be little to no difference in complexity when choosing Kotlin compared to choosing Java. While there is a slight learning curve if you are only familiar with Java, the Kotlin community offers plenty of online resources to accommodate.

Groovy is developed as an open source programming language with a rather large community of active users. It also happens to be the programming language you use when creating creating Android’s Gradle files which are build time instructions for compiling and packaging your Android app. Groovy brings practically every feature from all the popular languages like Python and Ruby. Groovy also has a rather unique advantage in that it actually borrows most of its syntax and grammar from the Java programming language. This allows for a practically nonexistent learning curve. If you know the Java language you already know 90% of the Groovy programming language! The major differences between Java and Groovy are the relaxed rules in Groovy and additional enhancements. While Groovy also offers many of the same tooling support as Java and Kotlin it comes as an add-on and there is not a ton of tutorials or examples currently available. This could change soon as Groovy takes off.

I don’t know much about Go other than it is a new and growing language developed by Google which, I believe, compiles to machine code. It can be used for Android and iOS but the tooling support is limited, to my knowledge. The Go programming language is also open source and backed by a community of extremely active members, many who live, eat, and pay their income taxes with Go. It is said to be a very simple and powerful language, but again, I am only reporting what I’ve heard. You could choose Go if you wanted to run on iOS and Android, maintain a relatively small code base, and have time to go to the movies. I include it in my round up because of its growing popularity especially among enthusiasts. It is definitely something to keep an eye on.

This brings us to the Swift programming language. Swift is a relatively new programming language created by and owned by Apple. It has recently been open sourced. While only a few of the languages above can be successfully used on iOS, Swift is actually developed specifically for this platform. Its arrival on Android could mean a variety of things such as no more need to maintain two separate code projects for an app that runs cross platform. The beauty of this new language is that is also is an extremely expressive language which compiles to machine code. Indeed you get the best of both worlds with languages like Swift, where it offers the expressivity and flexibility of Groovy, or Python with the direct execution advantages of C/C++. It’s still too early to speculate on how it will work on Android but the news is already creating a lot of buzz. IT will likely take a bit of time for tooling support to be as complete as it is for Java or Kotlin and few people will trailblazer writing cross platform apps with it. However the possibilities are very enticing. Imagine truly writing code in a single language and deploying it to iPhone/iPad/Apple products along with Android phones and tablets!

This post probably has not answered any questions for you. I am just at the beginning of exploring what my next language of choice will be for Android development. As such, I felt I would convey my thoughts while sharing with many of my new found just learning to code buddies. Many of you may be just starting to code and my hope is that this serves as a gentle introduction to what is currently available. For some of my more seasoned coding homies (y’all are still my peoples!) stay tuned because I plan to do a deep dive into a few of these languages and kick the tires to see what is viable. Until next time…

Android Animation Fun

Merry Belated Christmas!!! I find myself trapped under my Macbook this holiday season and completely captivated by the Android animation system. “I find myself” is sort of a strange thing to say since I’ve never really lost myself. I mean, how can I find myself without involving one of those out of body experiences? If I did have an out of body experience I couldn’t imagine losing myself because I would always know where I last left myself. If myself is not inside my-fleshier-self then I would think that my-fleshier-self would know to stay put until I returned to myself, know-what-I’m-saying? By the way, I’m Cliff. You’re here because you probably did lose yourself on one occasion or another.

You see, not many people are as responsible as I am during out of body experience. Other people would probably misplace their fleshier counterpart while they wander off to the casinos, shorelines and so forth… generally having an awesome time. Then they would circle back, completely forgetting which hospital or state they departed from and… where was I going with the story? Android animation!

I was looking to enhance an app I’m building with animation and when I took a step back I realized I built the beginning of an animation composer. It started from my need to see how the different interpolators behave. I found some source online to visualize interpolation and started to build from it. I had this idea of shape morphing so I created a custom view to see how/what I could do to morph it. My project is somewhat basic. I mean I just started with an activity with an Activity containing animation controls.

A basic activity
A basic activity

I read the values from these controls to make an animator and apply it to a custom view. I then wanted to experiment with orchestrating multiple animations at once or in sequence. For that I needed to repurpose my controls into a fragment so I can create a multi-control list view. Pulling the logic out of my Activity and into a Fragment was somewhat simple using Android Studio. I started by moving the controls in the layout into a separate layout with the extract layout refactoring. This created an includable resource which I wrapped in a FrameLayout. I has to move the animate play button out of the layout with the controls since this would eventually apply to all controls. Building and running on the device confirmed that I hadn’t broken anything while rearranging the layout. I gained confidence to delete the include from my layout. I renamed the activity replacing the Activity suffix with a Fragment suffix and changed the logic to load the newly extracted controls layout. Next I created a simple activity to load the fragment dynamically and add it to a frame layout in the center of the screen.

After confirming the app still worked using the controls out of the fragment I went on to introducing a list view replacing the the included fragment. I figured out how to add fragments as list items in an adapter. I added logic to iterate the fragments in the list and build an AnimatorSet where I play all animations together. Things were broken initially but with a few more tweaks I got the entire thing working again.It is still in its infancy stage but it covers the basics of composing animations and playing them against a custom rounded rect view. You can find my work in progress at Bitbucket.

multiple animation support
multiple animation support

Learning Android Gradle Unit Testing

The Gradle build system is pretty robust and it is becoming mainstream. That means it behooves you to start putting it to use. I’d been spending a little time with various Gradle based projects and realized that there were a couple of things missing… documentation on the Android plugin. Sure you can look here but I’m a rebel and I like to pretend there isn’t any documentation while learning the hard way. Hi, I’m Cliff. You’re here because you don’t read documentation. I’m here to show you how to reverse engineer your own documentation using Gradle/Groovy goodness. Today’s article is going to be short since it only covers a small area.

So I’m playing with a Gradle based Android project trying to get unit testing to work when I hit a snag. I had been so used to Maven and following all of the popular Gradle documentation online will have you believing, “Hey this works mostly like Maven!” In fact, a basic Java Gradle project is mostly indistinguishable from a Java Maven project from the outset in that they both follow the same familiar structure. Just drop your compile files into “src/main/java” and your test stuff into “src/main/test”. You hardly have to write any code in your build file to work with these types of projects. So it is almost a given that I get lost when I opened my new Gradle-based Android project and tried to add unit tests. Let’s start from my first sign of trouble in Android Studio. My initial step was to create a test folder for my project to begin adding tests to. Doing so I noticed it was colored manilla-tan and not green as I’d expected. Now in IntelliJ there’s a nice little right-mouse context menu that allows you to mark a folder as either a source directory, a test directory or a resource directory. Right clicking in Andoird Studio did not reveal the same feature so I thought there was a bug in the recent Canary update. (“Doggone Canary bleeding edge!”, is what I murmured to myself in disgust.) Then I thought I could just edit my Gradle build file to get the proper color on my folder allowing me to right click tests and run them directly.

I copied a source set config from an earlier Ant-based Android project that I coerced into Gradle. In this project I used the sourceSet configs to map the legacy Android-Ant structure into something Gradle could work with. This was done many months ago and several changes to Gradle and Android has happened since then but I figured it would still work the same since the original project was still functional. Dropping the following under the android config in my build.gradle did not change the color:

sourceSets {
    test {
        java.srcDirs = ['src/test/java']

Out of frustration I poured through all the Gradle documentation I had. Unfortunately I was reading Gradle docs and not Android plug docs for Gradle so I was confused into thinking what I was doing should work. Just before complaining on StackOverflow or filing a bug report I found a little hack I could use to debug my build.gradle. Remembering that a Gradle build is just Groovy source code gave me relief as I could just drop a println anywhere and inspect build elements in my console. (I use the terminal plugin in Android Studio so I didn’t even have to leave myIDE to try it.) I looked up the SourceSet API and then coded the following:

android.sourceSets.each {
    println "Sourceset: ${it.name} java source: ${(it.java ? it.java.srcDirs.join(':'):'Null')}"

That’s when it became apparent that there is not test source set in the Android plugin, only an androidTest sourceSet! I also learned, as I had figured, that there was no need to code an explicit source set so long as I followed whatever the convention was. I finally decided to write this blog post out of frustration because NOWHERE IN THE INTERNET UNIVERSE IS THERE ANY DOCUMENTATION EXPLAINING WHERE ANDROID TEST SOURCE LIVES!!! HOw frustrating it is to be an Android developer these days!