SproutCore 1.0: Platforms
Mobile is a really interesting area for any web developer. With the iPhone and Android, there are finally phones with serious browsers that can run actual app-like code. Very exciting.
Of course, developing an application for a phone has its own unique limitations. Bandwidth is an issue of course. As is memory constraints and the UI has to look completely different.
Nevertheless, I believe that the thick-client model that SproutCore is based upon holds great promise for the phone. Precisely because of the bandwidth constrained, memory limited environment, downloading and installing code that runs right in the web browser can produce a dramatically better experience than forcing the user to wait on regular HTTP or even Ajax requests to complete. All you need is the framework.
SproutCore was originally designed for desktop applications, where you can potentially display large amounts of data. Neither the UI controls nor some of the large-data technologies we use on the desktop make sense on the phone. This is why we are working on creating a mobile version of the framework.
Starting with SproutCore 1.0, you will have a few new options in the SproutCore build tools to let you output a version of your application just for the mobile phone. Rather than force you to create an entirely new app for mobile devices, SproutCore treats platforms a bit like creating multiple languages. That is, you simply add a “foo.platform” folder to your project. Anything you place in that folder will only be included in the build for that platform.
For example, let’s say you were designing a Contacts application. You might create some models and controllers for your app. These will live in the models and controllers folder just like before. But now you could also create a “desktop.platform” folder and a “mobile.platform” folder. Inside of these folders, you can add the views and view-level resources needed to build the unique UI for that platform. Here is how that folder structure would look:
contacts
core.js <-- namespace
models/
contact.js <-- Contact model object
controllers/
master.js <-- typical controllers
detail.js
desktop.platform <-- for the desktop browsers
main.js <-- this main() is run when loading the app in the desktop
english.lproj
body.rhtml <-- view helpers for desktop
mobile.platform <-- for the mobile browsers
main.js <-- this main() is run when loading the app on the phone
english.lproj
body.rhtml <-- view helpers for mobile
When you run a build, SproutCore will output both the desktop and mobile directories in your bundles. Once your app is deployed, you can visit your two apps by going to either:
| Desktop: | http://www.example.com/contacts/en/desktop |
| Mobile: | http://www.example.com/contacts/en/mobile |
There is also a facility to add auto-detection code at the top of your template page so you can redirect to the correct version of your app whenever a user visits your app’s main URL.
Of course, this means that the SproutCore JavaScript itself will also come in desktop and mobile flavors. More on that as it develops.
This new feature in the build tools is still fairly primitive. I’m sure we’ll be adding many more features to it once we get into your hands, but in general this opens up a new and very exciting area for SproutCore. I can’t wait to see what you all do with it!
This looks promising, though I wonder how much actual shared front-end code a desktop app would have with it’s mobile counterpart — while the back-ends might be the same, I think even the server and model code of a mobile app would only need a subset of it’s desktop sibling.
Perhaps if there were some pre-compilation that could strip out unused functions from a particular platform’s build output could mitigate this, otherwise I think there’s going to be a lot of duplicated, platform-specific code required to avoid overhead.
On a related note, I thought the post-mortem Ross Harmes wrote on developing the flickr mobile site was insightful and instructive:
http://code.flickr.com/blog/2008/10/27/lessons-learned-while-building-an-iphone-site/
Notwithstanding his first recommendation (”Don’t Use a JavaScript Library or CSS Framework”), I think there’s definitely some lessons that could be applied to SC Mobile to provide a powerful end-user (as well as developer) experience.
One thing that caught my eye, “On the iPhone, for instance, only files smaller than 25 KB are cached.”
This might suggest a slightly different methodology for delivering resources beyond the front-load approach in use by SC today.
Anyway, just some thoughts — keep up the good work!
> I wonder how much actual shared front-end code a desktop app would have with it’s mobile counterpart
If they are too different you can always create two separate apps. One mobile + one desktop. Though I think being able to maintain even my core models in the same place is really helpful. The cool thing about JS is that you can build a class in pieces. So you could define your common model class, then add in extra methods for the desktop. This is how I am refactoring SproutCore right now. It allows me to have a common class hierarchy, even if most of the implementations end up in platform-specific code.
Thanks also for the pointer to that article. It’s very interesting. I wasn’t aware of the 25K limit. That does argue for having a way to split out modules.