Jetpack Compose: First Impressions and Learning Resources

Android’s current UI toolkit is over 10 years old now… Do stop me if you’ve heard this before 😉

As you most certainly already know, Jetpack Compose is the hot new thing for Android UI development. Its promise is to save us by making all the pain points of the old View system and XML layouts go away.

After many many preview versions, it got to beta status about a week ago. Here’s what it’s like to use Compose at the moment, and some of the best places to learn more about it.

The good

First of all, Compose is exciting. It makes a lot of basic UI work really simple, and you get to write it all in Kotlin, making use of all the language’s powerful features! The APIs have great discoverability in Android Studio, since all of it is just Kotlin code that you can access via code completion. This makes it truly easy to get started.

Kotlin’s type safety also works wonders in Compose. No passing in dp values instead of pixels, or mixing up vertical and horizontal alignment options. Everything is strongly typed, and the compiler safeguards you from making many, many mistakes.

The declarative style and state management of Compose is great as well. Writing down what you want to appear based on state is not only clear and explicit, but also a blessing after the problematic state management of the View system.

Given how much effort is going into developing and marketing Compose, it’s almost certainly the future of Android UI development. That being said, the XML system will probably never fully go away. Just like the Java to Kotlin shift, it will take a couple years until the new standard really kicks in, and we’ll occasionally still find ourselves interacting with code from the before times.

So… Get on board soon, just don’t expect all of the old system to disappear overnight. I’d certainly still suggest learning the old XML based system to anyone starting Android Development today — unless they’re somehow very certain that they’ll never work on an existing project.

Jetpack Compose comes with some cool Android Studio tooling as well. Flutter users will probably already be familiar with the handy Surround with shortcuts that let you wrap pieces of code in a new widget, and the same makes an appearance in Studio now.

Select some code, invoke Surround with (Ctrl+Alt+J on Windows, ⌥⌘J on macOS), and then hit R for a Row, C for a Column, or W for an arbitrary widget.

Another quick tip: creating a new Composable will immediately add a parameter list and a body to it, and then place your cursor inside its parameter list, to let you immediately add modifiers and other parameters.

If you don’t want to add any parameters, you can hit Tab to quickly skip to defining its content.

The bad

Now, let’s see the bad part, continuing with the tooling theme. To run Compose, you’ll have to run the latest Canary version of Android Studio. This version has… Some issues.

From my personal experience of a few days:

  • IDE Previews (which would be a really nice feature for Compose) sometimes don’t load at all, or don’t update as changes are made (even after rebuilding). Re-running either the full app or just deploying a @Preview to a device was faster than using the IDE preview feature 100% of the time.
  • The debugger never connected to either an emulator or a physical device when running Compose apps. Still didn’t manage to solve this, though I heard others had more success.
  • Logcat doesn’t show app names when running apps, making it difficult to filter the logs for the current app.
  • When running the emulator in a tool window inside the IDE, the emulator tab occasionally doesn’t appear in the preview version of Studio. I had times when I used the emulator tab inside another project in a stable Android Studio instead… I eventually gave in and reverted to using an emulator in a separate window.
  • Sometimes Studio just froze up entirely, and its process had to be killed and restarted. This happened about once a day or so.

I heard some similar anecdotal stories from others, including excessive resource usage when using Compose compared to other projects. These were occasionally fixable by restarting, invalidating caches, restarting adb, and similar “usual” debugging practices.

Another pain point of using Jetpack Compose can be that looking up how to do things is a bit hit-and-miss for the time being. For example, when you land on StackOverflow questions about it, you’ll often find answers that say “this is how to do it in dev11”, or “here’s the new API for this in alpha3”, but then none of those APIs will be present in the current beta version.

Of course, on one hand it’s nice that Compose went through a lot of iteration and they weren’t afraid to change and evolve APIs — that’s what the preview versions are for.

On the other, it makes for a somewhat unpleasant experience for developers trying to build things on the latest Compose version. Thankfully this situation will naturally improve over time, but we’ll have to wait a bit to get enough new, up-to-date answers in.

The resources

Since StackOverflow won’t be your best friend for learning Compose yet, where else can you go?

First, there’s Google’s official resources, which are a decent start:

  • Their best resource by far is the written documentation pages — get started with them here. These include a lot of helpful explanation and snippets for designing things in Compose, and also touch on more advanced topics like navigation, architecture, and interop with existing code.
  • There’s a lot of video content about Compose as well, under the #AndroidShow branding. I’ll recommend skipping most of this, especially the livestream and Q&A parts — they’re not really developer-focused, and contain a lot of hype and marketing.
    What contains a lot of value, however, are their screencasts about Compose features (which are also included in sections of the written docs). You can find these in this YouTube playlist.
  • If you’re new to Compose, the Beta overview video is also worth watching. For more longer-form introductory content, these videos from last year are all really helpful: Jetpack Compose, Thinking in Compose, Compose by example, and Compose for existing apps.
  • For hands-on practice, take a look at Google’s Compose Pathway that includes videos, articles, and code labs. This goes into significant detail in some parts — feel free to skip the things you’re not interested in learning deeply immediately, otherwise it’ll take a long time to get through it.
    I also found that some of the codelabs here were outdated (not using beta1 APIs yet), so be prepared to fiddle a bit with the code snippets provided, or to debug dependencies. Again, this is something that will be improved soon.

If you prefer reading, RayWenderlich team’s Jetpack Compose book has really solid, professional content in it, providing a complete tour for you to get started with: A nice exploration of the basic UI building blocks of Compose, as well as multiple example apps. (This, again, is slightly outdated, as its samples use alpha10. Fingers crossed that it gets a revision soon.)

For even more long-form video explanations, guidance, and demos, Exploring Jetpack Compose and Advanced Jetpack Compose by Filip Babić are both excellent.

To find quick snippets for how to perform basic things, the Compose Academy site can come in handy.

Finally, exploring Compose on your own is also a great way to learn about it. All of the APIs you use are just Kotlin code, so exploring through code completion, and jumping into the underlying implementation in Android Studio to read the source are super easy. The in-code documentation for most Compose APIs also tends to be excellent.

Conclusion

Are you excited and ready for Jetpack Compose? We know that we are, and you can look forward to more Compose content from us soon, including in our Android Chat SDK.

Tweet at us @getstream_io and tell us what you think about Compose, and what you found to be the most useful way to learn about it!

Originally published at https://getstream.io.

Click 👏 to say “thanks!” and help others find this article.

To be up-to-date with great news on Kt. Academy, subscribe to the newsletter, observe Twitter and follow us on Medium.

If you need a Kotlin workshop, check how we can help you: kt.academy.


Jetpack Compose: First Impressions and Learning Resources was originally published in Kt. Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Continue Reading Jetpack Compose: First Impressions and Learning Resources

Kotlin Heroes: Episode 6 Is Here

Registration for Kotlin Heroes: Episode 6 is open. This coding challenge is co-hosted by JetBrains and Codeforces, the most popular platform for programming contests. It is a great opportunity to learn about the features and capabilities of the Kotlin language.
Register now and save the date: March 9, 2:35 PM UTC.


“Programming contests are a great way to test your programming skills and improve them. Whether you are a seasoned competitive programmer or a Kotlin developer who has never participated in a programming contest before, you’ll find these contests useful, entertaining, and thought-provoking. They’re designed to give everyone a chance to win prizes. We hope that you’ll find the Kotlin language fun and enjoyable to use and that you will keep using it in other programming contests.”
— Roman Elizarov, ICPC Live Director, Project Lead for Kotlin


The contest features a set of problems designed for both beginners and seasoned competitive programmers. Competitive programming is a mind sport where contestants write programs to solve precisely formulated algorithmic problems within strict constraints. The problems range from simple ones, which can be solved by any developer and don’t require much code, to complex ones that demand knowledge of specific algorithms and data structures, and lots of experience.

The top three winners will receive prizes of $512, $256, and $128, respectively. The top 50 contestants will win a Kotlin Heroes t-shirt and exclusive Kotlin stickers. Every competitor who solves at least one problem will enter a drawing for one of the 50 exclusive Kotlin Heroes t-shirts.

Before the Kotlin Heroes: Episode 6 begins, you are invited to test your programming skills in a practice round. On March 9, you are invited to take the real challenge and compete for prizes.

Check out our page about Kotlin Heroes to learn more about the format of the competition, and resources available for preparation.

To get ready for the challenge, you can read our tutorial on competitive programming in Kotlin and watch the videos from our Competitive Programming playlist on YouTube.

See you soon!

Continue Reading Kotlin Heroes: Episode 6 Is Here

Using coroutines to save my tree-like modal to the file system. Is my (beginner) approach okay?

In my JavaFX program I am attempting to save my modal to the users file system without freezing the UI. I’m trying to do this with kotlin coroutines JavaFX dispatcher. This is pretty much my first attempt with kotlin coroutines so I’m concerned I’m making simple errors.

For simplicities sake the modal consists of:

  • Book

    class, which contains a list of instances of a…

  • Page

    class, which contains a list of instances of a…

  • Content

    class.

This naturally lends itself to a tree like structure, and I want this structure to be similar on the user file system (There is a book folder, inside of which is a folder for each page, and inside each page is a text file of whatever is in the content class).

Previously in other projects I simply created a

FileIO

class that dealt with saving and loading the modal from the file system. This often became bloated so I wanted to try something more organized this time.

Firstly I created a

Savable

interface which consists of a single function

suspend fun save(saveFolder: File)

.

Book

,

Page

and

Content

each implement this interface. The idea is each class is responsible for saving itself to the file system.

Secondly I had the

Book

class extend

CoroutineScope

. My naive implementation of its save function was:


override suspend fun save(saveFolder: File) { val jobs: List<Job> = pages.map { page -> coroutineScope { launch { page.save(saveFolder) } } } jobs.joinAll() // wait until all jobs are finished }

After some research I saw that Here It says “A parent coroutine always waits for completion of all its children. A parent does not have to explicitly track all the children it launches, and it does not have to use Job.join to wait for them at the end”. I also read from this reddit comment that there should be a single top level scope that all other coroutines are launched in. Since it appears that

coroutineScope {}

creates a new scope I think I should instead be passing the

Book

scope in the

Savable

save function, which now looks like:

suspend fun save(saveFolder: File, scope: CoroutineScope)

The save function of

Book

is now:


fun saveBook() { launch { val folderToSaveIn = askUserForFolder() save(folderToSaveIn, this) } } override suspend fun save(saveFolder: File, scope: CoroutineScope) { pages.map { page -> scope.launch { page.save(saveFolder, scope) } } }

And likewise the

Page

save:


override suspend fun save(saveFolder: File, scope: CoroutineScope) { // creating the page folder omitted contents.map { content -> scope.launch { content.save(pageFolder, scope) } } }

And finally the

Content

save just creates a textfile with its contents.

  • Is this approach an okay way to go about the problem?
  • If one of the coroutines hits an IOException for whatever reason, is it okay to just call
    scope.cancel()

    to shut the whole thing down?

  • What pitfalls should I look out for, or what features should I implement here? I’m looking to eventually license this software out to users so I want to really get the saving/loading done right.

I am new to coroutines so nudges and pointers to improve my approach would be welcome!

submitted by /u/SamKeene
[link] [comments]

Continue Reading Using coroutines to save my tree-like modal to the file system. Is my (beginner) approach okay?

Best practices Coroutine Scope for Spring Components

Hello

I’m trying to figure out how to handle CoroutineScope in Spring managed beans. What I want to do is to use coroutines internally in a component.

Maybe I want to launch a coroutine doing some task and just return to caller. Or do some async operations and combining in some context. Or simply call other services that offer suspending functions.

Currently I have some outside code that expects a Java CompletableFuture. I compute this using a bunch of chained thenApply, thenCombine etc which is a nightmare to read and maintain. I’m looking to rewrite it using coroutines. (I’m familiar with future coroutine builder, but it still needs a scope!)

I understand that using GlobalScope or creating a scope on the fly via CoroutineScope is advised against since it works against structured concurrency

From the very limited information there is to find about this, I’ve seen someone suggest that the component itself implements CoroutineScope, and a reference to a parent job is kept, which can then be cancelled during spring destruction.

Is that a good approach? Any other alternatives or best practices? Or should coroutines not even be used in this manner at all?

submitted by /u/FederalSignature
[link] [comments]

Continue Reading Best practices Coroutine Scope for Spring Components

End of content

No more pages to load