I wonder if there is an excellent document to show the difference between Combine and RxSwift?
It's good for me to quickly learn the Combine because I already had good knowledge about RxSwift
Đức Bùi posted a good article detailing the surface level differences. In this answer, I'll cover some other differences I've discovered...
A Cancellable and a Disposable are much more different than the article suggests. The former is required to keep the subscription alive, while the latter is only needed if you want to explicitly kill the subscription. So Disposables can be ignored, but Cancellables never can.
The share(replay: x) operator in Combine is equivalent to RxSwift's .share(replay: x, scope: .forever) and there is no notion of a share .whileConnected. This means that shared publishers can't be restarted like shared Observables can.
Other issues:
The back-pressure handling in Combine is an extra complication that
you will never need, but have to deal with anyway.
Every operator in Combine returns a different type and most of them are
wrappers around their source type, so they get extremely complex very
fast. The eraseToAnyPublisher() operator provides some relief but
having to constantly use it is its own torture.
The lack of UIKit support is tough. It's better to go with SwiftUI. As
such, it's not a simple translation from one API to the other, but a
complete rewrite.
You will quickly find yourself reaching for third-party libraries in
order to fill in the holes that Combine left open. If you are switching
to Combine in order to avoid third-party libraries, you've defeated the
purpose.
As for benefits? I have only found one. Combine Subjects are thread safe whereas RxSwift Subjects are not. In RxSwift you rarely need Subjects anyway, in Combine you need them constantly.
Related
On a new project with a new team, should we enforce to sort the members of the classes automatically in a specific order (e.g. by modifier and alphabet) prior to check-in?
The alternative is to let each developer group the members as he thinks. And since everyone has a different opinion of what is related and how the grouping should be, this pretty much comes down to random order.
So what are the pros and cons of having them sorted automatically? Is this bound to a specific IDE/development-process/build-process/language? What else do we have to consider?
Edit to foster more answers:
I once was in a project where we had to maintain several branches. Because of the inability of the RCS to support this appropriately (SVN by the time), we had to manually move classes and methods from one branch to another and than merge back again (most RCS can maintain a subset-superset-relation only in one direction). Because the methods could appear anywhere in the class in any order, merging was a nightmare. Enforcing automatic sorting of members right from the beginning would have avoided much of the pain.
On the other hand, if working in a long existing project without automatic sort order, it can be a bad idea to enforce this. Moving all the members around is basically the same as throwing away the versioning up to this point, because comparing files with older versions via diff will be no good anymore for the same reason that merging in the other project was a pain.
Same goes if refactoring is due. When methods are renamed they will also be moved, making a diff of two versions practically pointless. With different names AND different places, it is difficult to recognize methods again.
Given that your IDE can sort your members the way you prefer, I'd personally avoid a global company policy on the matter.
I think rules-for-rules-sake are an important factor in de-motivating a team. As programmers we have a certain mindset, a certain way of seeing the world. Practicality and pragmatism are often valued higher by many programmers than policy.
If it's a quick click of a couple of menu items to have the code look the way you want it to when it's your turn to look at it, I'd stick with those few clicks. (and make this into a quick keyboard shortcut for your convenience)
I like to have a consistent code layout, but I have learned the hard way that anything which only touches the topic of "coding style" always leads to endless discussions and can waste a lot of time. It is not worth it.
Far more important is to make decisions on other topics (architecture and design, tests, how to communicate).
Usually I tend to assume that related members will be grouped together over time. I see no advantage in using an alphabetical sort order, because that is what the IDE can do for me.
Renaming, moving code, deleting green code, adding comments is nothing I like to see mixed with other changes. That is why I usually split it into two changes - one, that updates the "code layout/style" and another, which changes the behaviour of the program.
In my case... I consider usefull to order by access level. I follow the StyleCop rules (.net but valid in any other languaje)
Public
Internal
Protected Internal
Protected
Private
static
non-static
Inside of this groups... I've some randomness, but I always put things like Id's or unique identificator first.
I'm not saying this is the better good practice in the word, but at least people know where to look for things.
Depending of the lenguaje and the IDE you choose, maybe you could be lucky and find a tool that rearange the code for you based on your owns preferences. (Resharper, in my case, It's a good help)
I consider sorting of class members useful if it results in better readability of code. A sorting scheme should not be too strict but strict enough to add to better code readability. I prefer this sorting scheme:
static fields
instance fields
constructor
methods
Each method that calls another method (mostly private) the called method should be below the calling method.
As pointed out above the only reason to order class members should be better readability because you write code once but read it a hundred times, so having an accepted (by the team) order system can boost productivity.
Ordering code to work around inabilities of RCS will not per se lead to better readability and thus will not boost productivity. In most cases such an ordering method will fail. I'm in doubt if an alphabetic order method could lead to better readability.
I'm trying to write a wrapper for the third-party graphics library I'm using. I'd like to make it general enough you I could switch libraries easily if I decide to port it over to another platform or OS.
The problem is I can't really find a good enough design. Besides the library I'm using, I'm also following the design of two other libraries to ensure a general enough design. But there always seems to be something one lib can do the others can't.
Do you have any tips as to how I should make my code more portable (easy switching of libraries)? Maybe you can suggest a design for a graphics wrapper that's worked for you in the past.
Do you have any tips as to how I should make my code more portable (easy switching of libraries)?
This is rarely of significant value.
If you think you must ensure portability you have three choices.
Least Common Feature Set. Take all the libraries you think you might want to use. Write down all the classes, methods and attributes and find the smallest common subset. You have to do some thinking to match up all the various names to be sure you've got the semantics as close as possible.
This will give you a minimal graphics implementation that must run everywhere.
However, it will be feature-poor and your application (or wrapper) will have to do a lot of programming to fill in the missing features in a uniform way.
Union of All Features. Take all the libraries you think you might want to use. Write down all the classes, methods and attributes and simply add each new thing to the ever-growing list of features. You have to do some thinking to match up all the various names to be sure you've got the semantics as close as possible to avoid adding duplicates.
This will present problems because a feature that's in one library must be implemented in all the other libraries. It's a lot of programming.
You're not the first person to have this thought and realize that it's really, really hard to do.
So what's the fall back?
Choice 3.
Pick your favorite library. Get something to work.
Based on customer demand, identify the most-demanded alternate library. Create the necessary wrapper so that your application can work with this library.
Iterate this last step until you're out of customers or the customer demand is so low that it's cheaper to fire them as a customer than it is to support them.
Rather than trying to run a bunch of tests. Does anybody know what is less resource intensive?
Bindings, KVO, or Notifications? Has anyone tested to see as well?
Chuck's answer is quite right as far as notifications vs. KVO goes, but I'd like to expand on the "Bindings are KVO + KVC + ..." part he mentioned because that's where the real pain in the ass can be. Key Value Coding seems like it's the more important consideration here, since you can't use Bindings without it. If you're worrying about performance for good reasons, you'd do well to note the cost heavy use of KVC can incur.
I would say that any circumstances that call for heavy querying as a result of a single action (example: asking a few thousand objects for the results of multiple key paths each) would be an indicator that you might want to avoid KVC (and Bindings by extension). Especially with long key paths ( -valueForKeyPath: vs. -valueForKey: ).
I've run hard up against this myself and am now working to eliminate this part of my architecture as a result. The relatively minute cost of Key Value Coding can seriously add up when you're asking 16,000 objects for the result of half a dozen long key paths as a result of a button press (even with NSOperation/Queue). The difference between using KVC and good-old-fashioned [[object message] message...] calls can mean the difference between a few seconds and well over a minute or two on large jobs. For me, the very same query calling the accessors directly (like [parameter name] or [[parameter variable] name]) represented roughly a 500% increase in speed. Granted, mine is quite a complex data model with a large volume of data for a typical document.
On the other hand, if many of your app's single actions affect/query one or a handful of objects and are mostly Key Value Observing-oriented (ie, change a last name and have it update in a few views at once), its simplicity can be akin to magic.
In summary: if your app queries/updates large volumes of data, you might do better to avoid KVC and Bindings for the query/update part because of KVC, not because of KVO.
On OS X, it doesn't generally matter. They're all lightweight. Apple itself relies on it, and so the implementations are highly optimized. I would write the code so that it is as readable as possible, and only optimize the speed/resource consumption when it's necessary.
Another point is that Apple often changes the implementation across the OS version. So, the relative cost (speed, resource consumption etc.) of various particular technologies often change. What can be found on the 'net can be often outdated. Apple itself emphasizes never to assume which is faster and lighter, and instead to use profiler (Instruments, etc.) to measure the bottleneck yourself.
These aren't really distinct options, per se. KVO is a special case of notifications. Bindings are KVO + KVC + a couple of glue classes.
Core Data is pretty amazing, and I've really enjoyed using the visual layout Xcode provides for it to organize things and get a quick sample of what data I've placed where. At times I've started to wonder if I'm making the best use of it, however, as after a while there tends to be such a mass of arrows that it becomes difficult to tell what's going where.
I try to keep this to a minimum by
grouping like objects together,
abstract objects/parents in trees with their children,
etc.
but the clutter seems inevitable.
What are some ways you employ to keep it optimally organized and readable?
This is difficult to answer in a general sense. I think it's important and you're right to give this some good consideration. I tend to obsess over the visual arrangement of things myself as I find it has a profound affect on my perception and ongoing understanding of my own schema. Xcode's data modeler is essentially a schema design and design documentation tool.
I strive to compartmentalize my own designs as much as possible. For example, if you consider an iTunes-like case, you might have a controller managing the library source list selection (a playlist, for a simple example), and another managing the members of the selected playlist. In the schema, there may be several "library-related" entities and several "playlist-related" entities, and there are definitely several "song-related" entities (album, artist, and song/track). I'd group the song-related stuff tightly together in a way that nicely arranges the relationship lines, but that keeps these entities visually separated by space from playlist- and library-related items.
In other words, if you keep related items together in clearly-defined logical clusters, separated by nice whitespace, organized in the same way you'd organize your controllers, the concepts are kept fairly clear.
The other problem is Xcode's automatic placement of the relationship lines. Unfortunately, there's little we can do about making those neat. I've been known to spend (actual time redacted out of embarrassment) worrying over balancing clearly-depicted relationships with clearly-depicted clusters of interrelated entities.
Good luck and happy OCD! :-)
here's better suggestion.
http://www.sebastianrehnby.com/blog/2013/01/15/structuring-an-ios-project/
Additionally, Services module, Helper module(your app utility classes)
services - (calling external services like your back-end server, DBOject services)
Also, this one
http://www.slideshare.net/MassimoOliviero/architecting-ios-project
I'm looking for patterns that concern coding parts of a GUI. Not as global as MVC, that I'm quite familiar with, but patterns and good ideas and best practices concerning single controls and inputs.
Let say I want to make a control that display some objects that may overlap. Now if I click on an object, I need to find out what to do (Just finding the object I can do in several ways, such as an quad-tree and Z-order, thats not the problem). And also I might hold down a modifier key, or some object is active from the beginning, making the selection or whatever a bit more complicated. Should I have an object instance representing a screen object, handle the user-action when clicked, or a master class. etc.. What kind of patterns or solutions are there for problems like this?
I think to be honest you a better just boning up on your standard design patterns and applying them to the individual problems that you face in developing your UI.
While there are common UI "themes" (such as dealing with modifier keys) the actual implementation may vary widely.
I have O'Reilly's Head First Design Patterns and The Poster, which I have found invaluable!
Shameless Plug : These links are using my associates ID.
Object-Oriented Design and Patterns by Cay Horstmann has a chapter entitled "Patterns and GUI Programming". In that chapter, Horstmann touches on the following patterns:
Observer Layout Managers and the
Strategy Pattern Components,
Containers, and the Composite Pattern
Scroll Bars and the Decorator Pattern
I don't think the that benefit of design patterns come from trying to find a design pattern to fit a problem. You can however use some heuristics to help clean up your design in this quite a bit, like keeping the UI as decoupled as possible from the rest of the objects in your system.
There is a pattern that might help out in this case, the Observer Pattern.
I know you said not as global as MVC, but there are some variations on MVC - specifically HMVC and PAC - which I think can answer questions such as the ones you pose.
Other than that, try to write new code "in the spirit" of existing patterns even if you don't apply them directly.
perhaps you're looking for something like the 'MouseTrap' which I saw in some articles on codeproject (search for UI Platform)?
I also found this series very useful http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/ where you might have a look at embedded controllers etc.
Micha.
You are looking at a professional application programming. I searched for tips and tricks a long time, without success. Unfortunately you will not find anything useful, it is a complicated topic and only with many years of experience you will be able to understand how to write efficiently an application. For example, almost every program opens a file, extracts information, shows it in different forms, allow processing, saving, ... but nobody explains exactly what the good strategy is and so on. Further, if you are writing a big application, you need to look at some strategies to reduce your compilation time (otherwise you will wait hours at every compilation). Impls idioms in C++ help you for example. And then there is a lot more. For this reason software developers are well paid and there are so many jobs :-)