11 votes

I want to learn Android (with Kotlin) ... should I focus on Jetpack or the old XML style?

I am an experienced programmer (mostly M$ stack -- C#, etc).

I started learning mobile Android development a few months ago, learning both Kotlin and the larger Android development environment at the same time. I got bogged down in tutorials and guides, because half of them teach Jetpack Compose methodology and half teach XML layout ... and, often enough, don't bother to mention which method they're using.

Which should I learn first? I am initially interested in learning Android dev for my own hobby/fun/side projects, but I would--ultimately--like to be able to put "Android developer" on my resume.

Jetpack definitely looks better, more modern, more OO, and I expect it will eventually become the new standard ... but that could still be many years down the road. Also, while it might be "better"--especially for larger projects--it also smells more complicated.

So, ultimately, I guess I should learn both if I actually intend to become an Android dev ... but I should definitely get comfortable with one, first ... so, which one?

9 comments

  1. talklittle
    Link
    Probably Jetpack Compose. You're starting without legacy code, for better and for worse. You will be more productive sooner using Jetpack Compose. For people coming from an XML codebase, they can...

    Probably Jetpack Compose. You're starting without legacy code, for better and for worse. You will be more productive sooner using Jetpack Compose.

    For people coming from an XML codebase, they can leverage a lot of that code and it will continue to work out for a long while to come. So they need to weigh the decision more carefully. IMO it's valid to stick with XML style views forever (read: as long as Google supports it). Not every app needs to be rewritten for the sake of using new frameworks.

    There are some drawbacks to Compose, like immature ecosystem library support. For example, ExoPlayer is the de facto video player library in Android apps, and doesn't yet have Compose support: https://github.com/google/ExoPlayer/issues/9654

    So depending on what app you're making specifically, you may find that you're forced to use traditional views and XML.

    On the other hand, XML views have pretty much every problem and quirk solved by another dev already, and you can find the answers online. Also, Compose might require you to rewrite as the API evolves. So it also depends a bit on whether you will be bothered by API deprecations and rewrites.

    9 votes
  2. GoatOnPony
    Link
    I worked on an android app professionally for 5 years, but I haven't seriously touched android in the last 2 years. My team was just examining whether to switch over to compose when I left and...

    I worked on an android app professionally for 5 years, but I haven't seriously touched android in the last 2 years. My team was just examining whether to switch over to compose when I left and I've dabbled with it a bit in my spare time.

    If I were starting an app today I'd use Compose, but there's a couple criteria you could use to pick between them:

    • Preferred programming style: if you're a fan of functional programming, unidirectional data flow, compositional and stateless components, compose is heavily reliant on those paradigms. If you like react, compose is amazing. If you want java style subclass OO where objects hold state, regular views might be more familiar.
    • Performance: Views require/will by default use a bunch of tricks to try and get better performance. Learn to love recyclerviews and constraintlayout. Compose has better baseline performance but if you run into trouble you might have fewer tools to bail you out.
    • Future proofing: Compose is the likely future, but it will still be a while before the ecosystem is done adjusting. Compose is also multiplatform, which is quite nice if you want to learn one UI framework for desktop, web, and mobile. But, if you want to use it professionally, be prepared that you might still need to understand regular Views and XML layouts for existing code/if the team has decided to wait to use Compose. Also I personally find that stack overflow for android view code is really hit or miss, a lot of answers are not up to date or encourage some very hacky solutions.

    Also note you can mix and match - compose can embed regular views and vice versa.

    3 votes
  3. pete_the_paper_boat
    Link
    So I'm not an Android Dev, but have messed around with it years ago. So I've only quickly compared syntax. But I'd say the learning curve for XML is (and probably after Jetpack) so much shallower...

    So I'm not an Android Dev, but have messed around with it years ago. So I've only quickly compared syntax.

    But I'd say the learning curve for XML is (and probably after Jetpack) so much shallower than Jetpack, that you'd probably be able to read through the XML and "get it", even if you put your time into Jetpack.

    Also, AI can probably help with XML easier than Jetpack, so if I had to choose which to really learn, I'd go with the domain specific language.

    2 votes
  4. [3]
    phoenixrises
    Link
    I'm an Android Dev for my day job (currently sitting on some code to merge before the holiday break)! From what I've heard in the Android Dev conventions that I've participated in, it seems like...

    I'm an Android Dev for my day job (currently sitting on some code to merge before the holiday break)!

    From what I've heard in the Android Dev conventions that I've participated in, it seems like many of the big companies have been slowly migrating or building their new views on Compose nowadays. I'm currently not writing any new XML myself (team of 1 though, so I get a lot of leeway). XML is relatively easy to learn as well anyways, pretty self explanatory, but also super old and doesn't play nice with some of the new architecture patterns. Feel free to ask me anything about Android dev, we're a pretty rare breed :)

    2 votes
    1. [2]
      Eric_the_Cerise
      Link Parent
      I was hoping you'd weigh in. Just 'cuz it's simpler, and Old-School (like me), I'm going to focus on XML this next time around (I tried Jetpack the first time — it looks promising, but complicated...

      I was hoping you'd weigh in.

      Just 'cuz it's simpler, and Old-School (like me), I'm going to focus on XML this next time around (I tried Jetpack the first time — it looks promising, but complicated and too many confusing guides/answers online, at least for me).

      Also, to start, I'm doing a fairly small, cheesy, mostly-text-adventure video game that does not require a lot of advanced UI. If/When I succeed in deploying that to F-Droid, then I'll dive into something more serious, w/Jetpack.

      But anticipate some questions from me in the coming month or two...

      Thanks

      2 votes
      1. phoenixrises
        (edited )
        Link Parent
        Feel free to message me about anything or tag me for these kinds of questions :) XML is definitely still a thing especially with older legacy code bases so it's still worth knowing for sure! And...

        Feel free to message me about anything or tag me for these kinds of questions :)

        XML is definitely still a thing especially with older legacy code bases so it's still worth knowing for sure! And like talklittle mentioned above, there's a lot of things people have figured out already that you can leverage.

        The only major thing you lose in my eyes is the ease of lazy columns and rows, but Recyclerview and it's quirks and boilerplate is something most android devs get to learn anyways.

        The only other thing I'd mention is trying to learn actual mobile architecture. I'm solely a mobile developer so idk how it changes with other platforms, but knowing some MVVM (nowadays there's some new architecture innovations that look really fun, like Circuit over at Slack) will help you in the long run, especially when trying to secure a job in the field or scaling up your own product for multiple devs. (This is coming from someone who's worked in monolith repos and specifically worked on breaking it out to separate modules, easier to properly modularized it in the first place. A good dependency injection framework will help a lot for that.)

        In XML constraint layout is your friend :)

        Also a quick note! Technically Compose and XML's can exist in the same code base so don't feel pressured to make a definitive decision. I simply stopped writing my new views in XML and switched to compose with a few architecture tweaks.

        1 vote
  5. [3]
    pyeri
    Link
    How is the resource use of android studio and the whole SDK toolchain these days? The last time I had tried was in 2018-19 and it wasn't a very nice experience. It seemed every bit of my RAM was...

    How is the resource use of android studio and the whole SDK toolchain these days? The last time I had tried was in 2018-19 and it wasn't a very nice experience. It seemed every bit of my RAM was used for sustaining the Studio, SDK Manager, AVD (Devices), etc. and I couldn't do anything else on my PC! Even Visual Studio with multiple projects open doesn't eat that kind of resources! Has the situation improved these days?

    1 vote
    1. phoenixrises
      Link Parent
      It's still a bit hefty for sure lol. They've made a lot of upgrades recently, and I personally haven't noticed too much difference, but my work provides me a really beefy Macbook Pro so I wouldn't...

      It's still a bit hefty for sure lol. They've made a lot of upgrades recently, and I personally haven't noticed too much difference, but my work provides me a really beefy Macbook Pro so I wouldn't feel it much anyways. Visual Studio does perform much better on the same Macbook Pro though.

      2 votes
    2. Eric_the_Cerise
      Link Parent
      Huge resource hog from my limited experience. I set up my dev environment in a dedicated Ubuntu VM, and required 16G of RAM and 2 (4?) cores to even begin to get responsive build/run times ... not...

      Huge resource hog from my limited experience.

      I set up my dev environment in a dedicated Ubuntu VM, and required 16G of RAM and 2 (4?) cores to even begin to get responsive build/run times ... not sure, but I think Jetpack contributed to the logjam.

      1 vote