Live data from Hacker News

Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

blog.codemagic.io

51–60 of 186 posts

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#51

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?

We did that in one of our projects using react-native-web https://github.com/necolas/react-native-web which basically allows you to write your web code within the react native project so everything is shared between web and mobile including the same views which are exported for the web with proper styling as mobile. Plus it allows you to override any components for your web using .web.js just as .ios.js and .android.js extentions.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#52

This 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 well.

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
OP mentions the Provider package [1] wasn't around when they did the Flutter version. That is really too bad, because it is absolutely the best way to manage state in Flutter. It makes things so much easier and cleaner than the other methods.

[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

#54

Earlier quoted context omitted.

With native toolkits being around for so long, why do they still suck to build with?

Because they carry around 10+ versions of compatibility debt

Why can't they release breaking changes under a major release?

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#55
post #22

There 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.

Hyper Text Markup Language

If JSX isn't a language, then what is HTML?

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#56

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

> you want to share as much code as possible between your web and mobile apps, and also backend

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

#58

This 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…

In my first job as android developer (circa 2010) I was tasked with porting a J2ME application with 30,000 lines of code in total to Android. Their primary condition was 'I shouldn't use any XML for layouts and any UI element should be defined only via code'.

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

#59
post #26

ouch 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?

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 . 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.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#60
I'm really interested in learning Flutter for future app development as I could really use the time saved in development. But, one thing which really concerns me is the volatility of Google w.r.t products which doesn't get enough adoption i.e. in other words 'I'm afraid Google will kill Flutter'.
Post reply on HN