

Pegasus for Cocoa Touch - Framework to build UIKit view hierarchies in XML - saniul
http://jona.than.biz/projects/pegasus/

======
RandallBrown
It seems like a neat project, but I don't really hate Interface Builder that
much.

Getting rid of all the glue code is a _really_ nice part of interface builder
and this makes it so every UI element I want to use requires at least a couple
lines of code.

I also don't like the idea of randomly tweaking numbers and rebuilding to see
my whole interface.

------
jon4than
Just to add: I'm seeing a lot of click-thrus from Ycombinator onto my site.

This is fantastic and I'm glad people are checking it out. I'm also looking to
gather requests and feedback for how it can be improved further.

Right now it's little more than a proof-of-concept with a handful of adapters
for the most basic UIKit classes (UILabel, UITextField, etc. but support for
UITableView, UIPickerView, etc. is still in the works).

If anyone has any feedback, suggestions and/or criticisms please do leave a
comment on the site or post here and I will look into it.

------
jon4than
Developer of Pegasus here:

I hear what you say. The idea is not to necessary replace IB, but to provide
an alternative.

Next step is to include layout managers (similar to Android/Swing) which will
automatically lay out views based on some pre-defined templates (e.g. i*j
grid, horizontal, vertical, etc.) which will remove the need for randomly
tweaking numbers as you say ;-)

(Said so, this is how a lot of developers tend to work already...)

~~~
buff-a
Love it. I can't stand IB.

~~~
jon4than
Thanks. Please do follow the repo and check back on the site in the coming
days and weeks as I will be providing a LOT of updates which will (hopefully!)
make writing an interface in XML just as functional (if not more so) as
writing it in ObjC/designing it in IB.

------
headhuntermdk
I'll bite.. why describe your UI in XML when interface builder does it for
you? How does pegasus deal with localizing your UI in different languages?
This seems a bit like reinventing the wheel for very little benefit.

Who is the target developer? A new developer to the platform or an experienced
one?

~~~
jon4than
Thanks for your feedback.

1\. Because the XML generated by IB is completely incomprehensible for the
average (or even experienced) developer. The XML from IB was never intended to
be modified by the end-user. If you're talking about why you'd want to use XML
at all over IB, well there are several reasons: Firstly, many advanced
developers have ended up ditching IB for anything more than the most trivial
interfaces, because you can only do so much with point-and-click, sooner or
later it is just easier to do everything in code. Secondly, IB can become
confusing when working with lots of different views which have exotic
properties; you inevitably waste time clicking through submenus to find the
property you're looking for -- IB simply doesn't let you have a bird's-eye
view of your project and hides options away. The XML approach on the other
hand gives you a single file containing your entire view, all in one place --
a true embodiment of MVC.

2\. Localisation can be done with the existing APIs that are already in place.
Alternatively, one could (or I could) extend Pegasus to deal with localisation
in a wide range of other interesting ways. For example, you could specify
additional attributes to deal with each region, or specify a system whereby
each tag is flagged with a token that relates to a string localisation table.
Pegasus is simply a bridge between the XML and native UIKit controls, nothing
more. You can still access all of the traditional UIKit classes and properties
at runtime.

3\. I wouldn't say that Pegasus reinvents the wheel, I'd say it just offers a
different way of driving the wheel. For example, on Android users are able to
create their views in XML, but this functionality has not (until now) been
available to iOS developers. I'm simply providing a different approach to
creating a view, and while I'm at it, looking at providing a _better_ way of
creating views, by completely separating code from the views, implementing
useful features like hex-to-UIColor and JavaScript-CSS-Selector-style
searching for views based on tags and IDs. Thanks to recommendations I've
received today I'm also looking at creating layout attributes/tags whereby
views can be laid out automatically according so predefined templates,
something that just isn't possible currently. But it's important to remember
Pegasus in its current state is just an initial proof-of-concept. I'm in the
process of gathering feedback and ideas and looking to build upon it. This is
definitely not the finished product.

4\. I think that this is a product that transcendes the new/experienced
developer divide. Instead, let's look at the complexity of the product. I
think that what Pegasus provides right now is a very fast way to prototype a
UI. For beginners, this means they can write a UI without needing to know the
nuances of UIKit or the details of IB (which can be daunting at first). With
Pegasus, what you write is what you get, and I've tried to remove excess
"fluff" and boilerplate code wherever possible (e.g. I implemented "virtual
properties"). For experienced developers, I think that -- in time (not yet!)
-- Pegasus can provide a way to be able to strictly enforce an MVC workflow,
and to refactor and design views in a fraction of the time it could otherwise
take, without having the hassles of IB or the micro-management needed in
Objective-C: I just don't see why developers should have to worry about
creating object references, structs and enums when all they are doing is
creating a view. This should all be a totally separate workflow.

And what's more, I think that Pegasus provides a way for non-developers to be
able to design UIs. Even using IB requires some knowledge of Cocoa Touch/ObjC,
but with Pegasus the ultimate goal is to create a powerful platform on which
UIs can be designed and prototyped with only a basic knowledge of XML.

------
hakeraj
Interesting. Have you thought about using JSON to describe views (like in
QML)?

~~~
jon4than
It's already something I'm considering for a future release.

Having said that, I'm not sure that the readability of JSON (when producing an
interface like in QML) is as straightforward as XML.

~~~
hakeraj
Well I personally find JSON easier to read and write than XML. Though it might
be different for some people, I don't know. It would differentiate the whole
thing a bit more from the usual XML approach by interface builder.

~~~
jon4than
Will definitely take that onboard

------
huytoan_pc
How stable is Pegasus now? Is anyone using it for realworld applications yet?

