We've built an app through Flutter and realising that some of our user behaviour is best created for larger screens, where people are creating best on desktop. I've seen that the codebase is viable for transporting to a web experience. We want to avoid the desktop app and build for a browser.
Has anyone had experience with building for web browsers using Flutter?
What's been your experience? How good is the codebase for creating things such as:
Messengers
Posting and threads
Spaces, like Pinterest folders or Padlet like these - NewHope Crowdsource Space
This is the app on the store if that helps.
I'd greatly appreciate any feedback, thoughts or experiences you've had. I'm wondering whether to invest in Flutter for web browser or whether I need to go back to JS.
Thank you
We're exploring whether to develop the website through a different language and looking for people's experiences if they've attempted this.
The experience is not much different than mobile development, if you're used to it, really I recommend you usage this variant. Only one source code for all platforms.
In addition, the use of libraries is practically the same. The only thing that changes is that it compiles to HTML, CSS, and JavaScript.
I only recommend taking care of the adaptability to different screen sizes, using mediaQuery (height, width) and Expanded Widgets.
The rest stays the same, your HTTP requests (Dio is an excellent option). To work the logic layer also the BLoC design pattern helps a lot.
Related
With the recent announcement of Hummingbird, it looks like Flutter will mature for web apps. I was trying to learn AngularDart, but I personally believe Flutter web apps will be a better approach. I'd have to plan a lot to share my codebase between Flutter and AngularDart.
Will Hummingbird receive support for Flutter web apps? Does the use of AngularDart will have diminishing returns in the future?
I understand the answers might be very subjective, but maybe it would be better to discuss some serious advantages and disadvantages of flutter-web.
Update (13.09.2019) Hummningbird is now Flutter-Web and Flutter-Web is now merged to Flutter branch. Things have changed for good ;)
As always, the answer is: It depends.
If you want to reach a lot of users quickly, AngularDart is your friend as it provides a solid foundation right now.
Also notice that doing a lot of "planning to share your codebase", which basically translates to thinking about separating your business logic from your UI logic, is a win either way because the more modular code will benefit you in the long run.
Additionally, it's never a bad thing to get to know more frameworks.
However, if you can allow yourself to be patient and you're thinking in the long term, Flutter's future support for web and Fuchsia may intrigue you.
That's why - if you believe in Flutter's success - it can make sense to only develop for Flutter and then wait and see what's about to happen.
Personally, I believe Flutter will become a well-supported, versatile, general UI framework.
That's why I would recommend betting on Flutter if your project is not time-critical.
I think it really depends on your use case. AngularDart and angular_components are trying to support a more 'enterprise' use case. Complex web apps that are primarily desktop focused. While HummingBird is focusing more on the mobile web use case or where you already have a flutter app that you happen to want to target web also with the same target. So both will have a place.
I understand you very wel ;-)
I'm now tryin to recycle my carrer and been a lot of months learning Angular (The Typescript branch) I love work with it, so pleasant an so intuitive, I did some major web apps than are working very well ant the mantainence is easy, quick and clean ... the future seemed me and Angula in a long love afaire ...
But sudenly I hear about Flutter, like two monts ago, and I was captivated for the concept (before I already had try different aproachs to have one codebase an reach all mobile platforms, Xamarin in major part, and was painfull to learn and to use, ReactNative never make me feel anything), but Flutter is soo easy, with so much power than Xcode and Swift witch I been workin too and with wich when you have a middle project the storyboard is intelligible. I been learning Flutter full time last two months, already have app in appstores and doing my first web (wonderfull experince doing web without css, ohhhh yes).
Then my opinion is similart to the others "depends", but if I was you and was just starting to learn AngularDart I will go for Flutter without loocking back.
I been look into things about PWA (link: https://www.youtube.com/watch?v=LaS_5jUeh_0) and it does mention something called "App Shell Architecture",
My Uncertainties:
Can Progressive Web Applications support other Architectures such as MVC? or in order to implement PWA feature we need to change our Legacy Architecture to the Architecture that design for PWA?
Is it possible for us to continue use the Architecture that we are comfortable (in my case: MVC architecture) to implement PWA?
I'm migrating an MVC, Razor heavy app to be more PWA like, ultimately I want it full PWA with offline capability but there are a lot of things I need to change before I get there however hardly any of it requires changes to the existing MVC code!
The key factor, to answer your question, is building in MVC will not prevent you building a PWA and if you're happy with that architecture then carry on using it.
What matters more is how your pages are rendered (particularly if you want to go full offline) a heavy Razor based site for example will I think make life a lot more tricky, especially if you have dynamic elements on the page that rely on callbacks to the server.
So the first thing I'm doing is moving a lot of my functionality into the Javascript and uploading all the page data up front as JSON. Then I can have things happen dynamically with a lot less reliance on the sever.
Obviously saving and updating data still relies on the server and I've not got to that point yet, in terms of how to handle things in offline mode.
If it helps my starting point was to reduce callbacks to the server to the bare minimum required, once I get there then I'll know what I have left to deal with, including all the Razor pages!
You can use MVC to build a PWA. App shell is nothing but the skeleton of your page which you use to load your content. That has nothing to do with whether you use MVC or not. It is recommended and easy if you use SPA for PWA which make the app shell cachin easy. Again there is no hard rule. If you follow the recommendations, it will make your life easier.. recommendations are made for a reason!
This is a complaint about the quality of the content served by soundcloud's embed API (iframe)
The main css file has 235 KB (160kb gzipped) where 92% is not used at all.
The main JS file has 450 KB (149kb gzipped), possibly following the above situation.
We developers spend much time optimizing bytes from our websites. Seeing this after hours of work makes us think that soundcloud just don't care about us and users.
The main css file has 235 KB (160kb gzipped) where 92% is not used at all.
I am not sure you counted all possible views that widget might have.
The main JS file has 450 KB (149kb gzipped), possibly following the above situation
While we are trying hard to keep the weight of the widget low, you should realize that HTML5 widget is a complicated single-page JavaScript application that has many features, including API hooks to control the widget, ability to resolve various URLs, a way to customise the widget, a way for widgets to communicate with each other and more
We developers spend much time optimizing bytes from our websites. Seeing this after hours of work makes us think that soundcloud just don't care about us and users.
If you feel very strong about this, I would suggest to build only the functionality you need from the widget on your own – SoundCloud provides public API, so building a player with similar UI that only does things you need is your best bet – you could use tools like http://zohararad.github.io/audio5js/ or even https://github.com/kilokeith/soundcloud-soundmanager-player etc. for playback.
Good luck!
I am starting a new project where we need to make entering web data forms an easy experience on mobile.
Currently our web site data forms cannot be styled and made mobile friendly they also reside behind a company firewall, however we can do POSTS via XML to submit a data form.
I'm currently undecided to which approach would be best.
Rebuild the forms natively on the iPhone using iOS components
Somehow create a local HTML5 Data form on the mobile, and then have the iPhone parse this and submit via XML.
Has anyone done similar on mobile in the past, it would be great to hear of your experiences, one key piece to this project is that we also need to have the data forms offline, and have them posted when the device is back online.
Based on the background information you've given, I believe that the only way to go is with the native UI components. Here's why:
You've stated the need for offline form "submission". You will have a much easier time if you have a native form that stores the information somewhere and then submits it when connected.
You've stated the desire to provide an easy experience on mobile. For that, I would naturally recommend native UI controls. Your custom "native" web controls are more likely to be confusing and difficult to use. Contrast that with UIKit which presumably has a lot of research behind it (and millions of satisfied users to back it.)
In the long run, it will be easier to integrate with the rest of the device if you use native controls.
For making XML requests, I recommend the ASIHTTPRequest library.
In my opinion, the better option would be to recreate the forms using the iOS components. It would be much more user friendly, and faster, if done right.
This question has been asked in various guises. However. this is a slightly different take on things. By web application, I mean an ultra lightweight frontend - ideally an HTML page with form and regular buttons, with as little dependence on heavyweight JS libraries like jQuery as possible.
The goal is simple. I want to write a simple forms based application for use accross various mobile devices. I thought going the HTML route would be the simpler route (since browsers get around the whole cross platform issue) but even the browser approach seems problematic because of differing screen sizes on mobiles.
I have two questions:
For a simple form based application like I have in mind (possible 3-4 screens in total), I think the browser based approach gives more bang for my buck - am I missing a trick?
Are there any resources that someone can point me to for:
a useful reference for minimum (i.e. lowest common denominator) window size (I forget the technical term for the visible part of a page)
perhaps an example that will show a simple HTML page that will render correctly accross multiple devices?
The HTML5 mobile boilerplate will probably answer a lot of the questions about how to best get things to work across browsers:
http://html5boilerplate.com/mobile/
They have example markup and template implementations for things like browser/device specific CSS hacks, getting a custom launcher icon across different device styles, and implementing offline digest.
You really need to answer two questions before you pick a platform. First, what mobile devices and/or device capabilities are your lowest common denominator? There are lots of variable capabilities between most of those platforms -- screen size, input method, platform speed and mobile platform to name a few. Second, what is your connection requirement? Completely different issue building something targeting spotty or no connectivity versus a fully connected app.
Then you can start thinking about what tool(s) might get you there. In general, a very, very simple HTML site will look okish on most platforms you list. I wouldn't roll with HTML5 functionality because you've got serious limitations there. And HTML/web apps are kind of moot if you need things to work with limited connectivity.
iOS (webkit), Android (webkit) and BB OS6 (webkit-ish), are fairly easy to develop for.
Windows 7 should be, but who knows? They aren't promising HTML5 support until end of year.
BB OS5 browser sucks if you hope to be doing DOM manipulation or fancy JS event listeners. It's really buggy.
Nokia...it's a crap shoot. Granted, they have about one year left before they ditch their OS anyways.
Screen sizes are an issue, as is the fact you can change the orientation. But that can be gotten around with some careful planning.
HTML5/CSS/JS is definitely the way forward for making cross-platform apps as easy as possible...be it in the browser, or as a compiled app.