profile
viewpoint
Arkadii Ivanov arkivanov @google London, UK https://twitter.com/arkann1985 Android developer. Passionate about Kotlin Multiplatform, MVI and reactive programming.

arkivanov/Decompose 183

Kotlin Multiplatform lifecycle-aware business logic components (aka BLoCs) with routing functionality and pluggable UI (Jetpack Compose, SwiftUI, JS React, etc.)

arkivanov/MVIKotlin 145

Extendable MVI framework for Kotlin Multiplatform with powerful debugging tools (logging and time travel)

arkivanov/Essenty 114

The most essential libraries for Kotlin Multiplatform development

arkivanov/android-dev-challenge-compose-2 50

Week #2 - Countdown timer

arkivanov/CompoSnake 48

A simple Snake game implemented using Compose for Desktop

arkivanov/Konf 15

Kotlin Multiplatform conference app template

arkivanov/ComposeNavigatorExample 8

Example of Compose Navigator using the Decompose library.

arkivanov/gradle-setup-plugin 8

Gradle setup plugin for my projects

release arkivanov/Decompose

0.5.0

released time in 8 hours

release arkivanov/Decompose

0.5.0

released time in 8 hours

release arkivanov/Decompose

0.5.0

released time in 9 hours

created tagarkivanov/Decompose

tag0.5.0

Kotlin Multiplatform lifecycle-aware business logic components (aka BLoCs) with routing functionality and pluggable UI (Jetpack Compose, SwiftUI, JS React, etc.)

created time in 9 hours

issue commentarkivanov/Decompose

Why do configurations in the stack have to be unqiue?

Hello and thanks for the question. This is because how the API is designed, the main method for navigation is as follows: navigate(transformer: (List<C>) -> List<C>). So instead of direct commands like push or pop, there is one single method navigate.

One the one hand, this gives a lot of flexibility, as you can manipulate the stack how you want. For example you may want to navigate from A <- B <- C <- D to C <- E <- A (the head of the stack is at the end).

But on the other hand, the Router has a requirement to destroy removed components, to create new components, and to do nothing with the components that are still in the stack. In order to achieve it, the Router calculates diffs between old and new stacks and performs required operations.

Calculating diffs requires all components to be unique, because the Router compares configurations. For example consider the following stack - A <- A<- A. For this stack the Router created three instances of a same component class - ComponentA <- ComponentA <- ComponentA. If at this point you call router.navigate { listOf(it[0], it[2]) } to remove the middle component, the Router will have to compare the following two lists - [A, A, A] and [A, A]. It is impossible to determine which components should be actually destroyed and removed from the stack.

Additionally, configurations are used as map keys in some other places, or compared by hash code.

If you have any issues due to this requirement, I will be happy to help find a solution.

gnawf

comment created time in 9 hours

delete branch arkivanov/Decompose

delete branch : enable-watchos-target-for-counter-sample

delete time in 19 hours

push eventarkivanov/Decompose

Arkadii Ivanov

commit sha 76d45629cfb62654ccf2a83a3c9fd094d7d2b863

Enabled watchos target for Counter sample

view details

Arkadii Ivanov

commit sha 00cc27de16e767d54bd5213091fdc5bf982fb0ce

Merge pull request #18 from arkivanov/enable-watchos-target-for-counter-sample Enabled watchos target for Counter sample

view details

push time in 19 hours

issue closedarkivanov/Decompose

Enable watchos target for the Counter sample after Kotlin 1.5.31 update

The Counter sample has watchos targets temporary disabled, due to KT-48613.

closed time in 19 hours

arkivanov

create barncharkivanov/Decompose

branch : enable-watchos-target-for-counter-sample

created branch time in 20 hours

push eventarkivanov/Decompose

Arkadii Ivanov

commit sha bd8b1c1aebc3393e999e791d9a88545e58964729

Conditionally exclude either check-publication module or all other modules

view details

push time in 20 hours

delete branch arkivanov/Decompose

delete branch : update-kotlin-to-1.6.10

delete time in 20 hours

push eventarkivanov/Decompose

Arkadii Ivanov

commit sha fe02b7a1ab029a6de89a9ae0b0c2b5df7c61cceb

Updated Kotlin to 1.6.10, Jetpack Compose to 1.0.5, Jetpack Compose compiler to 1.1.0-rc02, and JetBrains Compose to 1.0.1

view details

Arkadii Ivanov

commit sha 523f850aa96f15a36b5760c22689f682fc130622

Merge pull request #17 from arkivanov/update-kotlin-to-1.6.10 Updated Kotlin to 1.6.10 and other dependencies

view details

push time in 20 hours

PR merged arkivanov/Decompose

Updated Kotlin to 1.6.10 and other dependencies

Updated Kotlin to 1.6.10, Jetpack Compose to 1.0.5, Jetpack Compose compiler to 1.1.0-rc02, and JetBrains Compose to 1.0.1

Closes #5

+3594 -24

0 comment

7 changed files

arkivanov

pr closed time in 20 hours

issue closedarkivanov/Decompose

Update Kotlin to 1.6.x

Things to consider:

  • Version 1.6.0 has some bugs (e.g. KT-49798), perhaps better to skip this version.
  • There is no stable version of Jetpack and JetBrains Compose version compatible with Kotlin 1.6.10 as of now.
  • Mind #3

closed time in 20 hours

arkivanov

PR opened arkivanov/Decompose

Updated Kotlin to 1.6.10 and other dependencies

Updated Kotlin to 1.6.10, Jetpack Compose to 1.0.5, Jetpack Compose compiler to 1.1.0-rc02, and JetBrains Compose to 1.0.1

Closes #5

+3594 -24

0 comment

7 changed files

pr created time in 21 hours

create barncharkivanov/Decompose

branch : update-kotlin-to-1.6.10

created branch time in 21 hours

push eventarkivanov/Decompose

Arkadii Ivanov

commit sha d7662b8e0dfd36e57b71880df26fe2416ac952cd

Bump version to 0.5.0

view details

push time in a day

issue closedarkivanov/Decompose

Web Browser routing support

Copying from #271

Raising an issue as per the conversation over at MVIKotlin Slack channel

As discussed, what do others think about having the support for routing in web browsers (eg having paths in the URL, yourwebsite/users/profile and etc...).

There are two main options for the URL paths:

  1. Hashed paths eg. example.com/#users/profile

Consider one page website, or website built fully on AJAX, without any page reloads.

#hash helps such applications to push state of the application to the client, this helps the application itself to be aware of the state and the client (and browser) to be aware of the state. This will also help the user to bookmark the application in its' current state and use back and forward buttons (browser history).

Which basically is Client Side way of telling where we are, it's easy to implement but a bit uncommon and not what the people are used to. As it doesn't require page refreshes

  1. Normal paths eg. example.com/users/profile

More common, the paths we are accustomed to seeing. A bit more difficult to implement.

Issues that are currently present while developing for web that can be solved with this:

  1. Refreshing the page returns you to the root and not just the "page" you were on
  2. Nicer looking URL's, since currently all pages live in the /
  3. Support for History (going backward and forwards in the browser). Most notably on Desktop, you are sometimes stuck between Parent and a Child on Desktop as there is no back option unless you manually add a button.

Implementation

As for the concrete implementation, I am not sure. But here are some of my notes

  1. Changing the path should change the configuration, alongside pushing a new configuration should update the path. So the entity responsible for the path should be aware of the possible configurations
  2. How would it integrate with the current way navigation is handled (talking about the implementation), of pushing configuration onto a router that is being observed in your UI solution (Compose, React...). As the navigation is currently platform-independent.
  3. Can it be made in a way that doesn't affect the existing code for other platforms? Maybe even keep the existing code for the web alongside some additional setup at the beginning to map all of the routes.
  4. Parameters, dynamic URLs. Currently, with configurations, you can pass pretty much anything to the children, but for the URL's this wouldn't be the case. So if we push a complex configuration via the existing code that may not be possible to map to a path with parameters. This would mean that a possible limitation could be to not allow manually altering the path from point 1. Considering that this works in other solutions like NextJs and React with Navigation libraries, this shouldn't be an issue.

Please correct me if I am wrong on anything, and do add some more input.

This is primarily based on similar solutions existing for Compose on Web

closed time in a day

Nikola-Milovic

issue commentarkivanov/Decompose

Web Browser routing support

Closed via #15 and #16

Nikola-Milovic

comment created time in a day

push eventarkivanov/Decompose

Arkadii Ivanov

commit sha b45e994fe6d6070d1291d7f43e8d6e82397a685d

Added Web Browser History docs page to the menu

view details

push time in a day

delete branch arkivanov/Decompose

delete branch : docs-for-WebHistoryController

delete time in a day

push eventarkivanov/Decompose

Arkadii Ivanov

commit sha ad51b06b4b0c6ac73743bee4e411fd313155ce71

Added docs for WebHistoryController

view details

Arkadii Ivanov

commit sha 6f1fcf516ef250c1fd0cb32691e8291bdb81d453

Merge pull request #16 from arkivanov/docs-for-WebHistoryController Docs for WebHistoryController

view details

push time in a day

PR merged arkivanov/Decompose

Docs for WebHistoryController

As part of #1

+67 -0

0 comment

1 changed file

arkivanov

pr closed time in a day

push eventarkivanov/Decompose

Arkadii Ivanov

commit sha ad51b06b4b0c6ac73743bee4e411fd313155ce71

Added docs for WebHistoryController

view details

push time in a day

PR opened arkivanov/Decompose

Docs for WebHistoryController

As part of #1

+67 -0

0 comment

1 changed file

pr created time in a day

create barncharkivanov/Decompose

branch : docs-for-WebHistoryController

created branch time in a day

delete branch arkivanov/Decompose

delete branch : js-history

delete time in 2 days

push eventarkivanov/Decompose

Arkadii Ivanov

commit sha 33c8804b23d812908f1f5f4280bccb42a3b1c1f8

Added WebHistoryController

view details

Arkadii Ivanov

commit sha 677e297b7e3684683b4298dfae08ae0e98361e71

Merge pull request #15 from arkivanov/js-history Added WebHistoryController

view details

push time in 2 days

more