Hello <#CHJP9K00L|splitties> any idea about `start...

# splitties

[Sergio Crespo Toubes]

Hello #splitties any idea about startActivityForResult ? I think is not implemented yet

[louiscad]

Hello @Sergio Crespo Toubes What are you looking for exactly?

[Sergio Crespo Toubes]

i am migrating from anko and i had something like startActivityForResult<Activity>(requestCode,extra)

[louiscad]

I see, can you open an issue with the example on GitHub? I'll consider adding it after the KotlinConf week.

[ispbox]

I would like to add my 5 cents. From my point of view, it is really not necessary to wrap ugly Activity lifecycle events and messages in Splitties DSL / UI part of code. It is the responsibility of some other framework (for example, I would suggest Conductor for all that stuff).

[louiscad]

But this thread is not about lifecycle events!? @ispbox

[ispbox]

@louiscad You are right - startActivityForResult is more related to Intents, rather than Activity lifecycle. But that's why I added "events and messages" 🙂 I think that all activity-related stuff (events, intents) should be separated from UI (Splitties DSL). You can have any helpers in other Splits, that's ok. My concern was about weak responsibility segregation in Anko, that was really tied to Activities and Fragments. I appreciate that Splitties DSL goes another way :)

[louiscad]

Splitties try to be like: do your own class, use interfaces if it fits, and use it from wherever you want, even all at once if needed.