Yea I have used Flutter for hybrid apps and love the dev experience. The apps have come out great, and are smoother than my native Android work.
I am really hopeful for it and am going to keep using on it for hybrid apps.
I try to just tell devs to try it, then judge it. Because it does seem weird up front, but it is such a nice experience for devs and can make great mobile apps.
I think there is some place for these not quite ready junior devs. I have worked at and with some dev agencies and there seems to be a lack of technical QA on majority of projects.
My idea is to hire these devs that aren't ready to write code themselves, and have them do lots of technical QA. Pull down the code, run it on their machine, test all endpoints in Postman, write some simple scripts, etc. Then after several months doing that, give them a raise to move them closer to a dev salary and move them to active dev work.
You get to 1. Hire devs at a big discount since they won't be doing dev work quite yet. 2. Get to work with them for several months before letting them get active on code. 3. Even with the raise post QA period, they would be at a below market rate for junior devs.
Junior devs get 1. Experience in a technical position. 2. Opportunity to continue learning and see what it takes to build professional quality code. 3. On ramp to being a dev.
Maybe I got the numbers wrong on this and it isn't feasible. But it seems like a good tradeoff for agencies to bring on devs. Because devs are crazy expensive in the US and agencies have a hard time bringing them in while staying profitable.
Yeah, I think the issue is telling a client with a straight face you're going to add a "not quite ready junior dev" to a project to QA your own work for the client and charge the client for the privilege (even at a "below market rate") is a bit ... off.
And if you're doing it fixed-fee, then you really need to confirm that the QA is either accelerating delivery (and therefore reducing costs) so you can keep the price constant and collect more margin or ensuring a better (i.e. more valuable) outcome to the client to justify an increase in price in a fairly competitive bidding market.
This is a good sequence of events. Kind of what happened to me after I graduated from school - I didn't have much programming experience (my BS was essentially a math degree and I did it in < 2 years), so they hired me to answer phones, then from there I did level 1, then level 2, then releases, then level 3, then bugfixes and then I was finally granted the title of Dev.
Has the benefit of making sure you know the cost of issues and outages, knowing how to spot bugs, and generally how to be a good citizen both with the dev teams and the rest of the company at large.
> You get to 1. Hire devs at a big discount since they won't be doing dev work quite yet. 2. Get to work with them for several months before letting them get active on code. 3. Even with the raise post QA period, they would be at a below market rate for junior devs.
You'll pay every penny of the discount by wasting time tutoring them to the level of a real CS grad.
I am testing out if running can help me improve my focus.
Recently I have signed up for longer races and slowed my pace down. I find it is good practice for impulse control. When I get bored at work or at home, I quickly open a new tab or pull my phone out of my pocket. I would rather just be bored for a moment and stay on task.
I think running long distances can help me a lot because I do get really really bored out there, but there is not much to do but keep running.
Is there a debate about whether or not his foundation is doing more good than damage? I'd like to learn more about it. I find it interesting how difficult it seems to do philanthropy that has long lasting benefits without damaging some party.
I am not super knowledgeable about all the exact architectures, but I thought mobile was just starting to adopt the redux architecture vs MVP, MVVM, etc
A lot of people are saying that the new-but-not-really-new React Context API and useReducer hooks are sufficient to cover redux. My team isn't convinced, we see immense value because we're big fans of using Redux Saga-- a model that isn't well covered using Context or hooks, although we do use those APIs as well when needed.
Suspense for data loading seems to cover that side of things quite well in the experiments I've tried with the current API.
I use Sagas as well though, and Ive found them ok...really easy to test but feel very heavyweight and clunky; personally, I don't _really_ like the loading/error state to be handled by Redux: the more years I work on React/Redux app the more I prefer for a section of an app to be mounted -> triggering a fetch -> loading, show local loading UI -> {fails, show local UI|succeeds, dispatch success}. So Redux becomes a serializable normalized data cache that acts to store the results of disparate API calls and doesn't care at all much about the UI.
There's a tremendous amount of work out there for how to get redux to completely handle async and branching methods, and I think the best solution for most cases is to not have it handle any of that.
Keep your data fetching in normal everyday functions, have react components call those and funnel the data you need in the global store back to redux, and then have the components that need that data read it from the global store.
The results are in the Redux store. I'm not sure I understand the question, why and how would multiple components be making the same fetch request at the same time? With what I'm describing, there is already a common state, if they just need access to that state they have access to it.
Edit: If you do need to synchronise multiple async updates to that state that happen in a very short space of time & in an unknown order in a controlled way, then yeah something like sagas is a solid choice to exert control over that. But very often the user of the UI is only going to make one request [or one batched set of requests] -- eg I am working on an RN app at the minute, and each screen does need to fetch data. So I fetch in the component, it shows loading etc, then populates the store. If the user cancels what they're doing (navigate away for example), the component used to fetch unloads and no dispatch is made.
That was me! Component level fetch !== no Redux, that's not what I described; using Redux does not _mean_ you have to use one of the many libraries built to wrestle asynchronous fetching into Redux.
I've got nothing against any of them, I've used almost every major one in my jobs over the last few years. But I (and the person who replied to me) both seem to feel the same way, that in many cases just fetching in React, in the component, is all that is needed, let the Redux application deal with marshalling the resultant state (which it is very good at)
I have preferred this method myself when dealing with simple calls (calls that need no further external information). jumping through 7 files just to find the API request that gets shipped is slightly insane.
but how do you put the result back in the store? how about displaying a default failure screen?
> jumping through 7 files just to find the API request that gets shipped is slightly insane.
The API request is in the file that represents the point at which the API request is made by the user (previously in a loader component or, now, using a hook, in future using suspense), so I would say it involves jumping through 0 files, as opposed to several if I move it to redux (the dispatch occurs at the UI trigger point, then I have to drill through several other layers of abstraction). In practice there's normally some facade in front of the API to prefill values and also to make it easier to mock for testing, but if anything that just makes it simpler as the facade acts as a reference.
This is I guess down to a preferred philosophical approach but from my pov React is a UI library and it's _really_ good at showing conditional UI. Redux is a state container and is not great for this. I don't feel I want that in Redux, I want Redux purely to be a reference the state of the data in the app; loading/req/etc states are not that. Whenever I've moved error/request/loading/failure state to Redux (ie almost every app I've made over the past four years before this year) it involves a series of abstractions to track the current request. Whereas React can do this out of the box at the point the action is taken: make the request, show some state, if the request succeeds, dispatch the data to the store and [re]render the component that displays the data based on the state of the store.
> but how do you put the result back in the store?
dispatch({ type: "foo", data: "bar"})
And have a component that renders based on props in the store, same as normal.
We started a greenfield project a few months ago and decided not use Redux and try the context API instead. In retrospect, that was a bad idea. Context is fine for a small app, but small apps tend not to stay small... and then you're stuck with the Yugo when you what you really need is a truck.
In our main app we also use advanced features like what Slack is describing in their post, like having multiple Redux stores. We also combine stores from multiple sources (e.g. appStore = [...store1, ...store2, ...storeFromALibrary]. It's incredibly flexible.
Hooks are definitely going to reduce a lot of greenfield project needs for a state library, which should be great for React ease of starting new projects.
Something like Redux Saga, Redux Thunks, Redux Observable (my personal preference here), or what have you, are the higher order "toolsets" that Hooks alone aren't likely to replace yet. It may be the case that some of them are going to start targeting Hooks/Context more directly without "needing" an intermediary state engine like Redux, but it's also entirely possible that it will still remain a good reason to make a step change to a state engine like Redux when you find yourself needing higher-order coordination between components that libraries like Sagas, Thunks, or Observables can provide.
I think once you grok sagas, they're very difficult to replace. I think it's such a neat mental model to be able to dispatch global actions and having async tasks able to respond. I think it leads to nicer decoupling in components between UI & data.
Under the hood it uses [cofx](https://github.com/neurosnap/cofx) which is a library I wrote to solve the need to write declarative side-effects without redux.
I wouldn't say Redux is dead, but there are a number of alternatives. My team has switched from Redux to MobX for all new development, as the two libraries solve the same problems, and we find MobX a bit easier to work with for our specific use cases.
There's nothing wrong with Redux; we just found that Redux based code tended to have a fair bit of boilerplate, and it wasn't as easy to maintain code using Redux as we would have liked. Every dev team has to find the right place to draw the line on implicit versus explicit, magic versus verbose, convention versus configuration. No real right or wrong answers.
> I thought mobile was just starting to adopt the redux architecture
I don't think so, no. The Redux architecture (ie, reducers, actions, etc.) is fairly specific and not universally loved. I would say that people are starting to really grasp the importance of solving the problems that Redux solves, however.
I encourage you (and everyone facing the same problems) to take a look at Rematch (https://github.com/rematch/rematch). It's Redux (the real Redux, you can even use it with the Redux-DevTools) with a MobX-like syntax. And already comes with async support.
I have been a full time Android dev for past 5 years, and have really grown to dislike the work. UI development takes up so much of my time. And usually the fix ends up being some small attribute that only has an effect when combining X and Y UI parts.
Had the chance to do some Flutter work, and really enjoyed it. Could knock out the UI and later modify it with ease. Spent most of my time focusing on app logic, and not tons of UI work.
Happy Flutter is spreading elsewhere, I will try this out and spend some time looking into Hummingbird also.
Are you using the ConstraintLayout? Previously, I would have agreed with you. But, I've found the ConstraintLayout to be pretty fantastic when developing UI's.
Learning some JS to help out on a project. Having a good time playing around with this as I read through a JS intro book. Nice and easy to check things out as I work my way through code examples throughout book.
I have been a freelance Android Dev for past 4 or 5 years. I have recently built out a flutter app for a client. And honestly I am now looking for more Flutter work.
UI development in Android is such a pain and I feel like I spend most of my time trying to get the UI just right. With Flutter I am building UI so much faster and getting to focus on the actual logic of the code. Dart was fine, I learned it as I went. I enjoy it more than Javascript but like Kotlin much more.
The app I built with Flutter was pretty straightforward, so I haven't stretched the platforms capabilities, but hoping I get the chance to.
I haven't touched Android development since 2012. I remember the experience being a terrible hodge-podge of XML and Java which effectively required an absolutely attrocious IDE and an impossibly slow emulator. I assume things have changed since then, but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.
Those are still the not fun parts to work with in Android, although its better now kotlin extensions so you no longer have to refer to the XML directly to manipulate views.
Flutter doesn't use any of that, you just code and thats pretty much it. No XML or anything, and you can use VSCode which is a lot lighter than android studio.
Yes, tremendously so. It's still XML for basic UI, but Kotlin is the primary language of choice these days, Android Studio is a solidly world-class IDE, and the emulator is very fast.
> but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.
Flutter uses the regular Android emulator, and although you have more editor choice the recommended was to just use a plugin for Android Studio.
Your layouts & styles are typically all in XML. But honestly I don't find it bad - it's not "proper" XML, so there's not a ton of cruft. It's really more like XHTML.
Dart is "Fine" is the perfect description. It is pretty basic, but pleasant enough to use that it doesn't get in the way.
Kotlin, swift, rust, etc are more fun languages for me but Flutter is productive enough with Dart I am not about to ditch if becasue the language is decent at best.
Have you implemented any layouts using the Constraint Layout? Normally, I'd agree with you, but I find the Constraint Layout pretty great for designing UI's. The "glued together" approach makes responsiveness a breeze, imo.
They have taken short cuts on Android and instead of fixing the core app, they are focusing on their AR add ons. May be the right choice, but it has ended up with a horrible user experience on Android, at least on mid-level phones.
I am really hopeful for it and am going to keep using on it for hybrid apps.
I try to just tell devs to try it, then judge it. Because it does seem weird up front, but it is such a nice experience for devs and can make great mobile apps.