Cider 7

With the impending release of iOS 7, it was time to give Cider a makeover, and since some parts of the control structure were more than a little awkward, it seemed like time to pitch out baby, bath water, & all and just start over.

The Cider 7 controls are more or less done, and I’m now reworking the editor to use these new controls. Expect it all to hit a forum near you in the next few days.

In some ways, this version of Cider has fewer controls than previous releases, but this time the controls have been remodeled to look and behave much more like the native iOS controls in UIKit. Some of the controls also evince different behaviors. For example, in the image above the first group of controls are all Button controls, with only a style parameter bringing different behavior. You can see other example of these style changes in SegmntedControl and TextField. There are other examples not shown here.

The code structure of Cider 7 is also somewhat different, and is designed to be a compromise between UIKit and the old Cider, with a lean toward “whatever is easiest.” For example, the previous version of Cider used four coordinates to define the bounding rect of each control. Cider 7 uses position and size, both Vec2, in a way similar to UIKit. However, Cider 7 still let’s you define multipart objects like SegmentedControls with semicolon delimited strings – because it’s easy and compact.

There are a lot more variables for colors and other style elements in Cider 7, so you’ll find fewer instances of variables pressed into double duty, but you will have to learn new variable names. In general, style elements now follow the names used in UIKit (hilightedTextColor, etc). The default font of all objects has been changed to HelveticaNeue Light (with occasional use of Ultra Light).

One thing you won’t currently find is the Picker control from UIKit. Not because it’s not possible, but because I don’t like it. Though Picker has been significantly cleaned up for iOS 7, it’s still a screen space hog. It also falsely implies the size of the list in it’s curve. In most instances, I replace Picker with the DropList control shown above, which now has support for both short and lengthy lists.

In Cider 7 for first release

Frame
This base class (which would be called Rect if that wasn’t taken) returns with a compliment of routines for drawing, styling, and dealing with the geometry of rectangles. Now based on Vec2 position and size.

Control(Frame)
This base class for controls is now chock full of more variables and constants to help bring consistency to child controls. Though not of great use on its own, you can use it to provide grouping to other controls. In the image above, the white area are Control objects.

Label(Control)
Text labels. Nothing to see here. In fact, the Control class can pretty much do this job on its own.

Button(Control)
Replaces the old TextButton class. Default style is the frameless sharp edged button introduced for iOS 7 (and yeah, I know slightly rounded corners are back in the latest beta). Styles can give you differences in color and shape, like info buttons, detail buttons, and a highly non-UIKit standard (but fun) round button.

SegmentedControl(Control)
Replaces the older MultiButton control from Cider 1.6 with something that looks and behaves much more like UIKit’s UISegmentedControl. The styles here allow this control to also be used in search bars and steppers.

Slider(Control)
Cleaned up, restyled, and sporting style options that for the most part line up with UIKit examples. Supports icons as endpoints for when you want to get fancy.

Switch(Control)
The humble light switch returns in iOS7 style. Note that text and sizing are now handled differently on this control with an external label instead of text on the switch detail.

DropList(Control)
And now, batting in place of Picker… the DropList has what I think is smooth behavior that doesn’t destroy your screen layout, plus it scrolls both directions to support lengthy lists. There are some considerations with this control, particularly around draw order and the keyboard. More later.

TextField(Control)
The old multi-line TextBox is stripped back to a single line here, but styling lets it mimic several UIKit text options. And no, I still haven’t made actual editing of text any nicer.

ActionSheet(Control)
Though it’s drawn off in the corner in the image above, this is generally used as a centered “pop up” element. Easy to use with the old semicolon-delimited list, though like other list controls you can manage the contents yourself if you’re willing to put in a little work.

SelectList(Control)
A way to group a sub-set of control types in a “settings panel.”

SpotSwitch(Control)
Just think of it as another, non-standard Switch that I could bear to kill.

IconButton(Control)
Another non-standard control, but one that’s good at packing lots of info into a small space.

And… that’s it for the first release. I’m still working on tab bars and navigation bars, so they’ll be back soon.

Dials, Doughnuts, and other “display only” elements from Cider 1.6 are taking a hike to a different library.

So… thanks for reading. Any questions?

^:)^ wow

Incredible work, @Mark. I also don’t like the iOS 7 (or 6) picker control and prefer your version.

@Mark, this is awesome! I love the ActionSheet and can’t wait to use it to replace my popups! In 1.6 I had to make my own popups using multiple textButtons and it took me a while to get it to work correctly since the controls were created in a for loop and the variables used for the popups were based off of index and value of the table of controls I was iterating through. Ended up having to create a global table to store the popup controls otherwise my popup always used the values of the last control in the loop. I can see the ActionSheet making this much easier. Great work!

Very nice!

Wow! Now that’s what I call usable.

That is Awesome!!!

Now we can make apps with iOS7 look appeal :slight_smile:

Code-link!
Code-link!
Code-link!
Pleaaaaaaaaaaaase!

@Jmv38 - stop drooling 8-}

@mark looks amazing. Looks like it time to scrap my ui and completly move to cider :slight_smile:

Nice job, Mark. Looks like you went with Vec2’s, so I’m pretty glad to see that!

Any ETA on the code?

Ok, Cider7 “first draft” is up

CiderControls 7
https://gist.github.com/devilstower/6205073

Cider7 interface designer
https://gist.github.com/devilstower/6205085

Why did it take so long between the last post and this one. Well, I rewrote the library… three times. And it all comes down to coordinates.

Previous Cider users will remember that the root of all controls (if not all evil) was the Frame, whose init looked like this.

function Frame:init(left, bottom, right, top)
    self.left = left
    self.right = right
    self.bottom = bottom
    self.top = top
end

But that structure, which mimicked older frameworks, was at odds with both the way Ccodea lays out Rects and with the way iOS’ UIKit lays out controls. Meaning Cider both chaffed against Codea on one level, and wasn’t a good first step toward learning UIKit.

So when I rewrote the library for Cider7, I went to the base and changed Frame to this

function Frame:init(pos, size)
    self.pos = pos
    self.size = size
end

Where both pos and size were vec2. Internally, this worked well. It made for cleaner code within CiderControls and was a decent (eh, sorta) bridge to the heavily structure-based UIKit. So, there you go.

Then I tried using it… and I hated it. The problem was that, with few exceptions, I found myself building vec2s for no other purpose than to pass then along. There are some activities that naturally involve the generation and manipulation of vectors but in my experience, and in my trials of the alpha library, that just wasn’t true of interface design.

So the ripping and tearing began, and when it stopped, this is where we landed.

function Frame:init(x, y, w, h)
    self.x = x
    self.y = y
    self.w = w
    self.h = h
end

Elegant? Hardly, but it does make a Frame the structural equivalent of Codea’s Rect. If it helps, just think of Frame as a vec4, without the z.

To support other approaches, Frame is now festooned with convenience methods. You can address frame.x though frame:left() or see what frame.y + frame.h add up to by calling frame:top(). You can also change the location using frame:setPosition(pos), which accepts a vec2, and return a vec2 with frame:position(). In general, I’ve gone a little further down the road toward Apple’s insistence on getters and setters, but not very far.

It’s a compromise library, and I don’t expect anyone to love it. However, because I can approach problems pretty much however I’m thinking of them at the moment, it is a fairly easy library to live with.

And I’m doing something else for the first time: I’m writing documentation. Expect to see that soon.

This is the first time anyone other than me has seen this code, so expect issues. Let me know where you run into problems, have questions, or just have a better way of doing things. I’d particularly like some suggestions on better ways to deal with modal objects like action sheets and color selectors.

Thanks.

@mark looks awesome!

@Mark, those look great! Is there any reason that this is locked to Portrait only?

@JakAttak no reason other than I didn’t do the math for landscape.

The controls will work either way, it’s just the designer that’s currently locked down.

Oh, one other thing that’s changed in the editor. Previously, controls were sized by dragging the corners. The new version, in fitting with the change in underlying objects, takes a different approach.

I like the new approach which uses an X and Y box for precise placement, along with an H or W box for sizing along one axis. It’s much easier to line up components than before, and to see the effect of sizing on controls. You can stll jab your finger down anywhere in the middle of a control and drag it around freely, the new controls just lend precision.

Movie coming soon.

@Mark you guys and your portrait mode! :stuck_out_tongue:

@Mark, =D>