4 ms·

How far are you planning to go in your support for css properties ? css animations/transitions ? Positionning (top, left, right) ? There are a lot of similari

by bsaul 14y ago

How far are you planning to go in your support for css properties ? css animations/transitions ? Positionning (top, left, right) ? There are a lot of similarities, but by going very far you may end up rewriting a lot of the storyboard xml in a css format... Then maybe later on, you'll want a WYSIWYG css editor on top of it, and i'm a bit wondering whether you won't have ended up rewriting absolutely everything. From my personal opinion, CSS is nice the first 10 minutes, or whenever you only have a few element to style, but styling a complete app along with animations between states makes you really want to stay away from it as far as possible for mobile apps (and especially ios where resolutions are quite standard)...

pcolton 14y ago
Storyboards aren't dynamic. Our CSS implementation not only lets you style your app, including animation and transition, but it can be changed at run time, either locally or remotely -- just like the web. Think of storyboards/xibs as a layout mechanism, and ours as a dynamic styling mechanism.
- bsaul 14y ago
  It's theoretically interesting, but after having coded ios app for the last three and a half years i really don't see any user case where you'd want styles to be dynamic, and not behavior. Either use a UIWebView if you want to include completely dynamic and server-generated content (such as ads), or use native... Do you have any example ?
  - pcolton 14y ago
    One real-life example (told to us by a customer): imagine you have a "spring sale" that you want to promote to your customers. You want to customize the look of the app, perhaps rearrange a few things, change the look, etc. You want to do this for a period of time, and perhaps even for a certain geographic or demographic area. With Pixate, you could push new CSS and assets as needed, then revert when the sale is over. You could even push different looks to different users, etc. Effectively, Pixate is the flexibility of web with the power of native.
    - bsaul 14y ago
      Oh, ok, i didn't see that Pixate also handled download and caching of images. That's a good use case indeed, thx.
bennyg 14y ago
I'm with you about CSS. It seems the target market of this app is geared towards Web->iOS devs, but that seems like a smaller slice than something like "Bootstrap for iOS" should be made to do. Bootstrap is great because it makes web development so much easier through native uses. It doesn't add another language paradigm to make web development easier - it does it inherently. 1) If you're gonna' call it "Bootstrap for iOS", have the analogy end there. The site is way, way, way too much like Bootstrap already. Brand it better. 2) Good native code should be inherent! Nobody should have to learn CSS to make better iOS apps! A beginner should have a framework for her/him that allows something easy like [view fadeIn] and it work. Then, if they want a little more control something like [view fadeInOverTime:seconds]. Adding a shadow should be as easy as [view addShadow] or [view addShadowWithCornerRadius:radius]. Rounding corners is already extremely easy using QuartzCore, but let's make it even more intuitive for people. [view roundCorners] and then [view roundCornersWithRadius:radius]. The whole point is to make development exponentially easier for anybody to come in and start making useful, beautiful things. I'm working on a class to include that does all of point #2 plus a ton more - and seeing this post will probably be the catalyst to releasing it this weekend. I have a huge plan in the works for making extremely easy to use UI elements as well, but I think open sourcing this in chunks, then releasing the whole thing as an example on how they all work together is gonna' be the route I go. So far, I've released one part of the project that makes choosing good colors to use in the app a breeze (https://github.com/bennyguitar/Colours-for-iOS https://github.com/bennyguitar/Colours-for-iOS). The next one will be for UI utilities like the fade in and shadow code mentioned above.
- nmcfarl 14y ago
  Coming to Cocoa dev from the web all of the direct manipulation in objective C of styling seems like mayhem. I’m not very far in, but already the giant amount of searching and replacing required to change all the corner radii in an app is crazy. For me it seems obvious that this stuff should be /declared/ in one place, with all other styling mechanism, not littered through dozens of classes that are primarily interested in getting things done, not looking pretty. Of course I’m a new at this - and everyone seems to think the other way is better… So maybe I’ll come around with time, but right now Pixate seems like a great idea.

by bsaul 14y ago

pcolton 14y ago

Storyboards aren't dynamic. Our CSS implementation not only lets you style your app, including animation and transition, but it can be changed at run time, either locally or remotely -- just like the web. Think of storyboards/xibs as a layout mechanism, and ours as a dynamic styling mechanism.

bsaul 14y ago
It's theoretically interesting, but after having coded ios app for the last three and a half years i really don't see any user case where you'd want styles to be dynamic, and not behavior. Either use a UIWebView if you want to include completely dynamic and server-generated content (such as ads), or use native... Do you have any example ?
- pcolton 14y ago
  One real-life example (told to us by a customer): imagine you have a "spring sale" that you want to promote to your customers. You want to customize the look of the app, perhaps rearrange a few things, change the look, etc. You want to do this for a period of time, and perhaps even for a certain geographic or demographic area. With Pixate, you could push new CSS and assets as needed, then revert when the sale is over. You could even push different looks to different users, etc. Effectively, Pixate is the flexibility of web with the power of native.
  - bsaul 14y ago
    Oh, ok, i didn't see that Pixate also handled download and caching of images. That's a good use case indeed, thx.

bennyg 14y ago

I'm with you about CSS. It seems the target market of this app is geared towards Web->iOS devs, but that seems like a smaller slice than something like "Bootstrap for iOS" should be made to do. Bootstrap is great because it makes web development so much easier through native uses. It doesn't add another language paradigm to make web development easier - it does it inherently. 1) If you're gonna' call it "Bootstrap for iOS", have the analogy end there. The site is way, way, way too much like Bootstrap already. Brand it better. 2) Good native code should be inherent! Nobody should have to learn CSS to make better iOS apps! A beginner should have a framework for her/him that allows something easy like [view fadeIn] and it work. Then, if they want a little more control something like [view fadeInOverTime:seconds]. Adding a shadow should be as easy as [view addShadow] or [view addShadowWithCornerRadius:radius]. Rounding corners is already extremely easy using QuartzCore, but let's make it even more intuitive for people. [view roundCorners] and then [view roundCornersWithRadius:radius]. The whole point is to make development exponentially easier for anybody to come in and start making useful, beautiful things. I'm working on a class to include that does all of point #2 plus a ton more - and seeing this post will probably be the catalyst to releasing it this weekend. I have a huge plan in the works for making extremely easy to use UI elements as well, but I think open sourcing this in chunks, then releasing the whole thing as an example on how they all work together is gonna' be the route I go. So far, I've released one part of the project that makes choosing good colors to use in the app a breeze (https://github.com/bennyguitar/Colours-for-iOS https://github.com/bennyguitar/Colours-for-iOS). The next one will be for UI utilities like the fade in and shadow code mentioned above.

nmcfarl 14y ago
Coming to Cocoa dev from the web all of the direct manipulation in objective C of styling seems like mayhem. I’m not very far in, but already the giant amount of searching and replacing required to change all the corner radii in an app is crazy. For me it seems obvious that this stuff should be /declared/ in one place, with all other styling mechanism, not littered through dozens of classes that are primarily interested in getting things done, not looking pretty. Of course I’m a new at this - and everyone seems to think the other way is better… So maybe I’ll come around with time, but right now Pixate seems like a great idea.