Great question. You can do this with a cell consumer (i.e. the with() method). See OrientationTest for an example (e.g. leftToRightButton, rightToLeftButton):
UIStackView is a step in the right direction, but it doesn't go far enough. It's still not truly declarative; it requires you to think in terms of content priorities; and it doesn't support z-ordering.
For one, you can't create a hierarchy of UIStackViews and their contents declaratively. But UIStackView also forces you to think in terms of content hugging and compression resistance priorities, which (to me) isn't as natural as widths, heights, or weights.
I understand the GraphQL pitch - I just don't buy it. From my experience, you don't generally need that level of flexibility. Most callers probably want the full set of data returned by your API. Those that don't can easily ignore it or filter it out client-side. So GraphQL is basically a big, unnecessary hammer.
Hi all. I'm the author of this project on GitHub. It seems like it might be a good foundation for building microservices in Java. However, I'm not a microservices expert, so I was wondering what others with more experience in this space think. Thanks!
I agree that 1 - 2 hours of homework may be excessive. However, 10, 20, or even 30 minutes seems reasonable to me, assuming that it reinforces what is being taught in school.
And yet, most of the population won't end up making a living from their sporting accomplishments. However, they will get a job based on what they learned (or didn't learn) in school.
That sounds cool. WebRPC isn't meant to be an "everything to everyone" solution. It's main advantage is simplicity and low overhead. It allows you to quickly and easily build a service tier that is consumable by multiple clients. But if your requirements scale beyond what WebRPC provides, Thrift sounds like a great option.
If you are implementing a REST service, then I agree with you 100%. WebRPC is simply a different interpretation. In WebRPC, GET means "get the result of executing this method". POST basically means the same thing, but the arguments are passed in the message body (just like an HTML form).
The client libraries all use POST internally - GET is primarily useful for testing and debugging (so you can easily execute a method in the browser).
Not sure. The client libraries don't work with sockets directly. The Java client uses HTTPURLConnection, the Objective-C/Swift client uses NSURLSession, and the JavaScript client uses XMLHttpRequest. You'd have to check the documentation for each of those to see what they might be doing under the hood, or what options you might have for configuring them. Same goes for the server, which just sits on top of a servlet container. You'd have to see the container docs to see what your options are.
However, I ultimately found that approach too limiting and went with custom layout managers for version 1.2.