3 ms·
sure. Again, I want to stress out that this is not an attack against the author. I started learning Android roughly 10 years ago now. I actually anecdotally r
by on_and_off 7y ago
sure.
Again, I want to stress out that this is not an attack against the author.
I started learning Android roughly 10 years ago now. I actually anecdotally recently started teaching it to my SO and it finding the right approach to do so was a challenge. The sources I use to keep up with the latest tech are not the ones you want to push to a beginner.
> know of a better example of an idiomatic kotlin Android app?
off the top of my head, I am not sure what open source app I would direct somebody to.
There is always https://github.com/google/iosched https://github.com/google/iosched . The big downside is that for very long they shied away from using some common libs like rx or dagger in order to show off what you can do with just the base google libs. I know that they have revised their approach but to be honest I haven't checked out the code source of this app in 2 years (they always do a big refresh around io)
Android is also in a spot that must feel like a catch 22 for its maintainers : the platform has for very long had an approach where very little was irrevocably decided for you by Google. Which was great since it allowed to use whatever pattern works best for your usecase but also means that this freedom can be very intimidating for newcomers.
This has changed in the past 1 or 2 years from 2 different reasons :
- initiatives like jetpack provide an opinionated way of doing things on Android.
- we can't have nice things. Some APIs are progressively closed off. In some cases it is because of performances (since devs are too often not going to care a lot if they have a rogue foreground service siphoning the user battery as long as their feature works), security or privacy.
Looking at `createTableRows()`
Removing all the views before adding them again is extremely unidiomatic. As well as handling all your layouting in kotlin/java instead of xml.
A clean way to handle what op is doing would be first to define a ViewState : a model representing the UI. In itself, it is nothing fancy, just an immutable kotlin data class
looking something like this :
data class IngredientsModel(
val title : CharSequence, // "ingredients"
val ingredients : List<IngredientModel>
)
data class IngredientModel(
val name : CharSequence,
val text : CharSequence
)
next up would be to apply it to the UI
a simple method like bind (model:IngredientsModel) should be in charge of that.
Using a previously inflated xml layout for the whole screen
And a RecyclerView (abstraction similar to iOS UICollectionView ) to display the ingredients
stuff like
tv1.setPadding(32, 6, 6, 6) -> padding applied manually instead of being done through a layout definition and moreover using raw pixel values instead of dp ones.
if (index >= cocktail!!.measurements.count()) -> you don't do this kind of logic in the view layer, ever. This is why I have defined an IngredientModel, so that what to display can be defined in the business logic, not in the view layer.
Reading the article "create layouts declaratively like with Dart,wasn’t around when I created this project"; it looks like the author tried very hard to write idiomatic flutter code (and not necessarily good one) in place of Android one.