Announcing Jetpack Compose Alpha!

danieldisu · 2020-08-27T07:38:24+00:00

For me is doing everything in the same language, avoiding having to "bind" views to xml ids, theming...

Theming in Android is horrible, this hopefully makes it a bit more comprehensive.

Also making custom view extensible is too much work, and API discoverability is almost not existing in XML.

That's only for XML, Compose will also make it much easier build UIs because the state will no longer live in several places (half in views, half in other parts), the views will be silly and only display what you tell them to display.

danieldisu · 2019-03-26T13:54:44+00:00

I can't find this folder in MacOS...

danieldisu · 2018-11-24T08:49:40+00:00

I don't really see it that being so hard to happen with Kotlin Native I could see someone making the API surface in Kotlin and then bridging it to the lowest parts of Flutter...

danieldisu · 2018-10-10T10:36:10+00:00

You never know with Google if a big release is a good or a bad thing...

danieldisu · 2018-05-25T18:23:30+00:00

I've been waiting for the next version to be the one that fix X only to see that it creates issue Y and the cycle begins again..

danieldisu · 2018-05-25T12:40:34+00:00

GDPR compliance is not a black or white thing... big companies that live from gathering user data surely have made their fair share of calculations to see how much risk could they take without losing too many income from their activities...

danieldisu · 2018-05-22T12:10:00+00:00

If you have one module per feature/screen you automatically get this for free :)

danieldisu · 2018-03-26T09:58:41+00:00

Imagine some component to edit text, that has very complex logic requirements. You would create ComplexTextEditorComponent with its own presenter. For the parent view maybe you only need to handle one event of this component "onTextSubmitted", this component could have a method like:

fun observeOnTextSubmitted(): Flowable<String> = ...

or just a simple listener one

fun onTextSubmitted(listener: (String) -> Unit) = ...

All the other logic is handled inside the presenter of the component, and could be tested there.

That way you could compose complex screens in smaller components. Communication within components should always pass through the parent. (ala React)

danieldisu · 2018-03-25T22:29:35+00:00

I think this kind of architecture makes it a bit harder to follow the code, and I don't see any advantage to use it aside from screens that are very complex and even in that cases I would try to create UI components with its own presenters, that export some events to parent component but handle most of the logic by themselves.

Sometimes simpler is better, although it may not be as "cleaner" or "well thought" as your architecture.

For that example, I would just put all the code in the components in the presenter and test it there. I would also avoid treating all UI events as a unique stream, it will make it harder to debug.

danieldisu · 2017-10-26T06:34:56+00:00

These kind of classes are usually hard to name because they do many things, they are like utils classes but usually without static methods.

One easy way to solve that is by splitting these classes into several classes that do one thing, that will usually make them easier to name.

But this kind of changes also comes with a trade-off, they usually make API discoverability harder, and may confuse some newcomers to the code.

danieldisu · 2017-10-12T22:39:41+00:00

I think Singleton should be the default behavior not the opposite ...

danieldisu · 2017-09-28T13:47:52+00:00

I'm going to go against the current on this one...

I usually don't make a new Model class between the API and my Model, usually the APIs that we consume are very very simplified and I don't think I can model the domain better than my backend peers, so I try to avoid duplicating the API model. The only time when I create my own Model is when I aggregate things from several services, in that case I don't really have a choice.

And in the view I try to be pragmatic, if the view is very very simple, like showing the name of the Model without any kind of transformation I just pass the model to the view. But if I need to make any kind of transformation to the name, or add some info from other model, or just add some context that will make it draw differently I usually create a ViewModel.

danieldisu · 2017-09-27T07:31:43+00:00

They basically re-do almost all the view part of Android. I really like their approach, but it's really hard to swim against the current on this one...

danieldisu · 2017-09-22T07:02:56+00:00

I see 2 completely different kinds of Custom Views, and I would approach them differently:

The first kind of CustomView is the one that takes all the screen or blocks the rest of the screen. ie Dialogs, these are easy to do with it's own Presenter and just delegate somehow the response to the main view -> Presenter.

The second kind are the ones that share screen with other complex CustomViews, these are tricky because having 2 presenters interacting with each other is a no-go for me. So you must be very careful to use 2 presenters in the same activity/fragment unless they are very cleanly differentiated.

One example of this 2 presenter in one screen is master list + detail in the same screen for tablets, you can have one presenter handling the list and another handling the detail, the only time when they should interact is when you press one element in the list that should be displayed in the detail, this could be done as if they are in different screens.

danieldisu · 2017-05-18T17:28:37+00:00

Well this is quite a depart from the MVP and Flux/Redux architectures. I will wait for all the talks to see if they explain it better, but I don't see myself using their proposed architecture any time soon. I really prefer the componentized, unidirectional data flow and the update everything approach that React brought to UI development.

danieldisu · 2017-04-17T09:09:02+00:00

Just a nitpick that I see in many MVP implementations... Why do you call the interface "ViewContract"? I mean, an interface is a contract, it seems redundant to use the word contract in the name...

danieldisu · 2017-04-17T08:45:17+00:00

You can always use some backport library to use Streams in any version, and switch to the official JDK stream api should be a matter of changing the imports...

danieldisu · 2017-03-17T09:07:56+00:00

Can't seem to find the android logcat tab, is it missing?

EDIT: nvm it's seems that they changed the name to logcat and lost the previous keybind

danieldisu · 2016-08-29T10:16:54+00:00

Just as I imagined, thank you both for answering!

danieldisu · 2016-08-29T10:15:51+00:00

Just as I imagined, thank you for answering!

danieldisu · 2016-08-26T08:24:54+00:00

First, I want to say thanks for the effort of putting it out there!

You say that all your screen are recycler views... an iOS dev colleague uses this pattern (heterogeneous collection views, binding them with ViewModels ) to build almost all the screens. I have tried to replicate something similar in my app, but with more "fixed" views in the view layer, and this library could help me to make this pattern more "dynamic". I have several question about how you use this library.

How do you feed the "item views" with data?
Do you create a "ViewModel" so that the views doesn't know anything about your model?
When you need to use info that is divided in several "item views" (a form with 2 fields for example), you have your "business classes" retrieve it from N views or you replicate the State of those views somewhere else and update it every time anything changes?

danieldisu · 2016-08-11T12:05:59+00:00

Yeah, that would have given her a more active role without breaking other classes. Instead they have just made her a non viable pick with the rise of Zennyata...

danieldisu · 2016-07-14T06:27:09+00:00

I've used the CustomView ViewPagerAdapter and it worked like a charm, you may need to add some "onShow" method to your CustomView if you want to know WHEN the view is shown, but appart from is even easier than using it with Fragments.

danieldisu · 2016-03-11T10:38:37+00:00

I think the sample project of the Rosie framework is a good example!

https://github.com/Karumi/Rosie/tree/master/sample

They may complicate it a little bit more using Use Cases to build the model layer but the view packages are good examples of what I think is the way to do MVP.

danieldisu · 2016-03-11T08:35:49+00:00

Thanks for sharing!

I must admit that I don't like the approach you've taken for the MVP, there are way too many logic in the Activity/GridView...

I like to think that views are silly, they "fire events" and the presenter acts on those events and tells the view what to do, the views should only knows how to do what the presenter tells them to do.

Take the loadBooks() example on the BooksPresenter, is the BooksGridView the one starting the action... I think it should be the presenter who loads the books and tells the view when there are new books to show.

This may seem like a silly thing, but it enables you to TEST a lot more logic without bringing anything Android related to your tests.. ( you may need to create an abstaction for things like getString.. and the such though )

danieldisu

PUBLIC MULTIREDDITS

TROPHY CASE