45. Ariel Ben Horesh
30:11 Share

Hi, thanks for listening. This is the It's All Widgets Flutter Podcast. My name is Holo Korn. Each episode, you get a chance to speak with another amazing member of the Flutter community. This episode, we are extremely lucky to be speaking with Ariel. Welcome. Hi, thank you for having me. Thanks for being on. So to start, do you want to share a bit about your background? Yes, sure. So I have a lot of experience in the development industry. I've been doing it for as much as I remember myself.

For the first time, I touched my first computer. I knew this is my purpose. And since then, I focused all of my efforts to become a software developer and

I've joined the army as a developer, and I've been in the army for almost seven years doing work as a developer and as a team leader. And lastly, as an R&D department leader.

And after that, I left the army and joined SELA as a consultant. I've been there three years, mostly doing .NET, WPF, UI stuff. And together with a few friends of mine, we started out CodeValue.

And together we've built an amazing company. I think at its peak it was 250 employees. And I've been there for 10 years and I've done a lot of mobile stuff that we will talk about soon. And then I left after 10 years and

and went on to do different things. And I've joined Lumen, a cool startup that is in the health industry. We are trying to track metabolism and we are doing a lot of flatter work. And this is a consumer device, a lot of opportunities, a lot of challenges, product-wise, development-wise, and

I can say that I'm feeling very lucky to be where I am. And how did you first hear about Flutter? Was it through Lumen or before? Yeah, actually it was before. As I said at CodeValue, I've done a fair share of mobile development.

I've done native. I've done also cross-platform. As a side note, I've worked on many of the Israeli Windows phone apps at that time. Way is building a speech at WINE at Walla. So I was very involved in the mobile community back then.

And Team Snit actually approached us and had a meeting with us and asked us, how can we help push Flutter in Israel? It was a very early stage. I think it was maybe alpha. They didn't have a map widget back then. And the Hebrew support was also non-existent. So it was very hard to actually do a project with. But

this is the first time that I like really put it under my attention and like following started to follow and track it after that I remember I've done like a session comparing the different cross-platform technology Xamarin React Native and Flutter and I remember it was my first time I really tried to do something with Flutter and

the conclusion and something that was also from the audience itself that Strata was like the most let's say

A promising technology of all those gang. Cool. And are there aspects you like most about Flutter in particular? So first, I must say that since I had such a vast background in developing in a lot of platforms, I can really say, and I mean it from the bottom of my heart, you can say, that I really enjoy developing in Flutter.

The reasons for that are mainly the consistency of the development model. So you can really rapidly develop values platforms using the same paradigm, the same patterns, and it's really scaling this down. The fact that you are not limited by anything, you know that you can do whatever you want. You can be pixel project, you can do anything.

And this, in the emergency, resolved any compromise on complexity. As I said, I was for years a WPF developer and I knew XAML and

every little thing you can do with it. And I can say that with XAML, you can also do anything you want, but the complexity was over the roof whenever you needed it. And with Flutter, just like magic, really is a fascinating technology.

Yeah, I agree entirely. I think one complaint sometimes here about Dart code is how it can get deeply nested. I think there again, one of Flutter's great beauties is the fact that you can always break widgets down further. You can just keep subdividing. Essentially, you build your own widget tree and make it extremely reusable. And that way, you end up with far less depth of widgets. Yeah, I agree. This is something I think beginners are prone to fall into and

And also separating and composing the widget is one of the, we can say, the skills that you own and sharp as you go. And the composition, the separations also make your code much more maintainable, but also makes the grasp much more easier to maintain. Although I can say that as well...

during my time and I keep comparing to XAML because it's very interesting to see that in XAML you also had a lot of components and nested objects there in the XML graph. So this is not something that I'm easily offended by or afraid from.

But of course, with your service, there are ways to mitigate. So speaking about how you structure the apps, is there a particular state management library you use for most of your apps? Yes. Also, I didn't say before, but I'm running the Tel Aviv Schlatter Meetup, which we try to meet every two or three months.

And one of the meetings, I also had a session about comparing the different state management libraries that we have at our disposal of Flutter developers. So if you're new into this area and you want to check it out, the various options, I recommend you try to YouTube it. Or maybe actually we can put it in the notes of this episode.

So, about my opinion...

I'm pretty much a little bit like an old guard that I love the block option. For me, it makes complete sense and the integration with how Flutter works is a perfect match for me because modeling and looking at the code of the state machine, which block really is doing a great job

in allowing you to build your logic around that notion. And the easiness of how you plug it into your widget tree and respond to changes. For me, the easiness of using it, because I, from now, look at it as the most obvious way you can...

describe the relationship between a UI and the UI logic. However, I'm also contributing and helping build that is using RiverPod. And RiverPod has made tremendous leap forward in the last year

and especially around the generated code that they use for the provider. So you just put a notation of "riverpod" on top of "method", on top of "classes", and it will just like recreate the provider. And it's actually quite magical to see.

And it's really robust and powerful. And it's actually quite simple to use as a developer. But as I said earlier, I still like the formidability and explicitness of the block pattern at the end of the day. Cool. Do you find you use the pattern itself or do you use the Flutter block package to implement it?

I usually use the ShrackerBlock library. I find it sufficient to my needs. Also, it includes the qubit. You can say base class that you can use. And maybe I can, if we want, I can also share a little bit of my perspective on how I see it, because it actually...

not defined in a way that the library instructs you, look, this is the philosophy, this is the religion, you should always do one, two, three. And it actually, like, this is our tool, use it as you want. There is no bad or wrong. But for me, what makes sense is I use the block

pattern wherever I create UI logic which is tied to a widget, tied to a UI. And I use the qubit for things like API or services that I want them to be a stream, to have a stream, to have an observable into it. And I can pretty much plug and play and use both. Also, when

I can hook them into a UI if I want. But then the qubit or the service in this case is not specifically... His responsibility is not to manage the UI itself, but maybe get some data to be accessible and have the widget...

change the state based on it, or configuration, for example, is a good example. Another thing is the texting library that complements the Flutter block. And this also, for me, when I do testing for my apps, I'm trying to find the most value for money, you can say, ROI. And so I usually do tests for my blocks.

And I usually do tests for, for example, for services or for like classes with logic. And a lot of time there are qubits or blocks. So it makes perfect sense to use that library. And if I can say another sentence about testing, I usually complement the bit with a splatter drive-like function.

a regression test and to end. So I have coverage coming from the UI and coverage from the blocks themselves in the logical tests. Nice. That makes a lot of sense. Are there any aspects of Flutter you'd like to see changed? Yes. There is always room for improvement, always room for making it even more awesome. Yeah.

I can say that I would be happy to see a bit more focus on the mobile. I feel that ever since the Flutter team started to expand to other platforms, the mobile is a little bit left behind.

So I would be happy to see more tools or more capabilities around specific platform features that you can use more easily with Flutter. As an example, we can talk about iOS widgets.

or other, for example, the tile that iOS now on the main screen, on the lock screen. So I would be happy to see more flutter interference with this platform-specific code. And besides that, something that I always wished for is

more robust runtime information, which is now blocked by mobile security. So I would be happy if they could find a way to at least give us more information on the types, even if dynamic invocation would still not be available. If you don't know, Dart itself has the mirrors library.

that allows you to get runtime type information, but it's not available on Flutter. So I'll try to find something in the middle. And another thing which is more related to Dart, I would feel that the generic features are a bit, let's say, could use some improvements here.

Maybe around more usage of the dynamic and usage of doubt. All those things have some room for improvements. I think they have focused a lot on

Now safety story. And hopefully now that it's behind them, we can see more language features coming in. We can see other languages at the end. And I would be happy to see more partners get into the language. Awesome. Is there any advice you give someone just starting out with Flutter? Well...

I'm trying not to sound too cliche. I think that our era is symbolized with a flood of information.

which can actually be very confusing for people that just start out because there are so many options, so many things they can learn, so many things they should follow. And I can see it when I answered questions on the main two Facebook Flutter groups that we have in Israel. People

people are really confused and the state management question for example is a good example for that because people don't really know what should they do there's so many things and you know everyone has their opinion so my recommendation is basically to try to focus try to try and start simple

Start with the Flutter documentation. Try to clear out all the noise. Have something like a site project or something that you really want to build and just put it out there. Ask for people that you trust or people from the community to review your code and to answer your question as you go.

There are also other ways of getting answers, Stack Overflow, the Discord channel of Slatter, and the Facebook groups as well. So just take it step by step. And the most important is just build something. Just make something work. And this is the way you actually learn by dirtying your hands.

Cool. That's good advice. Speaking of side projects, you first reached out to this podcast because of a package you're working on. Do you want to talk about, I think it's called Prism? Do you want to talk about what it does and the problems it's trying to solve? Oh, yes, of course. So, actually, Prism is not the name that I invented. And actually, also, the pattern that I'm using in the Flutter, please, I believe, are not

my invention. I would be happy to take credit for it, but I have to be, you know, true. So, actually, Prism library started out during the WPS era.

I think around 2007 at Microsoft, where people started to adopt WPS and they kept coming to Microsoft and tell them, okay, we see the Outlook Windows app, which is modular. The Outlook app has email, has contacted, has calendar to do, and we want to build apps systemically.

similar to Outlook. So how do we do that? And the pattern and practices team at Microsoft defined basically a guidance of best practices on how to develop modular apps. And Prism was a code library in .NET that helped build

And the concept, I had to implement this concept of modularity. So, a lot of the years I've been like a member in the advisory board, so to live with, and I helped evolve it to other technologies as we grow, as the years went by, basically.

UWP for example and when at Lumen now I'm like jumping to 2022-23 and so

At Lumen, we have now a very mature Flutter app, which is quite rare if you think about it. They started working with Flutter when it was just coming out of the beta, and it's 2018.

And they chose Flutter very, very early. So again, if we like jumping to now, we have a very heavy Flutter app.

And it contains a lot of features. I mean, you can separate the Lumen app into at least five apps which are standalone. For example, we have a fully-blown food log capabilities. You have an entire list of apps which only do food logging. Okay.

MyFitnessPal is a good example of an app in this domain. So, as you can imagine, AppNet was built for such a long time, and a lot of the patterns were invented along the way, all the best practices were developed,

discovered along the way. You have a lot of generations into the code of how you should model the app, how you should use the different features.

And since at Lohmann we really want to run quickly, iterate on features quickly, get responses from the consumers, understand what is good, what's not,

and build this app in a very vast pace. I understood that the approach we should have in the app is modular, and the same patterns that we used Prism back then applies to Flutter app, which is built for complexity. If you have a simple app, then Prism is not for you.

If your app has five, six requirements, user stories, then it's not the library for you. But if the app you want to build is complex and you want to have different models that each is maintainable and you can mix and match, because, for example, in the Lumen app,

we have a consumer device, an actual hardware device that's used for measuring. But let's say you want to deploy to the app store a version of the app. We start the device and allow the people to download it, use the full lock, for example, as we mentioned, and offer the device as an expansion or something that they can purchase. And then when they have the device, they will get the module of storage

using the device into the app and have extra features. But the app should work seamlessly even without those features. So you will need to work on the glue and how those modules interact with each other in a way that it won't break every Monday or Thursday when you build a new version.

So this is Prism, basically. It's a library that allows you to create those modules, allows you to bootstrap them and load them up in a sequence which is reliable. It allows you to compose the UI because a module can decide, okay, I have like a setting and I want to host this.

other widgets from other models. In the example that I used before, if we have a device model loaded into there, then I can have a widget which is specifically for the setup of the device.

So the settings area needs to dynamically behave with the models that are loaded. So we can have a separation between the host and the children that will be glued to the host without any of them to know who will be my host, who will be my children. So this is the concept of regions that we have in the Prism library.

And the third is a pretty standard publisher subscriber that allows to broadcast messages if needed in a way that the publisher doesn't know is subscribers and vice versa.

What is nice about my library is that you can easily extend it to use IOC containers. We will have a version of it that is using GetIt, but you can wire any IOC container as you like in the same manner. And we are also having another extension of Freedom Library with GoRouter.

And the Neo version of Renewal that we are building is basically based on those libraries. And so far, I can say I'm very pleased with the results. That's really interesting. Thanks for creating the library and sharing it. I'll make sure to include a link directly to this library in the episode notes. I think the full name of the package is prism underscore flutter underscore core. Is that right? Yes.

Exactly. And as I said, two more packages will be available as well on PopTel. Furthermore, this library, as I said, is very easily extendable. So this is why it's like Prism Core, because you can take it and extend it and...

Like, hammer it into the shape of how you would want to use it. The opinions there are very mild. And I try to keep it as a set of tools that you can use. Because you don't have to. You don't like PubSub in your app? Fine, don't use it. You don't like the concept of composing with and using the regions as I described it?

It's fine. Don't use it. You just want to use the regions without the models. You can mix and match and you can do whatever you want, basically. Very cool. Now, finally, is there anything else you'd like to add or promote? So I think I already promoted a lot, but I again will promote the Splats of Tel Aviv meta because I think that this way...

It's like one of the opportunities we have as a Splatter developers, Splatter community in our area to meet and greet each other. And I also call people to come and join. And of course, I hope not to see you coming as attendants, but also as speakers. And especially I'm looking forward to

Also, women speakers. So I really, really hope to see suggestions, to see sessions coming up. We have a meetup in this March 2023. This is when we are recording this episode.

And I will be speaking about Prism as well, this meetup. And I'm also going to take this session to Belgium. And there is a large development conference there. And they accepted my talk on the Flutter modularity feature that we talked about just now. So it's going to be really interesting

Happy meeting, I hope. And we already have plans for the next meetup, which will be early May. So tune into our meetup, and I hope to see you around. Thank you so much for being on the podcast. Thank you for listening. Till next time.

Thank you again for having me. It was a joy and high hope. I was able to contribute a little bit to the community and also grateful for the work you're doing. Keep it up. Thanks.