Recently, an implementation of stunning Parallax effect in SwiftUI by Philip Davis has been making rounds in the Android Community too.

So, I decided to try implementing the same using Jetpack Compose instead. The results turned out pretty decent and also well received by our lovely Android Twitter Community. 😁

suraj・🍜・🍙 on Twitter: "Tried it on #JetpackCompose !🥳 #AndroidDev @JimSproch https://t.co/Ic1LMruPzD pic.twitter.com/vxTJDiF1Wm / Twitter"

Tried it on #JetpackCompose !🥳 #AndroidDev @JimSproch https://t.co/Ic1LMruPzD pic.twitter.com/vxTJDiF1Wm

Implementation

The following explanation is completely based on this gist.

Fetching Sensor data

The @Composable views will be repositioned according to the orientation of the device. And we’ll be needing the orientation values along the ‘Pitch’ and the ‘Roll’ axes.

I’ve referred to this StackOverflow reply for my implementation of fetching the Pitch and Roll values.

Android phone orientation overview including compass

Register SensorManager listeners

Using DisposableEffect we’ll be initialising the SensorManager and also register listeners for the GRAVITY & MAGNETIC_FIELD sensors.

Finally the Pitch and Roll are received within the @Composable using Channel.receiveAsFlow().collect().

One may say that we could’ve LaunchedEffect instead since we’re only collecting our sensor’s data Flow. I’ll explain why I went with a DisposableEffect in the end (it has something to do with onDispose{}).

Now, once we have the Pitch and Roll values from our sensor, we’ll now be looking into how we can reposition various @Composable views to achieve the parallax effect. Philip Davis has himself graciously hinted at his implementation:

• repositioning the Image Card
• repositioning the Glow Shadow (reverse of the Card). I used Philip’s Glow Shadow implementation as reference for this.
• showing a subtle Card edge when tilted, for the pronounced 3D effect
• adding a parallax to Image inside (reverse of the Card)

Image Card

[1] we’re using Modifier.offset to reposition our @Composable views.

[2] Roll is along the y-axis while Pitch is along the x-axis. So, the x-offset will be decided by the roll while y-offset by the pitch.

[3] We bring about the inside Image’s parallax effect by adjusting the horizontalBias of @Composable Image() alignment parameter.

Glow Shadow

[1] Glow Shadow’s offset will reposition quicker than the Image Card and in the opposite direction.

[2] It’s size will be smaller than the Image Card.

• When the device is kept on a Flat surface (all orientation values close to 0), the glow shadow should not be visible.
• The darker portion of shadows are generally smaller than the actual object.

[3] Instead of a traditional shadow, use Modifier.blur() to make the Image Card appear translucent which is letting in light onto the surface.

Card Edge

[1] Card Edge’s offset repositioning will be slightly flower than Image Card.

• The edge shouldn’t be visible when kept on a Flat surface.
• The edge should ‘just’ be visible when the device is tilted to give the impression of a thin 3D card.

[2] It’s size will be same of the Image Card.

Points of Caution

Unregister cancel fetching of sensor data in DisposableEffect.onDispose{..}

We must prevent unnecessary leaking of SensorManager when this view is removed from the composition. That is the reason why I used DisposableEffect instead of LaunchedEffect since we get this convenient onDispose{} callback where we can clean up any unnecessary data upon leaving composition.

Use the right Modifier.offset method

Jetpack Compose provides two kinds of Offset modifiers:

• .offset(x: Dp = 0.dp, y: Dp = 0.dp)
• .offset(offset: Density.() -> IntOffset)

While these do the same thing i.e., set positional offset to the @Composable view, IF we are going to use dynamic offsets (for example, offsets changed due to certain animation or user action etc.) instead of fixed offsets, we should always use .offset(offset: Density.() -> IntOffset i.e., the lambda version. The reason being, the latter method avoids recomposition when the offset is changing values, thus significantly improving the performance. Even the documentation says,

This modifier is designed to be used for offsets that change, possibly due to user interactions. It avoids recomposition when the offset is changing, and also adds a graphics layer that prevents unnecessary redrawing of the context when the offset is changing.

Concluding

While this isn’t the most performance efficient implementation, hope this can help as a handy reference for the same.

Jetpack Compose and Swift UI are the best tools to realise high quality visual effects in such a short period time. I certainly believe that these two platforms will empower Mobile Developers to create beautiful experiences for the users. 🥳

Do share your solutions, suggestions and feedback on Twitter. Can’t wait to see what the community comes up with next 😁 It’s a nice time to be an Mobile Developer.

Parallax Effect with SensorManager using Jetpack Compose was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article will do a code walkthrough of implementing Google Translate’s character recognition (along with text translation) in Jetpack Compose using MLKit’s DigitalInk and On-device Translation.

Here’s the source code of my implementation.

GitHub - surajsau/ML-Android: Implementing various ML usecases in Android

Drawing on Canvas

Let’s setup a @Composable Canvas where users will draw the characters on screen.

This is a standard use-case where we intercept the touch events on the View and translate it as a Path on the canvas. Extending it to Jetpack Compose,

• Using Modifier.pointerInteropFilter we get the MotionEvent similar to that obtained in android.view.View OnTouchListener.
• For convenience I’ve created sealed class DrawEvent which will be mapped to the corresponding MotionEvent.
• remember the Path object, since it’ll not be changing over recompositions. Setting value to mutableStateOf<DrawEvent?> within the callback will trigger recompositions where either a new subpath is created or the current one is modified.
• path.lineTo() would also do instead of path.quadraticBezierTo(). I’ve gone with a quadratic subpath only to smoothen out sharp corners.
• Finally, at the end of each composition calldrawPath()

MLKit’s Digital Ink

MLKit by Google provides Digital Ink, a ready-to-use package for character recognition for over 300+ languages. It is also powers the handwriting recognition for services like Gboard, Google Translate.

The main components that we will be primarily dealing with are Ink.Stroke, DigitalInkRecognitionModel and DigitalInkRecognizer.

Let’s initialise them as we discuss their purpose.

• Ink.Stroke : this data object contains the list of coordinates (Ink.Point) information of the drawn shape which is the input to our RecognitionModel. MotionEvent coordinates obtained in the callback are then added to this.

• DigitalInkRecognitionModel : this is the ML model corresponding to the specific language whose characters are to be recognized. The builder takes in a ‘modelIndentifier’ to specify the language of character recognition. For this example we’ll be using the Japanese Language model, so we pass DigitalInkRecognitionModelIdentifier.JA
• DigitalInkRecognizer : this takes in the generated Ink.Stroke as input to the ML model and outputs a result of characters predicted by the model.

Checking Model’s availability

Before we use Digital Ink, for it to support language-specific character recognition the language specific ML model data (roughly, 20MB per language) needs to be downloaded and available locally.

You can checkout Digital Ink | Managing model downloads for more details. Here’s my code for reference.

Building Ink.Stroke & Recognizing

With a drawable Canvas and MLKit model ready, let’s add callbacks to handle building Ink.Stroke and triggering Recognizer.recognize() when done.

For convenience I’ve added sealed class DrawEvent mapped to the corresponding MotionEvent.

Inside the onDrawEvent callback,

• MotionEvent.ACTION_DOWN, MotionEvent.ACTION_MOVE: This indicates that the user is touching the canvas to draw. We add the obtained event coordinates to Ink.Stroke.Builder
• MotionEvent.ACTION_UP: This indicates that user has stopped touching the canvas thus signalling end of drawing. We can now build the generated Ink.Stroke and pass it to Recognizer.recognize().
  In onSuccess we get back the prediction results (RecognitionResult.candidates) for display. In onComplete we reset the Ink.Stroke.Builder to start taking in coordinates of the next character to be drawn.

At this point the above code snippet runs fine. However, in the example below the predictions results aren’t correct at all.

While some characters can be written in a single stroke, characters like i, t & complex characters like 終, even in cursive, cannot be written in one stroke. Every MotionEvent.ACTION_UP calls Recognizer.recognize() where we reset Ink.Stroke after receiving the results. So instead of passing coordinates of all subpaths combined, we’re calling .recognize() for each individual subpath.

This issue can be mitigated, by adding a ‘debounce’ like behavior which will prevent successive .recognize() calls for a specific time period after MotionEvent.ACTION_UP.

Adding debounce

To implement debounce, we have to cancel out all successive calls to Recognizer.recognize()for a specific time period (the debounce offset) after MotionEvent.ACTION_UP. There might be better ways to implement it, however this is the solution I came up with.

We add a delay(offset) within a coroutine before calling Recognizer.recognize() in MotionEvent.ACTION_UP. We can then cancel the launched coroutine in the next MotionEvent.ACTION_DOWN.

If user touches the Canvas within the specified delay, the launched coroutine is cancelled thus avoiding Recognizer.recognize(). This will allow users to add multiple strokes as long as they start drawing the next stroke (trigger the next MotionEvent.ACTION_DOWN within this specific offset.

MLKit’s On-device Translation

Implementing text translation is pretty much similar as above, instead we’ll be using MLKit’s On-device Translation. Like the name suggests the translation model runs on your device without requiring internet, which is why it might be slightly inaccurate at times.

Like DigitalInkRecognizer in Digital Ink, we’ve Translator here. This handles both downloading the translation as well as translation. While initialising Translator we’ve to specify the source and target languages. Rest of the implementation is pretty self explanatory.

Finally .close() everything

Even in the documentation it is mentioned clearly to .close() the Translator & Recognizer objects if no longer used. We can add a lifecycle observer and close those objects in LifeCycle.Event.ON_STOP.

Thank you for sticking along this pretty long read! 😅

This article is a part of Goodpatch’s Advent Calendar 2021🎄 We have a series of wonderful articles lined up for you this holiday season. While most of the articles will be in Japanese, if you are interested in going through the contents, you can use DeepL translator. It gives pretty accurate translations for technical articles in Japanese ♨️

On-device Google Translate with Jetpack Compose & MLKit was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Drag and Drop reordering in Recyclerview can be achieved with ItemTouchHelper (checkout implementation reference).

Jetpack Compose v1.0 has been out for quite some time now 🎉

Android Developers on Twitter: "🚀 Version 1.0 of #JetpackCompose is here! See how Android's modern, native UI toolkit is fully stable and ready for you to adopt in production ↓ https://t.co/IF2Z281hWn / Twitter"

🚀 Version 1.0 of #JetpackCompose is here! See how Android's modern, native UI toolkit is fully stable and ready for you to adopt in production ↓ https://t.co/IF2Z281hWn

At the time of writing this article in v1.0, Compose’s RecyclerView counterpart LazyColumn・LazyRow don’t have an implementation for Drag and drop, though Support Drag and Drop is very well a part of the Compose Roadmap.

In the meantime, I tried implementing basic Drag-n-Drop with the existing APIs.

Check this gist for the detailed and entire implementation of Drag-n-Drop.

In this article I’ll walk you over the key portions of code to help you understand the implementation.

Drag on Long-press

LazyListacts similar to RecyclerView, where reordering of data doesn’t reorder the View instances, instead recycles to reuse them.

So in this implementation, instead of applying Long-press gesture detector to the Modifier of each individual list element, which may require complex handling of View-Data mapping, we’ll add it to the Modifier of the LazyList itself. We can then translate the captured drag event of the LazyList onto the individual elements.

Determining the element to be dragged

With LazyColumn’s LazyListState keeping track of the visible elements (check LazyListState.visibleItemsInfo), we determine the element to be dragged by checking whether the drag’s start offset (in onDragStartcallback) lies within the bounds of any of the elements.

This will help us ‘remember’ the initial offset from where drag event had begun throughout further recompositions.

With the initial offsets and element to be dragged determined in onDragStart handled, let’s move onto onDrag when the actual drag happens.

While Dragging

Once the dragged element has been identified, we now determine the element over which the dragged element is currently hovering on. We then shift it up or down (based on drag direction) and shift the item in the List` or `Array` also to trigger recomposition of the `LazyList`.

Translating the dragged element

With the drag event’s initial offset determined, we can translate the drag event’s offset to the dragged element by the cumulative sum of offset value from the onDrag callback.

Identifying currently hovered items

As an element is dragged, it’ll be crossing over the other elements and based on the direction, once the element crosses a particular “threshold” of the element it is currently crossing (or hovering upon), reordering of the List will be triggered.

The elements which fall beyond the top or bottom of the dragged element are not considered as hovered upon.

Determining the element to be replaced

Once the list of hovered elements are determined we then choose the first element, based on drag direction, whose the top or bottom (the threshold in our case) has been crossed over by the dragged element.
This element will be the one that the dragged element will be replacing.

Trigger reordering of List

With the to-be-replaced element determined, we can trigger a recomposition of the LazyColumn with the List of updated positions.

Handling overscroll

In any typical Drag-n-Drop reordering list, it is expected that the list autoscrolls when an element reaches either visibile thresholds of the screen.

To implement this, we first check if the dragged element has crossed either of the visible thresholds and calculate the overscolled offset. If there’s a non-zero offset, we can then initiate a scroll by calling `LazyListState.scrollBy(offset)`.

Checking for any overscroll

In case of a positive draggedDistance which indicates drag in the downward direction, if the ‘bottom’ of the dragged element crosses the visible bottom threshold (check viewPortEndOffset) of the LazyList we can confirm that the element has over-scrolled beyond the visible bottom.

On the other hand, a negative value we would be looking for if the ‘top’ of the dragged element crosses the visible top threshold (check viewPortStartOffset) of the LazyList.

Drag Interrupted

Reset variables on interrupting the Drag

On cancelling or ending the drag, all the remembered values are to be reset. so that the dragged element settles at its latest position in the LazyColumn

Conclusion

While this might not be the most optimal solution in terms of composition optimisation for Drag-n-Drop. Hopefully this gave a little insight into the APIs of LazyList・LazyRow provided in v1.0.

Meanwhile, I wait curiously to see how the Compose team implements the Drag-n-Drop support 😁

Happy coding 💻 and stay safe during these trying times 😷

Basic Drag-n-Drop in Jetpack Compose was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

ki is a Kotlin Interactive Shell developed by the folks at JetBrains.

One of my colleagues recently shared a neat little Ruby script to get an ad-hoc localhost webpage up and running with all deeplink URLs.

We’ll be doing a similar exercise with ki.

Even though ktor would be the popular choice for this article only for simplicity sake (number of modules to be loaded to get things up and running), I’ll be using Javalin as the web framework of choice.

Let’s get started

A very helpful feature of ki is that you can import libraries on the fly. Let’s import javalin by using the :dependsOn function. Once downloaded, import io.javalin.Javalin into your shell.

Using the :paste mode, we’ll be assigning our HTML string to a variable val html

With Javalin imported and HTML string ready for use lets create our server and provide an endpoint /deeplink which will provide our ad-hoc webpage.

Then, javalin.start() with your desired port (7000 in this case), to fire up the localhost server.

Testing on emulator

With javalin started on localhost:7000 we now verify our ad-hoc webpage on an emulator.

Use your system’s ip-address (using ifconfig on Mac) to access the webpage from your device’s browser.

In the example,

• running ifconfig gives 172.20.10.3 as the system’s ip-address.
• since we started Javalin on the port 7000, we fire 172.20.10.3:7000/deeplink
• Google External has https://www.google.com as the URL and hence opens the webpage.
• The Twitter link has twitter://user?id=monsterhunter the URL which is the deeplink for the Twitter apps. Hence it opens the Twitter app instead.

Running a .kts script instead

ki also allows you to load an already created .kts script file into the shell. So So can save some time and effort by consolidating all the above-written code into a .kts file instead.

This script exposes a Javalin object which can be used to start a localhost server.

Use :l command to load the script and then use :ls to check for the variables and methods exposed by the script.

Well we already have a way to test deeplinks using adb. Apart from notifications, web pages are another popular source of launching deeplinks. So, I just wanted you to introduce some simple utilities of the ki Kotlin-shell and hope this article could do some justice to that 😄

Happy coding 💻 and stay safe during these trying times 😷

Testing deeplinks using ki was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is #8 in Goodpatch’s Advent Calendar 2020🎄.

2020 has been tough for everyone. We are eagerly waiting for it to conclude and the good thing is we’re almost there! Since it’s getting pretty chilly around here, I thought it would be nice sharing snippets of few of my Jetpack Compose implementations as I sip over a Cup of Hot Chocolate playing Monster Hunter XX on my Switch.

Just a heads up, I will be updating this article timely as I share few more snippets in the future as Compose keeps growing.
Also, the snippets I am sharing aren’t optimised or perfect (they aren’t earth shattering for sure). All feedbacks and suggestions are most welcome 🙂

Parallax Scrolling 🏙

Inspired by the awesome dribbble shot from Charles Patterson, this snippet discusses about how to intercept scrolling offsets of Views and communicating it over to other views to create a parallax effect.

[Check it out here]

Neomorphic Button 🔘

I have my own personal reservations of whether Neomorphism is a practical UI design pattern, but implementing it using Compose was interesting and relatively simple nonetheless.
Here I touch upon Compose’s state-based animation frameworktransition() and how to intercept user events like ‘press-and-hold’.

[Check it out here]

Slot machine animation 🎰

Slot machine animations will always be there where the UI implements an Odometer or a similar concept. Implementing it in Compose isn’t that difficult at all.

[Check it out here]

Goodpatch’s Advent Calendar 2020 has a series of wonderful articles lined up for you. I understand that most of the articles are in Japanese. However, if you are interested in going through the contents, then you can use DeepL translator. It gives pretty accurate translations for technical articles in Japanese ♨️

The basic idea behind implementing a slot-machine animation, is running a slide-up/down animation for consecutive digits (3 to 4, 7 to 8 etc.) and upon completion, replace those with the next set of consecutive digits and continue with the animation. Repeat this until you reach the target digit.

If target is 7 starting from 4:
animate(4, 5) -> animate(5, 6) -> animate(6, 7)

Setting the current iteration’sfrom value, to the previous iteration’s to value, will give the impression of continuity across multiple animations.

Let’s take a look at an individual animation loop.

[1] The current from value would be the floor of currentSlotValue.

[2] Animating from to to is done using transition() as discussed in the Neomorph Button example. To calculate the incremental increase (delta) we subtract the floor value of currentSlotValue from its actual value.

[3] Next we define the underlying @Composable Text() y-offset value based on this incremental delta.

[4] This is the@Composable Text() for each of the digit infromvalue. It has an initial y-offset of 0.dp.

[5] This is the@Composable Text() for the digit of the correspondingto value (which is from + 1).
Also to keep in mind that, afrom value ending with 9 will have itsto value ending with a 0.
Depending on the preferred direction of scroll, its initial y-offset of is set beyond the height of the current @Composable (in this case +50.dp).

Let’s combine these individual animation loops into a single from to to animation as we’d discussed earlier. This part would be rather simple to understand since we’ve already discussed about transition() in the Neomorphic button example.

[1] We’ve two states, from being state(0) and to being state(1). As we’ve decided to ‘animate’ between two digits, we need to use Floatfor granularity purposes.
Since fromcan be less than to or vice versa, the current implementation would mean, that the animation direction could reverse based on the values passed.

[2] We use a tween() AnimationSpec with a duration of 300ms per animation loop set dynamically over the entire duration of from to to.

But currently the animation reverses?

As mentioned above and also in the example screenshot at the beginning of this article, we see the direction of animation reversing when from > to. How do we avoid this reversing and preserve a set direction of the animation?

All we have to do is, simply consider this case as an overflow over 9 and add 10 to the to value. For, example, if from = 5, to = 4, it would effectively mean from = 5, to = 14.

And inside @Composable SlotText(), set the current to the last digit from the overflowed value.

Hopefully that made sense 😅

And that concludes my short snippet on implementing a Slot machine scroll animation using Jetpack Compose.

My implementation may not be the most optimised or perfect, but hopefully it could help you with few references to Compose implementations.

I’m documenting all my snippets at a single place. Check out Jetpack Compose over a Cup of Hot Chocolate ☕️

Giving a parallax effect to scrolling views involves a simple concept.

With one view scrolling at the User’s intended speed, the rest of the views should scroll at relatively different rates, in the same direction.

In this case, we’ve a horizontal scroll view with Cards in them. As we scroll horizontally, we intercept the scroll offset of the scroll view and programatically set the displacement offset of the Image inside the Cards.

Our Card view @Composable will need the Scroll view’s x-offset on scrolling.

[1] @Composable Image() alignment’s x-bias is responsible for its positioning within the @Composable ItemCard() . One can adjust this value as per requirement to increase or reduce the displacement speed relative to the scroll view’s scroll speed.

rememberScrollState()

Now, we’ll need to trigger @Composable ItemCard() recomposition in sync with the scroll view’s scroll.

[1] Compose provides a convenient rememberScrollState() to locally ‘remember’ any scroll’s scroll-offset. Here’s a snippet from its documentation,

Create and [remember] the [ScrollState] based on the currently appropriate scroll configuration to allow changing scroll position or observing scroll behavior.

Consider this just as a remember { mutableStateOf(..) } State object. Any child @Composable dependent on it will have its recomposition triggered whenever ScrollState changes value. In this way, we are able to communicate the parent’s scroll-offset to the children.

[2] We are using @Composable ScrollableRow() as the scroll container for the current example. However, any custom @Composable whose Modifier.horizontalScroll(state=..) or Modifier.verticalScroll(state=..) implemented will work just fine.

There you have it. A short snippet on how to listen to scroll offsets and achieve parallax scrolling using Jetpack Compose.

My implementation may not be the most optimised or perfect, but hopefully it could help you with few references to Compose implementations.

I’m documenting all my snippets at a single place. Check out Jetpack Compose over a Cup of Hot Chocolate ☕️

[Compose Snippet] Parallax Scroll 🏙 was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

[Compose Snippet]Neomorphic Button 🔘

Implementing Neomorphic views (hopefully I haven’t slaughtered the terminology here 😅) is explained to a greater clarity in this awesome article by gihub/fornewid.

As a TLDR; to the article, the impression of smooth elevation and subtle depression upon ‘pressing’ is achieved by animating two separate blur-edged shapes of two colors, a lighter shade and a darker shade of the general surface color.

Below is a demonstration of the same implementation above but, without the center gray circle at the top.

Basically, we diagonally displace the two blurred circles relative to the center one.

The diagonal displacement is achieved by animation frameworks provided in Compose. Another thing to notice here is that, the displacement animations are triggered only when we ‘touch’ the view or remove our ‘touch’. This calls for a little different approach than simply triggering the animation in onClick() callbacks.

Modifier.pressIndicatorGestureFilter()

With Compose we have a variety of GestureFilters at our disposal. In this particular case we’re going to usePressIndicatorGestureFilter , whose documentation reads,

This gesture detector has callbacks for when a press gesture starts and ends for the purposes of displaying visual feedback for those two states.

fun Modifier.pressIndicatorGestureFilter(..)

Going through the above snippet,

[1] buttonState serves the purpose of triggering a recomposition of @Composable NeomorphButton() when its value is changed.

[2] Given a change in buttonState value, we need to trigger an animation from the previous state to the current value of buttonState, hence the toggle logic.

[3] For proper understanding of implementingtransition() in Compose, I would highly recommend this Raywenderlich tutorial. As a summary, transition() is Compose’s state-animation framework. In this case, transition from PRESSED to IDLE or vice versa, will alter buttonStateProgress value ‘using’ the predefined tween() animator.

[4] As we toggle the buttonState on interacting with @Composable NeomorphButton(), we have to toggle the ‘from’ & ‘to’ states of transition() This will ensure that the animation reverses on toggling buttonState.

[5] Implementing Modifier.pressIndicatorGestureFilter(), we listen to the onStart() and onStop() callbacks and alter buttonState value accordingly.

Pass the TransitionState

The TransitionState obtained from defining the transition() in @Composable NeomorphButton() is then passed on as a parameter to @Composable CircleNeomorph(). As per documentation, any child @Composable depending on a TransitionState will have their recomposition triggered whenever, theTransitionState value changes.

[transition] takes a transition definition, a target state and child composables.
These child composables will be receiving a [TransitionState] object as an argument, which captures all the current values of the animation. Child composables should read the animation values from the [TransitionState] object, and apply the value wherever necessary.

@Composable
fun <T> transition(..): TransitionState

[1] From the TransitionState passed on, we obtain the buttonStateProgress (animated in its parent@Composable NeomorphButton()) which is used to calculate the x & y alignment biases of the blurred circles. As the value of buttonStateProgress animates from PRESSED to IDLE or vice versa, so do the alignment biases.

[2] This is the upper blurred circle with the lighter shade. I’m achieving blur here by using RadialGradient brush for Modifier.background().

[3] Since the upper circle will be displaced towards top-left, both of its alignment bias values should be negative & equal.

[4] This is the lower blurred circle with the darker shade.

[5] Since the lower circle will be displaced towards bottom-right, both of its alignment bias values should be positive & equal.

[6] This is the central circle whose color matches the overall surface color.

There you have it, a simple implementation of Neomorphic animation in Jetpack Compose. 😀

My implementation may not be the most optimised or perfect, but hopefully it could help you with few references to Compose implementations.

I’m documenting all my snippets at a single place. Check out Jetpack Compose over a Cup of Hot Chocolate ☕️

[Compose Snippet] Neomorphic Button 🔘 was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

While I was going through on how to make HTTP calls in Swift with Alamofire and subsequent URLSession tutorials, the HTTP calls looked something like,

While Alamofire does a pretty impressive job in cutting down a lot of the boilerplate, I soon realised that for projects with a lot many HTTP calls, maintenance of the API functions could be a lot easier if the generation of the Request URL and processing of response in completionHandler are separated.

Being an Android developer, I’m very used to how Retrofit (Android’s goto Networking Library) lets us separate the HTTP call URL generation and underneath calling of functions from the responseListener. Something like,

interface are nothing but protocol and each function represents the entirety of an HTTP call. All you need to do is call the function which will return an Observable of the Response. Neat and simple right.
What Retrofit in Kotlin/Java does under the hood is that, for each of the function annotated with @GET or @POST, the compiler synthesises all the required boilerplate to convert them into full-fledged HTTP calls with callbacks.

I was wondering if something like this could be done in Swift too and then I struck gold when I came across@propertyWrapper in Swift. The official documentation it reads,

A property wrapper adds a layer of separation between code that manages how a property is stored and the code that defines a property.

For example, if we wanted to have String fields to always return value in the “CamelCased” format, we can write a @propertyWrapper as follows,

The parallel I could draw in Kotlin would be either the custom getters and setters or even better, Property Delegates. In Kotlin, the above example would look something like this,

Using @propertyWrapper we would try achieving a Retrofit-like syntax for our Alamofire boilerplates. Something like,

Let’s begin by typealiasing our completionHandler closure to Observer<T>.

Next, let us implement a GET struct as a @propertyWrapper.

So what is going on here,
1. we have a local variable url which is being set at init.

2. the calculated value wrappedValue is of type Observer<T> which is going to behave as our completionHandler from wherever we make the HTTP call.

3. inside the get we return a closure where the entire Alamofire boilerplate resides. So, every time I fetch the variable which has been tagged with this @GET propertyWrapper, all I’ve deal it is the completionHandler in the closure without worrying of the underneath HTTP call boilerplate.

So now, we can ‘declare’ our HTTP calls and use them with minimal code as follows,

So…

Though this example showed the implementation of a wrapper @GET(:url)is a small portion of all the possible types of HTTP calls. The main reason for me to write this up was to demonstrate how @propertyWrapper can be used to do a lot of heavy lifting to make our code more readable and manageable in the long run.

I’m still very new to iOS and working my way through it. So, if you have any suggestions or corrections feel free to reach me on Twitter or let me know in the comments below.

Also, I love reading about Monster Hunter and the vast foray of ecological varieties it provides. I’ve started maintaining a personal collection of ecology and lores from various sources I come across. Interested people do give it look 🐲

In most cases, we use Toolbar as follows

<androidx.appcompat.widget.Toolbar
    android:id="@+id/toolbar"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    app:navigationIcon="@drawable/ic_arrow"
    app:title="@string/screen_title"
    app:titleTextAppearance="@style/ToolbarTitle" />

where we set the title and title’s style in the layout xml itself.

Let’s consider the following use case:

For this, I’d set the initial title of Toolbar as empty (let’s assume that @style/ToolbarTitle sets bold font to the text)

<androidx.appcompat.widget.Toolbar
    android:id="@+id/toolbar"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    app:navigationIcon="@drawable/ic_arrow"
    app:title=""
    app:titleTextAppearance="@style/ToolbarTitle" />

and, add the logic of setting Toolbar title in OnScrollChangeListener as follows,

scrollView.setOnScrollChangeListener { .. ->
    toolbar.title = if(scrollY > 50) task.name else ""
}

Makes complete sense right? On running the code, it looked like this.

Notice something? The @style/ToolbarTitle doesn’t seem to have any effect. Any reason why? Well, there is an issue with this implementation and a rather interesting piece of code behind this kind of limitation. Let’s have a look at it then.

Inside Toolbar.setTitle( )

Toolbar.setTitle() is called initially in the constructor of Toolbar itself. Where, the Charsequence title is taken from app:title and passed on as parameter.

Let us have a look at the implementation of Toolbar.setTitle() in AOSP (as per androidx.appcompat:appcompat:1.1.0)

From Line#10onwards, we see that if title is empty, mTitleTextView.setTextAppearance() isn’t called. So, style set inapp:titleTextAppearance won’t have any effect on the Toolbar’s title.

Fine. Then, how about we programatically set the style using Toolbar.setTitleTextAppearance(R.style.ToolbarTitle) ? That should work.

Nope, that doesn’t work too. Why?

Inside Toolbar.setTitleTextAppearance( )

Let’s have a look at the AOSP’s implementation of Toolbar.setTitleTextAppearance()

I would like to draw your attention momentarily towards Toolbar.setTitle() Line#13 for once. We observe that when titleis empty, mTitleTextView isn’t initialized.

In that case, even inToolbar.setTitleTextAppearance() we see that mTitleView.setTextAppearance() sits behind a null check. Hence, even programmatically setting Toolbar.setTitleTextAppearance() won’t have any effect on the appearance of Toolbar’s title.

Solution?

So as per the intentions of the author of Toolbar.setTitle(), in order for app:titleTextAppearance to have any effect on the Toolbar’s title appearance, one needs to at least set a default non-empty title in the layout file for Toolbar . Hence after adding a non-empty text in app:title things worked!

<androidx.appcompat.widget.Toolbar
    android:id="@+id/toolbar"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    app:navigationIcon="@drawable/ic_arrow"
    app:title=" "
    app:titleTextAppearance="@style/ToolbarTitle" />

Even though Android’s Toolbar documentation doesn’t specify anything about the design decision behind this restriction, I thought it would be fun sharing this nice little tidbit about one of the most frequently used View classes in Android Developement.

I also love reading about Monster Hunter and the vast foray of ecological varieties it provides. I’ve started maintaining a personal collection of ecology and lores from various sources I come across. Interested people do give it look 🐲

Toolbar.setTitle() is interesting 🔬 was originally published in Dailyrounds Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.