Getting back to Android

[Michael Rivera]

I was an android developer circa 2008, now managing people. Im thinking to get a book and some new pet peojects to begin with.

I've head head first before and know for a fact they are a fun and educational book.

Any tips doing android these days?

[Randy Tong]

1. Get familiar with IDE (Android Studio)
2. Always visit Android official website, so you know the latest update
3. Make Coderanch as your best friend :P

[Tim Holloway]

Be aware that the Android you knew in 2008 is not the Android you'll find today.

Not long ago I went to update a project I'd created back about that time and ended up having to re-create it from scratch because so many APIs and facilities were not only obsolete, but the elements that had obsoleted them were also obsolete up to about 5 generations. And since the Internet has little sense of chronology and less of order or correctness, it was a major pain to find the proper resources and their usages. Especially since things are being promoted that haven't even been finished yet.

So before getting any books, check to see how up-to-date they are!

Android is internally a mess for developers due to its inability to remain as a stable platform. Fortunately, it's pretty good from the user point of view. Spent yesterday trying to dig for settings on an iPhone. THIS from the company what got its fame from making computing easy???

[Tim Moores]

Back in the Android 2.x days, it was possible to have one book cover Android (and Android in Action, 2nd ed. did a decent job at that); these days, that's no longer possible. Some things have gotten easier (like using the built-in database, and using Gradle instead of Ant), but generally, an app needs to consider a lot more moving parts. So be prepared for a learning curve.

[David Griffiths]

Hello Michael,

You have picked *exactly* the right time to get back into Android

The language has pretty much switched now, from Java to Kotlin. It's still possible to many things in Java, but some features (such as Jetpack Compose) really need you to be writing code in Kotlin. If you've never done Kotlin before, as a Java developer, you should find it fairly straightforward to pick up. If you are starting (again) on Android, we would strongly recommend that you look at Jetpack Compose. You can still build apps with layouts, fragments and activities, but Compose brings a significantly simpler and more straightforward model to app development.

At this point we can make a very obvious plug for David's course on the Fundamentals of Jetpack Compose which is running online December 7th (a week today)

https://www.oreilly.com/live-events/building-android-apps-with-jetpack-compose/0636920060990/0636920062245/

It's four hours and builds a native application from the ground up in compose, and suggests a general architecture that you might find useful.

There are of course, many other resources available, and Google do seem to have improve their teaching material for Compose, so it is well worht checking it out.

Have fun!

D+D

[Tim Holloway]

One of the more important amenities of the IntelliJ Android Studio is that it can convert Java to Kotlin on a file-by-file basis.

That's important to those of us who are familiar with the original setup under Java and/or have legacy Java code we're trying to pull in.

My last Android project was re-written in Java because I didn't have head space to both find the latest way to talk to the UI, databases and webapp servers with callbacks and other kinks and to get familiar with a new language, but many of the online help sites provide dual Java/Kotlin examples.

The writing is on the wall, though. At some point Kotlin is probably going to be the Android programming language.

[David Griffiths]

Good point Tim. Also, Android Studio will also offer to convert any pieces of Java code you try to paste into the editor, which is very clever.

D+D

[David Griffiths]

Also, Kotlin has many features that make it worth looking at in its own right. One example (and one that we wrote about in "97 things every Java Programmer Should Know") is co-routines. Co-routines are pieces of code that have the ability to be paused and re-started.

Imagine a chef in a kitchen making a meal. They might need to make a sauce, and prepare some vegetables, and fry some things. They will *kind of* do them all at the same time, but in reality, they will briefly stop chopping vegetables whilst they check on the sauce, and so on. That's what co-routines are: they are distinct tasks which can "kind of" be run at the same time. They are often described as "lightweight threads" because they can be used for the same sorts of tasks as threads. But unlike threads, there aren't the same physical limits to number of co-routines that can run at the same time. It's quite straightforward to have 10,000 coroutines all running *kind of* at the same time.

Here's an example Drum machine we did for "97 things":

https://github.com/dogriffiths/KotlinDrumMachine/blob/master/src/main/kotlin/DrumMachine.kt

It's a single thread, that uses multiple co-routines to play parallel drum tracks *all at once*.

This same sort of magic is now used in Android development to greatly simplify things like running code on the UI thread, or respond to asynchronous code returning data from a database in a view-model. Kotlin allows for these more powerful abstractions, and it's the ground work of much of the work on Android that is now starting to roll out.

D+D

[Tim Holloway]

Windows had a similar "not-thread-thread" called a Bundle or Fiber. Never really caught on there.

But anything that can replace asynchronous callbacks is very worth having. Those   s have been my nemesis in both Android and NodeJS.

[David Griffiths]

Exactly!

In fact, back in the days before Windows 95, when dinosaurs still ruled the Earth, Windows 3.1 had a cooperative multi-tasking model where an application could make regular calls to allow other applications process events. It's a similar idea in co-routines, some suspendable functions (like "delay") allow other co-routines to take a turn.

D+D

[Tim Holloway]

The Apple Macintosh has the honor of being the first co-operative multi-tasking OS. Windows had the weird characteristic that each native (GUI) app ran in a co-operative space, but the DOS command windows each occupied an actual pre-emptively dispatched VM.

Then Commodore (Amiga) came along with the first true 100% real-time pre-emptively multi-tasking OS. Linux is generally built as a non-real-time pre-emptive OS, although it can be built for real-time operation. It's often done so for setting up Digital Audio Workstations and the like.

[Tim Holloway]

Disclaimer: The preceding is, of course, all PC operating systems. Mainframes and minicomputers were doing all sorts of multi-tasking and time-sharing long before 1975 and the first consumer PC.