For anyone looking for something a little closer to what they know from the web: https://github.com/facebook/css-layout
Stevia: Human-readable auto-layout in code
11–20 of 60 posts
Re: Stevia: Human-readable auto-layout in code
#12I feel like the app developers who don't simply bite the bullet and use the technologies that Apple promotes inevitably dig themselves into a corner. Programmatic layouts/constraints just crumble underneath you when Apple decides to make changes in each new version of iOS or introduces a new formfactor.
I think that's often true, up until the point in time where it isn't. :-)
I remember that when DHTML/Javascript was young, from 1998-2004, you used the features built into every browser or you'd find yourself painted into a corner with the next release. Java applets, VBScript, ActiveX, Flash, and numerous third-party plugins: all dead. And then suddenly, around 2005, Prototype/JQuery/YUI/Dojo all came out, and you were an idiot if you didn't use a third-party library. The pendulum is starting to swing the other way now that browsers are pretty reliably standards-based, but there are still a number of people who look at you funny when you suggest using vanilla JS.
I was a little young to remember, but IIRC the same thing happened with the PC: through most of the early 80s, if you didn't write in assembly and use the specific features provided by each vendor, your app didn't have a chance. Then 1990 rolled around, decent C/Pascal compilers came out, third-party class libraries took off, and you got left behind if you still coded in assembly. Then by the early 2000s things had centralized under Microsoft .NET again, but by then the web was taking off and nobody cared.
It seems like this is the pattern of most software platforms: for the first 10 years, you better code to proprietary APIs because you won't be able to accomplish anything otherwise, and if you do it'll be obsolete with the next OS release. For the next 10 years, an explosion of third-party frameworks takes off, and you pick the one that makes you the most productive. In the last 10 years, things centralize again under a monopoly vendor, but by then the platform is already getting obsolete. Not sure where we are in the cycle for iOS - we've probably got a couple years to go - but it looks like it may be happening in Android land already, with Dagger 2 and RxJava.
Re: Stevia: Human-readable auto-layout in code
#13It's not really on-topic, but why do people name their projects with names that are very difficult to find via search engine? I really don't understand this mindset.
Re: Stevia: Human-readable auto-layout in code
#14It's not really on-topic, but why do people name their projects with names that are very difficult to find via search engine? I really don't understand this mindset.
All projects start that way, mostly because it very hard to invent a new noun for something. Some projects just get really popular and then get high on search rankings for that noun organically.
Re: Stevia: Human-readable auto-layout in code
#15I feel like the app developers who don't simply bite the bullet and use the technologies that Apple promotes inevitably dig themselves into a corner. Programmatic layouts/constraints just crumble underneath you when Apple decides to make changes in each new version of iOS or introduces a new formfactor.
Um, auto-layout, which this says it uses, is an Apple supported constraints system? https://developer.apple.com/library/ios/documentation/UserEx...
Re: Stevia: Human-readable auto-layout in code
#16It's not really on-topic, but why do people name their projects with names that are very difficult to find via search engine? I really don't understand this mindset.
All projects start that way, mostly because it very hard to invent a new noun for something. Some projects just get really popular and then get high on search rankings for that noun organically.
I get that¸ but naming your project a single word that has tons of pre-existing search results can't be a great idea if you're looking for traction. The average person's (or even programmer's!) Google-fu has always been much worse than I expected, ime.
Re: Stevia: Human-readable auto-layout in code
#17Since people are discussing Auto Layout alternatives, I'd recommend AsyncDisplayKit (http://asyncdisplaykit.org/) – although it's a bit more advanced. Layout mimics CSS and Flexbox. It was originally built by Facebook and very actively maintained.
You also get a number of other advantages, like moving UI operations off of the main thread (which is often a pain point in iOS apps shooting for 60fps).
Re: Stevia: Human-readable auto-layout in code
#18It's not really on-topic, but why do people name their projects with names that are very difficult to find via search engine? I really don't understand this mindset.
I don't think this is actually an issue. You can always add context to searches -- rather than searching for just "stevia" you can search for "stevia iOS layout"
Re: Stevia: Human-readable auto-layout in code
#19Is that operator-overloading abuse or something else?
Re: Stevia: Human-readable auto-layout in code
#20It's not really on-topic, but why do people name their projects with names that are very difficult to find via search engine? I really don't understand this mindset.
I don't think this is actually an issue. You can always add context to searches -- rather than searching for just "stevia" you can search for "stevia iOS layout"
I mentioned it in my response to the other reply, but I've found that the average programmer's Google-fu is actually quite poor, and they would not do that subsequent narrowed search.