Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Wack how dare you mention hybrid. This is a Native only discussion. Pack your bags and leave sir!
-
@practiseSafeHex hey flutter IS nativ. It's directly compiled ARM assembly...
-
@Wack it compiles down to native and so does Xamarin and Titanium. The AMOUNT of shit these two platforms have caused me is unbelievable. I just don’t buy into hybrid any more. I don’t think it fixes anything, I think it only moves the problems somewhere else, but with a smaller community where things are harder to debug / get help with.
-
@practiseSafeHex fair. But then again xamarin and those use still a js realm to do calculations, animations and so forth (usually), which slows things down as fuck. Flutter doesn't do this but in the end gives you two nativ only apps, where you only need to write the busines logic once.
-
@practiseSafeHex I don't have any experience in this particular field, but to me, it sounds like you've already made all the right arguments why not to use them.
-
@Wack good point for long term. Short term if I wanted to take it out I think I need to justify why to put in the effort. So probably a bit of both really
-
@btft no manual fetching? But when you pull to refresh or click a button you still need to trigger a network request and then handle the result.
When you subscribe to a button click event. Is that not identical to the target action pattern already in iOS.
Not being tied to data types just depends on how you encapsulate. Good use of generics and protocols does the same thing.
I’m not afraid of it, I just don’t get it. If I’m making a team learn it. I wanna see a big pay off and I just don’t -
Tbh I dont know Swift but Rx is about streams of data, Pub/Sub behaviour and functional approach to processing those streams of data. You can manually start data fetching but then only subsribe to upcoming events from reactive streams. Its not really nothing new, it's simply standardization of one of possible approaches.
-
@btft I get the approach. And as I said I have nothing against the approach from a computer science point of view. What I’m asking / concerned about is:
Given the platform already has a perfectly fine approach to dealing with data and updating the UI. Is it really worth changing everything, and adding a big layer and dependencies to have Rx.
What can I do in Rx that I can’t do else where?
What killer feature does it add to make up for the performance / memory hits to adding something like that?
Myself and 4 developers are going to have to spend weeks learning it, what will we get for our trouble? How will we justify the investment? -
Don't know about RxSwift, but I use RxJava as a library not a framework.
I think the correct approach is to use it where is needed, the main value I see in Rx is the tons of operators you have available, like throttling, map, timers, zip, etc and the lifecycle operators to go on and off the main thread, background threads and io threads very cleanly.
So get to know the operators and how to combine them, that way you can tell very quickly when Rx is an overkill and where to apply it to solve a complex data flow problem.
Sorry if my answer is too generic. -
@spaceJunk no, thanks that’s kind of interesting. So to clarify, I’m looking at a codebase here, where every button click, text field event, networking request, or any user reaction goes through Rx.
You don’t do this? You don’t have it touching every part of your app? -
@practiseSafeHex not at all, you can do that but that's a too big paradigm change, and not every developer is used to that.
For instance, I us it a lot to coordinate io, db and network with main thread, I only use it with ui event listeners when I need to throttle user clicks, or to throttle layout updates from background or server events, etc.
Is not all over the codebase. -
I still remember my school days. Everything was going smoothly until we were tasked with learning Java. I struggled a lot, trying to understand the syntax and logic behind it. Then, a friend recommended a great site called https://essays.edubirdie.com/java-a... where I found all the needed resources. That experience taught me never to give up and always explore different problem-solving methods.
-
I still remember my school days. Everything was going smoothly until we were tasked with learning Java. I struggled a lot, trying to understand the syntax and logic behind it. Then, a friend recommended a great site called https://essays.edubirdie.com/java-a... where I found all the needed resources. That experience taught me never to give up and always explore different problem-solving methods.
It all makes sense now...
Just found the best dev ever.
https://alcohollick.com/tfw.html
!rant
Need some opinions. Joined a new company recently (yippee!!!). Just getting to grips with everything at the minute. I'm working on mobile and I will be setting up a new team to take over a project from a remote team. Looking at their iOS and Android code and they are using RxSwift and RxJava in them.
Don't know a whole lot about the Android space yet, but on iOS I did look into Reactive Cocoa at one point, and really didn't like it. Does anyone here use Rx, or have an opinion about them, good or bad? I can learn them myself, i'm not looking for help with that, i'm more interested in opinions on the tools themselves.
My initial view (with a lack of experience in the area):
- I'm not a huge fan of frameworks like this that attempt to change the entire flow or structure of a language / platform. I like using third party libraries, but to me, its excessive to include something like this rather than just learning the in's / out's of the platform. I think the reactive approach has its use cases and i'm not knocking the it all together. I just feel like this is a little bit of forcing a square peg into a round hole. Swift wasn't designed to work like that and a big layer will need to be added in, in order to change it. I would want to see tremendous gains in order to justify it, and frankly I don't see it compared to other approaches.
- I do like the MVVM approach included with it, but i've easily managed to do similar with a handful of protocols that didn't require a new architecture and approach.
- Not sure if this is an RxSwift thing, or just how its implemented here. But all ViewControllers need to be created by using a coordinator first. This really bugs me because it means changing everything again. When I first opened this app, login was being skipped, trying to add it back in by selecting the default storyboard gave me "unwrapping a nil optional" errors, which took a little while to figure out what was going on. This, to me, again is changing too much in the platform that even the basic launching of a screen now needs to be changed. It will be confusing while trying to build a new team who may or may not know the tech.
- I'm concerned about hiring new staff and having to make sure that they know this, can learn it or are even happy to do so.
- I'm concerned about having a decrease in the community size to debug issues. Had horrible experiences with this in the past with hybrid tech.
- I'm concerned with bugs being introduced or patterns being changed in the tool itself. Because it changes and touches everything, it will be a nightmare to rip it out or use something else and we'll be stuck with the issue. This seems to have happened with ReactiveCocoa where they made a change to their approach that seems to have caused a divide in the community, with people splitting off into other tech.
- In this app we have base Swift, with RxSwift and RxCocoa on top, with AlamoFire on top of that, with Moya on that and RxMoya on top again. This to me is too much when only looking at basic screens and networking. I would be concerned that moving to something more complex that we might end up with a tonne of dependencies.
- There seems to be issues with the server (nothing to do with RxSwift) but the errors seem to be getting caught by RxSwift and turned into very vague and difficult to debug console logs. "RxSwift.RxError error 4" is not great. Now again this could be a "way its being used" issue as oppose to an issue with RxSwift itself. But again were back to a big middle layer sitting between me and what I want to access. I've already had issues with login seeming to have 2 states, success or wrong password, meaning its not telling the user whats actually wrong. Now i'm not sure if this is bad dev or bad tools, but I get a sense RxSwift is contributing to it in some fashion, at least in this specific use of it.
I'll leave it there for now, any opinions or advice would be appreciated.
question
functional programming
reactivex
java
library
reactive
ios
functional
swift
android
rxswift
rxjava