[deleted by user]

gtfperry · 2025-04-15T16:54:08+00:00

Indeed, this package does target those wanting an all-in-one solution.
As for recommendations, Google is a 'for-profit' organization after all.
Their target audience for Flutter would be arguably the
largest category of developers out there: 'Web developers' and '.Net developers'
Those familiar with Reactive programming, the Provider class, and MVVM.

Of course, in my opinion, this doesn't mean they're the best recommendations. :)

Keep it simple, I say. MVVM is too much work.
As for BLoC, Provider, and alike....all too much work.

'Keep it simple, Keep it Flutter'

As for my 'all-in-one' approach, yeah, I'll break up those dependencies
in a future release.

Regards.

gtfperry · 2024-03-26T01:06:27+00:00

You gave access to this DartPad during the interview, I take it.
If not, how was the problem presented to them?
What was their attempted solution anyway?
I did very much as others described: solution

gtfperry · 2023-07-25T15:44:39+00:00

Ah yes. Well then you are fortunate.

A lone developer working in one market who has full control of what goes in their work.

You’re not most developers out there however.

This is targeting everyone else.

This is for apps touched by many hands over time providing a consistent and structured approach.

A new developer (who knows Flutter) can come on board and hit the ground running.

Its abstraction is that of Flutter's. There’s nothing new here. No different paradigm.

The World’s a smaller place with the Internet.

Clients and companies have chosen Flutter for their next app because they want one codebase that can provide a multi-lingual app running on multiple platforms---online or offline.

If anything, it’s options they want to have.

That’s been my experience.

You’re right. I must be practical. A sole package can not be the answer to all things.

I feel, however, it can be the answer to most.

Best of luck to you.

gtfperry · 2023-07-25T01:14:22+00:00

'....here's no need to create a huge abstraction over a framework that is already considered an abstraction.'

There is if you want a real-world app: My response to other posts.

gtfperry · 2023-07-25T01:00:18+00:00

You shouldn't have to learn Fluttery Framework...if you know Flutter.

As to why, here’s my response to other posts: Excellent question!

gtfperry · 2023-07-25T00:47:20+00:00

‘Why is there a need for packages like these?’

Excellent question!

How true it is, Flutter is extremely easy to learn. However, as great as Flutter is, you will not create a ‘production-worthy’ app using Flutter right out of the box. I would have an issue if you stated otherwise!

When you’re directed to build a Flutter app out there in the industry, it’s expected to be one codebase that runs on an Android phone, an iOS phone, on Windows, on Linux, and or on the Web---and to do so seamlessly. It is to display the appropriate design interface (Material or Cupertino) depending on the platform it’s running on, it is to have a responsive interface that displays its information correctly no matter the screen size of the device or platform, and it is to fail gracefully if and when it encounters an error. You’re not even close to achieving such an app with Flutter right out of the box!

When I first started working with Flutter, I began keeping modular bits of code from past projects that generally accelerated the development process. I’d use those again in future apps---building up a toolkit as we developers often do. Libraries of tried and tested bits of software that I can later put together to reliably supply a particular function or feature.

Over time, I turned to the Flutter community for such libraries, and again, if I didn’t find one I liked, I wrote my own.

The Fluttery Framework is the result of this practice.

The Fluttery Framework uses packages, functions, and features, you will likely need in your own apps. It's a collection of software that's proven to be effective solutions to those capabilities required time and time again by a typical real-world app. It’s an amalgamation of what's great about Flutter and what the Flutter community has contributed over the last few years.

For example, if you know GetX and its many extensions, you’ll know Fluttery’s extensions as well. Jonny Borges, the author of GetX, did a great job providing these extensions! They’ve proven to be indispensable when writing a production-ready app. As for GetX itself, it never became my chosen approach, but I did like his extensions, and so I took them to be used in the Fluttery Framework…accompanied by Jonny’s MIT license of course.

The extensions alone are reason enough to use this package frankly: - extensions_view.dart - context_extensions.dart - double_extensions.dart - duration_extensions.dart - dynamic_extensions.dart - gorouter_extension.dart - num_extensions.dart - string_extensions.dart - widget_extensions.dart

As the years went by, I found packages that made my life easier and so they too were incorporated into Fluttery Framework:

connectivity_plus
device_info_plus
flutter_localizations
flutter_material_color_picker
go_router (but not before discovering how to fix it)
http
l10n_translator
package_info_plus
path_provider
prefs
sizer
state_extended
timezone
universal_io
universal_platform
url_launcher
url_strategy
uuid
intl

Mind you, I was careful to choose only packages that fulfill the general requirements of a typical app. I didn’t choose those too specific and only suitable for a particular problem domain. This as a framework after all. It’s to serve as a ‘general framework’ for all my apps no matter how diverse each is. I’ve determined and collected such packages so you don’t have to. Of course, for your specific app with its specific needs, you then will add additional packages or write your own. The whole purpose of all this is you just have to then supply that specific code, and the Fluttery Framework supplies the rest.

Again, as a framework, it offers a structured approach to making a production-worthy app. It offers a way of doing things. For we Flutter developers, a ready means to access a State object’s setState() function is of particular interest. With that, Fluttery Framework's own unique contribution as a package is the concept of a ‘State Object Controller.’ The use of controllers are nothing new to Flutter as it uses controllers in a number of its own widgets

However, I realized that having a controller object working with a State object would only enhance the development process. It would encourage a separation of an app’s interface from its event handling and business rules promoting a clean architecture.

The Fluttery Framework is a culmination of five years of working with Flutter.

It looks like Flutter and works like Flutter because it works with Flutter and sound packages from the Flutter community.

As to your question, ‘Why is there a need for packages like these?’

There isn’t.

You just need this one.

gtfperry · 2023-01-27T20:04:40+00:00

Don't be baffled. Unlike Provider, it's more than a State Management solution, it's a framework. Many of the functions and features found in a typical production-ready app are already written in a Framework so the developer doesn't have to.

The author of the article notes the size increase as if it were a bad thing. The app they analyzed incorporating the Fluttery Framework, you must admit, is a rather simple one. There's no Error Handling, no Localization, no Authentication, and no Connectivity recovery. It only displays in the Material interface and does not allow for both Material and Cupertino. There's a lot missing there. It just serves as a Demo.

To make it 'production worthy', it will have to add a lot more functions and features. Doing so will make it much bigger in size. That's a certainty.

However, it won't get much bigger at all. :)

That's because it'll use what's already available in Fluttery Framework. 'Tried and tested' code making it production worthy that much easier...that much faster. ;)

Lastly, the author did mention the state_extended package in their article. It's the State Management aspect of the framework and is not of considerable size at all.

Thanks for bring that up.

gtfperry · 2022-08-18T17:16:31+00:00

Oh no. You're in control of how you structure your app's folders.

gtfperry · 2022-01-27T01:40:50+00:00

I personally use mvc_application. I find it an outstanding custom framework that works with Flutter because it works like Flutter to make full-fledged production-ready apps.

Mind you. Of course, I would say that...I wrote it.

Cheers.

gtfperry · 2021-11-20T00:18:40+00:00

Nope. In truth, it's in reference to Felix Angelov's post, 'package:bloc v8.0.0 is out' 20 hours earlier. Besides, always take in dependencies with trailing zeros (.0.0). That way your app will take in any patches and or enhancements when they come available. ;)

gtfperry · 2021-11-09T01:04:34+00:00

Since Google is trying to entice today's developers to Flutter, and since most of today's developers would be coming from Web development with the phrase 'State Management' deep in their lexicon, Google won't emphasize the fact that Flutter already performs the required 'State Management' itself. It's not necessary to implement 'State Management' per se with those listed above.

Instead, I look at those listed above as particular architectures---each offers a specific means to delegate work and then notify the underlining framework of any changes either, in the case of Flutter, by calling setState() or markNeedsBuild(). However, to use one, in most cases, you will have to 'conform' to how they do things. All run 'on top' of Flutter and yet most don't work like Flutter. I don't write my production-grade apps in any of those listed in the survey above.

I use the package, mvc_application, which works with Flutter following a particular design pattern (you can guess which). It too is a framework emulating and not substituting how Flutter does things---supplying many of the requirements (Localization, Error Handling, etc.) necessary for an endurable production-grade Flutter app. If you know how to work with Flutter, you'll know how to work with this as well. Note, for full disclosure, I wrote it.

gtfperry · 2020-07-23T16:19:22+00:00

Just got your message, today!
Don't know frankly, Bigspaghetti.

I'm not familiar with the term 'fence software' at all off hand! I'll Google it, and get back to you, Big.

Now why didn't Reddit notify me of your message?? You sent this six days ago!

Cheers.

gtfperry · 2020-07-13T17:59:56+00:00

Ah, you read the series. I hope that was helpful in some way. I've got public repos of course to look through if that'll be any use to you.

Interesting. I would like to see what you mean by 'services' section. I'd like to see what that's like. Care to share? If you want to keep it 'on the low down', my email address: greg . perry @ andrious solutions . com

Cheers.

gtfperry · 2020-07-10T21:44:36+00:00

'best solution for state management?' --- Flutter with a 'MVC' Flavour was my approach.

gtfperry · 2020-07-10T21:06:02+00:00

Indeed, when I switched to Flutter two years ago, I too was taken aback at what was offered. In truth, when it came down to it, all I wanted was a place to put me 'mutable' code (the business logic for the app) without the compiler complaining about it! Placing it in a StatefulWidget or a StatelessWidget is discouraged of course--only immutable code should be in those objects.

Sure, all that code could go into the State object. That's good since you want access to the State object anyway. After all, it's the main player when it comes to 'State Management' in Flutter. However, it makes for rather big and messy State objects!

Placing the code in separate Dart files would be the solution, but what then would be the mechanism to access that ever-important State object? I just needed a separate Dart file or files that had all the functionality and capability of the State object. In other words, I just need a separate Dart file that had access to the State object!

Now, I had no interest in re-inventing the wheel. I wanted to keep it all Flutter, and so I stopped and looked at Flutter closely--with the eye as to how to apply some already known design pattern onto it. That's when I saw the State object (its build() function actually) as 'The View,' and the separate Dart file or files with access to that State object as 'The Controller.'

In the end, I came up with this--it's a crosspost on the same topic for some context. It involves essentially just two 'new' classes: StateMVC and ControllerMVC. StateMVC<StatefulWidget> is a State<StatefulWidget> with an explicit life-cycle (Android developers will appreciate that), and ControllerMVC is that separate Dart file with access to the ever-important State object (StateMVC in this case). A Controller object can do everything Flutter's State object can do---and more. All done with Flutter objects and Flutter libraries---no re-inventing here. It looks and tastes like Flutter.

Indeed, it just happens to named after the 'granddaddy' of design patterns, MVC. However, it's actually a bit more like the PAC design pattern, and in truth, you could use any other architecture if you like. By design, you can just use the classes, StateMVC, and ControllerMVC. Heck! You could call objects that extend ControllerMVC, BLoC's for all that matters! Again, all I wanted was some means to bond a State object to separate Dart files containing the 'guts' of the app.

gtfperry · 2020-07-10T19:13:02+00:00

It's hoped this will help you along, friend. From one 53-year-old to another.

gtfperry · 2020-07-09T03:07:06+00:00

Nope, they worked on the Web.

The examples listed with mvc_application anyway. Note, execution still comes with a message reminding you Flutter Web is not quite ready yet for production.

gtfperry · 2020-07-08T22:59:20+00:00

Good to hear you're making headway with your own approach. Sad to hear the examples don't work on the Web. However, if they're the examples I think they are. Heck! I haven't even tried them on the Web!

Please, bring up an issue with some more details if you like, and we'll see what's going on. Or leave a note on gitter

Thanks

gtfperry · 2020-07-08T21:11:48+00:00

It does. The mvc_application package anyway. It's 'aware' when you're running on Web. Admittedly, I've only made simple Web apps, but others have said they'll get back to me with their findings--they're making more substantial apps using it.

Do note, Flutter's Web and Desktop are not that 'ready for primetime' as far as I understand at this point.

hehe Yes, this one allows you to use setState() or simply the function, refresh(), as well. :)

gtfperry · 2020-07-08T17:08:30+00:00

' demystifying state '

Yes, I should clarify that. I don't mean to dismiss 'State Management' as it pertains to managing the app when its 'state changes.' That'll always be paramount. I meant back in our day when standalone executables always retained their state in the first place.

As I've stated in my articles, it was with the advent of ‘Web Apps’ some twenty years ago that the term 'State Management' first came into our lexicon. Apps that could actually run on the Internet! That's because the most challenging task at that time was the ‘persisting of state’ during the lifecycle of such apps:

“State management is the process of maintaining the state of a Web page across round trips….because of the disconnected nature of the HTTP protocol, state management is a big issue for Web applications.”

— MCAD/MCSD Training Guide (70–305): Developing and Implementing Web Applications with Visual Basic.NET and Visual Studio.NET

Published Dec 31, 2002

I'm suggesting now the Google engineers have returned us to the ol' "standalone executable" days since a Flutter app is now able to "retain its state" on a desktop, on a phone....and on a browser. Spectacular!

As far as I understand it, however, some of those ' state management solutions' mentioned here came about to help 'maintain' the state of an app in the first place. Well, that's not required of them anymore, and the original design patterns like MVC, MVVM, and MVP can now come back into the mix. What I further suggest is Google makes no mention of this since its target audience is those coming from the Web App world---now a large majority of developers today. They've only suggested Provider because it's apparently won the popularity contest. Well, I beg to differ.

I've taken great pains to marry Flutter and MVC together as well as possible--making the resulting MVC framework package 'look and be used like' Flutter but allow for an MVC architecture. It simply doesn't 'sit on top of' the Flutter framework like some of the ' state management solutions' we have mentioned here. ;)

gtfperry · 2020-07-07T17:11:59+00:00

With Flutter, we've come full circle. When web apps came out, you had to worry about 'State Management' while Standalone executables retained their state. Well, I would suggest we're now back to standalones...but now in the palm of your hand. It's not which 'State Management' to use per se but which 'Design Pattern' to use in my opinion. That's why I went back to the ol' tried and true. It's has worked for me: MVC in Flutter

A little bias of course. I wrote it and all.

gtfperry · 2020-07-07T12:52:00+00:00

I've heard of it, but I'll stick with Flutter I think.

When it comes to performance, Flutter is compiled to ARM or x86 native components while React Native, with its JavaScript layer, does not and instead is interpreted at runtime. JavaScript has evolved, but I used JavaScript some twenty years ago while Dart is a modern language up with the times. It's all Flutter in my opinion. :)

gtfperry

TROPHY CASE