Pegasus for Cocoa Touch - Framework to build UIKit view hierarchies in XML(jona.than.biz)
jona.than.biz
Pegasus for Cocoa Touch - Framework to build UIKit view hierarchies in XML
http://jona.than.biz/projects/pegasus/
6 comments
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.
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.
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...)
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...)
Love it. I can't stand IB.
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.
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?
Who is the target developer? A new developer to the platform or an experienced one?
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.
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.
Interesting. Have you thought about using JSON to describe views (like in QML)?
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.
Having said that, I'm not sure that the readability of JSON (when producing an interface like in QML) is as straightforward as XML.
How stable is Pegasus now? Is anyone using it for realworld applications yet?
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.