Going from creating iOS apps to Android apps via Adobe Animate

What a long, strange 2 month trip it’s been…

So some of you might have noticed I took my annual journey into obscurity early this year. Usually I wait till after WWDC to go full immersion into whatever new stuff is being thrown at us devs. Which is a hard time to educate, because I, for one, am learning and usually a bit unsure of what exactly I’m doing. Also from June to September, Xcode is really in Beta mode, so I hate committing something to video when it might change a week later. So I tend to disappear for a couple months.

So what happened this year? Well, over Spring Break I decided to create a Member Check In app for my neighborhood pool, but really, ANY neighborhood pool. Well one thing led to another, and I’ve basically started a new side business for this. But along the way, I had to re-learn some Actionscript 3 to create an Android version of my iOS Member Check In app. And as some of you might remember, 20 or so years ago Actionscript (2) is what really introduced me to programming. And wow….

Swift and Actionscript 3 aren’t that different!

…That was the first big thing that struck me.

A little history. I learned Actionscript 2, which was kind of like having the training wheels on in terms for coding. A lot of coding on a timeline – for example,  starting and stopping a timeline, where at frame 10 code would run, then jump back to frame 1 or go to frame 20. Stupid stuff like that. Actionscript 3 matured the language a lot, which put an end to some of that silliness. It’s still possible to write code on frames of the timeline, but probably not recommended.

Well about the time I really got decent with AS3, the first iPhone came out, and I moved over to Objective C. That of course is a whole different beast. Not a lot of dot-syntax, and a whole lot of brackets. Ohhhh, so many brackets. It’s really not pretty. But I stuck with it, and Objective C kinda made me forget all about Actionscript. Then a few years later, Apple created this beautiful Swift language. So no more brackets and back to lots of dots. I can’t remember how many years now we are into Swift (probably 1 per version number), but it’s been a solid language to work with and you get to push out projects to your iPhone or iPad. Always fun, and they keep getting better and faster.

So my feeling was, why look backward and use Actionscript? Flash Player has long been dead. I didn’t personally have an Android phone, and the last time I had tried to put anything made with Adobe Flash (ahem, now Adobe Animate) to a mobile device was probably right around the time I was learning Objective C, and it just wasn’t a great experience.  Pushing a high frame rate game onto a test Kindle (back then) wasn’t a good fit.

Cut to last month, when I had that moment of, “if you’re gonna do this, you gotta do it for everyone”. And I’m sure many of you have thought that same thing about your apps. Games are a little different, because it’s really not required you create for both iOS and Android. You can test the waters and if you can’t make some money on one platform, well, chances are you won’t on the other. Look at Fortnite right now. It’s making millions on iOS but there currently isn’t an Android version.  So even big companies shuffle their feet developing for both. But as I was making a Member Check In app, and literally running into my small group of users, half of them with Android phones, I couldn’t create a utility-style app and exclude them.

But I dreaded having to basically start from scratch, with Actionscript 3, a language I felt I barely knew anymore, and publish to a device I didn’t have.  Well, all that anxiety was off base. The more I tinkered with Actionscript, the more amazed I was how similar it felt to Swift.

So am I an Android developer now?

Well, yes and no, I did not go full-immersion into Android by buying a new phone. I bought a $49 Kindle Fire instead. Putting it into Developer Mode was probably the trickiest part getting started (you have to tap a particular setting 7 times, article here). After that, I was able to plug it into Adobe Animate just fine. Along the way I downloaded some Android File Transfer app for the Mac which was unnecessary.

So aside from one stumbling block of enabling Developer Mode, I was impressed how easy it was to just create a new AIR for Android project in Adobe Animate and publish to the device. I eventually ended up testing on a friends older Android phone and it was just as easy.  As many of you iOS devs know, just getting Xcode to publish to your device can be a real pain in the ass. Now that’s changed somewhat recently, but I’ll say this, when things go wrong (and they still do), it’s not easy.  With Adobe Animate the worst problem I encountered publishing to a device was solved by simply unplugging and plugging the Kindle or phone back in.

I will say buying a cheap Kindle Fire for device testing worked great. You can do a lot of testing in Adobe Animate by just creating a swf file (Test Movie), but certain things like popping up a keyboard just don’t fly unless you’re on a device.

The flip-side of that coin is that Kindle Fire is a cheap-ass, $49 device. It’s practically disposable.  I know now why parents don’t seem to mind when their toddler covers them in cheese dip at a Mexican restaurant. It isn’t horrible tech, it just isn’t what I’m used to. Coming from the 2x and 3x resolution of the iOS world, it hurts your eyes.

Ugh, resolution issues…

The low resolution of it is also deceiving too. Because my Adobe Animate project had the scene stage set to around 450 by 800. And per some other blog’s advice, I thought I had it set to scale up for higher resolution devices. Nope. Not even close. So version 1 of my app looked great on the Kindle, but everyone else with a real device was like “Is this an app for ants?!”. Everything was tiny.

My solution was to basically create a variable based on the height of the stage. So this variable would be greater or less depending on the resolution of each device. A kindle might have a height of 1000, whereas some Samsung device might have a height of 1920.  The last line below, shows my variable….

stage.scaleMode = StageScaleMode.NO_SCALE; 

stage.align = StageAlign.TOP_LEFT;

var stagewidth = stage.fullScreenWidth

var stageheight = stage.fullScreenHeight

var heightUnit: int = (stageheight / 20)

Here’s an example of how I used that with an input text field…

pinInput.width = stagewidth * 0.8

pinInput.height = heightUnit

pinInput.x = stagewidth / 2 - (pinInput.width / 2);

pinInput.y = (stageheight / 2) - (heightUnit * 4);

So I made both the height of the input label and position vary based on the heightUnit variable. And this isn’t much different than something you’d need to do in the iOS world as well. That walled garden is a little easier, because you can simply test “hey, is this an iPad” or “is this is an iPhone” and start separating some code off by device family.

Skipping ahead…

I’ll teach some actual lessons on how to get back into the world of Actionscript, AIR for Android and Adobe Animate, but I want to finish up here by saying how impressed I am with the publication process in the Google Play and Amazon App Store. Both of which, I guess I had paid for many years ago (haven’t been charged since), so it was nice to just log back in and upload my .apk file to both. In both stores the app was approved within a day. No comments from any reviewers, and that’s both encouraging and alarming since my first version was apparently terrible for most users.

So there is a Wild West aspect to getting your Android app available to users. Granted, my app wasn’t asking for much permission wise, so maybe if I had toggled on more things in the Settings, they would have scrutinized it more. But all I asked for was Internet access because the app communicated with a website (and funny enough, the same .plist file I created with Xcode to pull dynamic data).

All in all, my experience coming back to Actionscript (and Android) was pretty darn smooth. So I probably need to teach you all a bit of this, huh! =)