If you’re a small startup, just like we are doing at ours [1], you want to share as much code as possible between your web and mobile apps, and also backend, so sadly due to Dart, I don’t see us anywhere in the future using Flutter. [1] https://standups.io
Can you really straight up share components between react and react-native? Most of the RN components kinda map to mobile stuff--they're called things like View and TextInput. Most of what I see in React are divs with different stylings. Moreover, can you share any code at all between node.js and react/RN?
Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
51–60 of 186 posts
Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
#52This is super interesting, but the problem I have is that this guy's eye for design leaves a lot to be desired. When was the last time someone built a clunky table directly into the UI and added fully styled table rows dynamically? Why not modernize the design, and use a styled list view with a data adapter and try this again on each platform? It didn't surprise me at all that he struggled with the table in basically…
It's still a great write-up, but that part hurt me.
Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
#53[1] https://github.com/rrousselGit/provider
Edit: I probably would have even gone back and refactored the app to use Provider before publishing the article. =) That would have been a nice additional bit of information for the reader.
Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
#54Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
#55There are some issues here and there (JSX is not a language!) but this is definitely a very good comparison. It is indeed a little bit too shallow (give animations! Full app navigation stack management!) but gives practical insights. Props to the author.
If JSX isn't a language, then what is HTML?
Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
#56If you’re a small startup, just like we are doing at ours [1], you want to share as much code as possible between your web and mobile apps, and also backend, so sadly due to Dart, I don’t see us anywhere in the future using Flutter. [1] https://standups.io
I've worked on 3 start-ups and 3 major, large companies. So far every single one of them tried to do the whole share code everywhere thing and every single time it ultimately cost us far, far more time to get everything working and then subsequently testing re-used code.
I've worked two projects where we used different components and code, for 99% of everything, across server, mobile and native and we were able to work _significantly_ faster.
So I'm curious, would you work towards sharing code again if you had to start from scratch? Has it ended up being worth it? Because my personal experience so far has seen it usually be more of a liability than anything else so I'd love to know how it worked out for others.
Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
#57Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
#58This is super interesting, but the problem I have is that this guy's eye for design leaves a lot to be desired. When was the last time someone built a clunky table directly into the UI and added fully styled table rows dynamically? Why not modernize the design, and use a styled list view with a data adapter and try this again on each platform? It didn't surprise me at all that he struggled with the table in basically…
As an Android developer I looked at the code he wrote and felt bad for him. Of course it was painful trying to set all your styling up programmatically for the table! Use a viewholder pattern and a recyclerview/adapter then throw your data into the adapter. Make a simple xml file for your rows and inflate those into the viewholder then you're good to go! None of these clumsy declarative attempts to do what xml does w…
I later understood that, it was because they wanted to use the J2ME-to-android bridge I develop for their other J2ME apps and XML layout dependencies would have been a hindrance. Since, this was very early in the android development ecosystem and many devs were Java developers before; usage of XML layouts for UI wasn't strictly mandated as it is now. I did complete the bridge in 3 months and the application performed as it should.
But, I'm glad I never had to do everything related to UI programatically on Android ever after.
Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
#59ouch The Android code indeed looks like a copy paste of bad stack overflow answers. I can't really hold it against the author .. learning several platforms at the same time is a bit much.
Could you elaborate, or do you know of a better example of an idiomatic kotlin Android app?
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 . 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 )
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.