As a user I've long been annoyed by the current Facebook iOS App (especially on my original-model iPad.) As a developer I've also been disappointed by what a poor example of an HTML-based mobile app Facebook has provided. Hacker News has a post today which links an article called Here’s why the Facebook iOS app is so bad that explains why.
Among other interesting commentary on the Hacker News post, is a link to an article by LinkedIn about LinkedIn for iPad, that provides some details about their architecture. If you haven't tried the LinkedIn app, it's worth looking at -- if only to cure the feeling of sadness you get from the Facebook App.
2012-03-08
The Bootstrap Revolution
Twitter's Bootstrap CSS framework has been wildly successful. I am using it on some (behind-the-firewall, unfortunately) consulting projects and am very happy with it.
Like anything else successful in tech, it has its detractors, but I'm truly surprised by the lack of substantial criticism. The biggest complaint, which I've made myself and have cautioned clients about, is that if you're not careful your site will end up looking too much like all the other Bootstrap sites that are out there. This problem occurs if you don't take the time to customize Bootstrap -- something that is relatively easy to do with a little tinkering with LESS.
In Why Bootstrap might be very important Dave Winer argues that this apparent drawback is actually a good thing and draws a comparison between Bootstrap and the original Macintosh Toolbox. In short, he's reminding us that UI standardization is beneficial. Read the whole (short) thing and skim the Hacker News discussion it spawned and draw your own conclusions.
Another valid complaint is that sites that use Bootstrap don't completely separate content from presentation in part because key Bootstrap CSS classnames describe layout, not content. In practice this is only a minor issue and is probably unavoidable with a CSS framework, but it might upset a Semantic Web pilkunnussija.
Bootstrap (and LESS) have changed my perspective on front-end development. I'd like to apply some of the lessons learned to the iUI Framework, but that's a subject for another time.
Like anything else successful in tech, it has its detractors, but I'm truly surprised by the lack of substantial criticism. The biggest complaint, which I've made myself and have cautioned clients about, is that if you're not careful your site will end up looking too much like all the other Bootstrap sites that are out there. This problem occurs if you don't take the time to customize Bootstrap -- something that is relatively easy to do with a little tinkering with LESS.
In Why Bootstrap might be very important Dave Winer argues that this apparent drawback is actually a good thing and draws a comparison between Bootstrap and the original Macintosh Toolbox. In short, he's reminding us that UI standardization is beneficial. Read the whole (short) thing and skim the Hacker News discussion it spawned and draw your own conclusions.
Another valid complaint is that sites that use Bootstrap don't completely separate content from presentation in part because key Bootstrap CSS classnames describe layout, not content. In practice this is only a minor issue and is probably unavoidable with a CSS framework, but it might upset a Semantic Web pilkunnussija.
Bootstrap (and LESS) have changed my perspective on front-end development. I'd like to apply some of the lessons learned to the iUI Framework, but that's a subject for another time.
2012-01-06
Grails Ajax Proxy Plugin
The Grails Ajax Proxy Plugin is now on GitHub.
Over 2 years ago I asked on the grails-user list if there was a Proxy Plugin available for Grails that was suitable for Ajax apps to work around the same origin policy. I was told that nothing was available, so with a tip from Matt Raible's blog, I quickly wrote one using the proxy servlet from EdwardsTx.net. It worked for my needs at the time, but nobody on the list had expressed much interest in it and I had a bad experience trying to publish an update to the Grails iUI Plugin, so I gave up.
Over 2 years ago I asked on the grails-user list if there was a Proxy Plugin available for Grails that was suitable for Ajax apps to work around the same origin policy. I was told that nothing was available, so with a tip from Matt Raible's blog, I quickly wrote one using the proxy servlet from EdwardsTx.net. It worked for my needs at the time, but nobody on the list had expressed much interest in it and I had a bad experience trying to publish an update to the Grails iUI Plugin, so I gave up.
Recently, I needed the plugin on another project, so I told my client that I'd put the source on GitHub in case they ever needed to modify it. This week, I mentioned it on the grails-user list and on Twitter and Burt Beckwith submitted a pull request that cleans things up quite a bit. He also changed the name to Grails Ajax Proxy Plugin. (I renamed the GitHub repo accordingly and GitHub doesn't provide forwarding -- so if you get a 404 looking for it you're using the old URL.)
With Burt's help, we may even get it published into the Grails Plugins Portal.
(It's enough to make me consider updating the Grails iUI plugin after we release version 0.4...)
2010-04-13
iUI and mobile HTML5 at iPadDevCamp
iPadDevCamp is this weekend. (It is produced by the wonderful iPhoneDevCamp team.) It is at eBay in San Jose, CA but there are some satellite locations as well. I went to iPhoneDevCamp in 2008 and 2009 and highly recommend it to both Cocoa and Web developers. I've been talking to a few folks about adapting iUI for creating iPad (or iPad-like) webapps similar to what Apple is doing in AdLib. Any takers?
We will be entering 'iuiPad' in the Hackathon. (Someone will need to volunteer to do the demo, because I will not be there on Sunday.) Of course, anyone will be welcome to contribute to the project, whether they attend iPadDevCamp or not.
If you're interested in contributing to this project, please do one or more of the following:
- Register for iPadDevCamp
- Follow #iuipad on Twitter
- Join the iui-developers Google Group
- Check the iUI project site (we've added a wiki page and will be updating it shortly)
Comments welcome...
2010-04-11
TXJS: JavaScript conference in Austin, Texas
TXJS is a full-day conference in Austin, Texas, featuring some of the best minds in JavaScript.
They just added more spots, so I signed up. I'm looking forward to visiting Austin again.
2009-11-23
Storing Persistent Data in Hybrid iPhone Webapps
I'm in the process of adding some persistence to a hybrid iPhone webapp. It looks like I'll be using the HTML5 Web Storage capability. I googled around and didn't find any comparisons of the alternatives or suggested best practices. Apple has a document called Safari Client-Side Storage and Offline Applications, which covers Key-Value storage and the JavaScript Database -- but makes no mention of hybrid applications.
It seems there are four possible options:
It seems there are four possible options:
- Web Database
- Key-value storage
- Cookies
- Use a JavaScript to Cocoa bridge to access native persistence
I've given a little thought to the advantages and disadvantages of each (enough to decide to give HTML 5 Web storage a try.) I'll update this document if I get any good feedback.
Web Database
Web Database
Advantages
- Can be used in hybrid, online and offline webapps.
- Supported in iPhone OS 2.0 and later.
- SQL is familiar and powerful for those who know it and need it.
Disadvantages
- Use of SQL is overkill for simple persistence
Key-value Storage
Advantages
- Simple conceptual model than SQL
- Has both "session"and "local" modes
Disadvantages
- Only supported in iPhone 3.0 and later (although Apple isn't very clear on this)
Cookies
Advantages
- Tried and true web technology
Disadvantages
- Either not supported in Hybrid mode or requires extra Cocoa code to support. (Does anybody have a definitive answer, details, or an example?)
- Extra data is transmitted to the server on each request
- Others?
Custom JavaScript to Cocoa Bridge Option
Advantages
- You can use any iPhone native mechanism for persistence
Disadvantages
- Requires custom Cocoa code
- JavaScript to Cocoa bridge options are fairly clunky
- Will not work for pure online/offline webapp
2009-11-10
Issues in Serving iUI Sample Apps using Mercurial
Since Google Code does not provide general-purpose web hosting to projects, iUI has long used the SVN repository as an HTTP server to server the sample webapps. For example the URL http://iui.googlecode.com/svn/tags/REL-0.30/samples/music.html serves the Music Sample from the 0.30 release of iUI. We had been using the tag REL-current to always server the latest stable release. We can't (easily) do this with Mercurial because the tag is passed in the query string. The URL http://iui.googlecode.com/hg/samples/music.html?r=REL-current will serve the HTML for the version tagged 'REL-current, but will then try to pull iui.css and iui.js from the 'tip' (at the time of writing, iui.css and iui.js are in a different directory on the 'tip' then they are in REL-current, so the files are not even found. If they hadn't been moved, then the wrong versions would be pulled.)
I'm not sure there is an easy solution to this problem, but if anyone has any ideas, please let me know.
Since we are now deploying the samples to Google App Engine (at http://iui-js.appspot.com), we'll have to have a 'tip' version and a 'REL-current' version on AppEngine, as well. Google App Engine does support deploying multiple versions of a webapp, but I think this is only intended for fallback purposes and not designed for serving multiple versions simultaneously. The other advantage to using AppEngine, of course, is that the dynamic pages used in the Samples and Tests will actually work.
I'm not sure there is an easy solution to this problem, but if anyone has any ideas, please let me know.
Since we are now deploying the samples to Google App Engine (at http://iui-js.appspot.com), we'll have to have a 'tip' version and a 'REL-current' version on AppEngine, as well. Google App Engine does support deploying multiple versions of a webapp, but I think this is only intended for fallback purposes and not designed for serving multiple versions simultaneously. The other advantage to using AppEngine, of course, is that the dynamic pages used in the Samples and Tests will actually work.
Subscribe to:
Posts (Atom)
