Using the Dock connector involved paying Apple a licensing fee. This circumvents that, and it's similar (although more involved) to how Square's card readers work.
There is already an iOS serial cable though, which I would think would be a better option for many projects:
" Under current Apple policy this cable may not be used with apps sold on the App Store."
That's an odd condition of Apple's terms. Why is this so? If I go through the process of designing and approving a hardware device, I can't sell an app to go with it? Or do I have to provide the app in tandem with the device?
"may not be used with apps sold on the App Store" probably just means "Apple will not approve an application which uses this cable for sale on the App Store".
I wrote an app that uses this cable. You CAN distribute an app using serial communications, but ONLY with a custom cable variant created by Redpark. This custom cable will ONLY work with your app, and your app will only work with this custom cable. Apple will approve this app because Redpark has done the legwork of MFI compatibility. What the web page points to is only a "evaluation" system, not production ready.
Thanks for that information. It's hard to get any understanding of what the whole Apple developer program is regarding the dock connector. Obviously the keynote dream of "look at all the things we'll be hooking up to iPhone/iPad!" is never gonna happen.
I'm all for new ideas and tools, but you have to bring something to the table other than just being different. And just being "smaller" is not enough.
This is the problem with Padrino- it isn't different enough. We don't need a smaller MVC Ruby framework, as there isn't much space between what Sinatra is great for and what Rails is great for.
There is also an assumption that scaling Sinatra up is a good idea. I'd propose that it's likely not.
It actually turns out that being smaller can be worse if it means you're just building a half-assed implementation of something Rails 3 already does well.
There is a lot of space to cover between a bare-bones HTTP DSL (which Sinatra is) and an opinionated full-stack like Rails. For example, Padrino allows you to freely choose between a lot of Ruby ORMs _and provides support_ to use them. Try that with Rails.
As another example, Padrino allows you to do Rails-Engine-like things in a very natural way (by hosting multiple applications in one Stack etc.). It is not a Rails rehash on a different base.
The Rails 3 rewrite / MERB integration was supposed to accomplish this by allowing pluggable ORM's and different libraries. Is Padrino trying to be the new MERB? I think extending Rails to be more modular is the way to go, not more frameworks.
Can you host arbitrary Rails applications in other rails applications like you can host arbitrary Padrino applications within another Padrino application? (it should even be possible to host padrino apps in any other rack app, though I've never done that so far, it might need a little hackery)
Rails is a Rack application, so yes a Rails app could play host to more than one sub app. In fact this is such a good pattern, that Rails core added Rails Engines which do just but better.
As someone that has been writing production Rails and Sinatra apps for years, I have to recommend against using Padrino. Rails scales up and down pretty well, and I don't really see a need for Sinatra in anything but very small or single-purpose apps.
If you already know Rails, there is very little reason to build a substantial app in anything "smaller". The reality is that for any moderately-sized app, you will end up using many of the parts of Rails that you think are unnecessary in the beginning. Especially as your app grows.
I tried using Padrino for an app a year ago, and while the framework has probably matured since then, I moved back to Rails fairly quickly due do a lack of polish/documentation/community/benefit other than being different.
There is a common tendency to find a part of a framework that doesn't work exactly the way you want, and in turn throw the entire framework out and seek out or write something new. I still prefer the way Merb and Sinatra handle responses, where the controller action return value is the response sent to the client. But the benefits that Rails provides so outweigh many of these kind of preferences that it's usually best to just embrace the way the framework works and move on to actually building an app that does something.
It's also short sighted to discount how valuable the wealth of existing documentation and extentions exist for an established framework such as Rails.
The presentation makes it sounds as though by using Rails you have to use SASS and Coffeescript. This is not true, you can easily use plain JavaScript and CSS if you want.
The majority of developers will be more productive in Rails.
We're using SproutCore 1.6 and TemplateViews for a medium size app, and in many ways, it feels like the early days of any framework- there are a lot of nice features, but you have to be willing to dig into framework code and bend it to your will. SC 1.x has a lot of really great ideas, but they're buried deep in a huge system that is, in many ways, inflexible.
SC 2.0 seeks to change this, by making the framework much more modular (think Rails 3) and trying to do less. KVC/KVO really pay off on larger apps by allowing the data to drive the app instead of you having to write a lot of boilerplate code to push data and UI elements around as changes are made to the data. Statecharts are really useful for giving structure to a complex client-side codebase- I highly recommend using them.
I have only looked at Backbone briefly, so I can't comment on how it compares on a real app. But my gut is that it boils down to this: with Backbone you will be writing more framework-level and boilerplate code, which may seem more explicit, but will also be harder to maintain. With SproutCore, you will be relying on the framework to do more, but you will have to understand the framework in order to take advantage of what it offers you. And since SC 2 is still under heavy development, you should be OK with adapting to change as the framework matures.
Has the documentation situation improved much in the last year? I tinkered around with it a few times and it really felt close to being great. But... aside from the 2 or 3 intro tutorials, I found the docs really lacking. I only made actual progress by reading the framework code.
You will probably still have to look at the API docs (and read some source) from time to time, but the core team is taking documentation a lot more seriously now.
The focus of SproutCore 2.0 is building views using Handlebars and the ability to use these views and the data layer in ways that play nicely other frameworks and web technologies. The only real demo so far is the todos app: https://github.com/sproutcore/todos
At the Chicago SproutCore Meetup, Tom Dale mentioned that they are working on a new UI toolkit to take the place of the one in SproutCore 1.x. There has been no word when that will be released, but I would expect a widget demo of some kind when it is.
Oooh, fancy. I wonder why I haven't heard anything about a new UI kit for SC2 until now. Hopefully it will come with a new look, I haven't been digging Ace very much.
The pie charts don't really make any sense. For example, a single project can use Cucumber, Capybara, and RSpec, or none of them, or any combination. But in the article and its graphs they are presented as mutually exclusive options.
Separating the results into exclusive types (testing framework, browser integration framework, assertion macros, etc) would make a lot more sense. Or asking what tool is being used for a particular task (unit testing, integration testing, mocking/stubbing, assertion macros, etc).
There is already an iOS serial cable though, which I would think would be a better option for many projects:
http://redpark.com/c2db9.html