The Dropbox API works a bit like an Amazon S3 storage bucket except that you, not the application in question, have control over your uploaded files.
The Dropbox API uses familiar tools like JSON, OAuth and OpenID, so web developers can essentially offload their user’s storage needs to Dropbox. For users, the usual risks of tying your web app to a cloud storage mechanism are mitigated by the fact that Dropbox keeps a local copy on your hard drive.
While the potential for integration with web apps is very cool — imagine if all your Flickr uploads automatically synced to the Dropbox folder on your hard drive for an instant backup — the first place you’ll likely see the Dropbox API in action is on mobile devices.
Storage limitations and, in the case of the iPhone/iPad, Apple’s imposed restrictions, mean that it’s difficult to build mobile apps that can access local files, let alone read, write and sync.
That’s the basic problem the Dropbox API seeks to overcome — using the Dropbox API means there’s no need for local files on your mobile device and everything is automatically synced back to your PC. The only catch is that you need an internet connection for the syncing to work.
Dropbox has already worked with a number of developers to integrate the new API prior to the launch. For example, Air Sharing, GoodReader and QuickOffice can now tap into your Dropbox account to edit and sync your Dropbox files. The new API ships with client libraries in Objective-C (pretty much required for the iPhone/iPad), Python, Ruby and Java. To create an application you’ll need to register with Dropbox and then, once you have access, you can grab the client library of your choice and check out the online documentation.
Want to see what your website looks like on the iPad? Get a load of iPad Peek, a new web-based emulator that shows you how any site renders on the new Apple device.
Click on the black frame above the browser to switch between landscape and portrait modes. You can also test your web forms by mouse-typing on the virtual virtual keyboard.
iPad Peek has a few limitations. There’s no touch scrolling, ads produce pop-ups, and embedded Flash videos and objects will still render inside the emulator even though the real iPad doesn’t do Flash. So, it’s basically a Webkit wrapper set to a fixed width and height. But, it does give you a pretty close approximation of how your site will look on the new shiny.
Also, Mashable has instructions for changing your Firefox user input string to that of the iPad:
Type “about:config” in the address bar, click the right mouse button, select New – String, and name it “general.useragent.override”. Then enter the value “Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10″.
And why would Apple ever ease up? The more the web relies on open technologies, the more iPad buyers will be able to do with their shiny new devices, and the more satisfied they will be.
In the two months since the iPad was announced, Apple has been waging a campaign urging web developers to stop using Adobe Flash Player and to use HTML5 for video playback instead. But while the most forward-looking developers are rushing to optimize their websites for Flash-less mobiles and tablets, many are wary of embracing open video whole hog. There’s no agreed-upon video format for HTML5, and the support varies greatly from browser to browser.
Some are going the route of falling back on Flash for any users not browsing with Safari. But that path — coding multiple versions of a website for multiple browsers — is precisely what developers have been trying to avoid for the last decade. It also opens up a can of patentlicense worms.
It’s also important to note that HTML5 isn’t just for video playback. It’s a substantial redesign of the way web pages are assembled (with an emphasis on semantic markup), and it includes various APIs for building full-blown web applications.
Not to be overly critical of Apple — anyone pushing for open web standards deserves kudos — but the company seems more deeply concerned with digging Flash’s grave than it does with promoting semantic markup. The page on Apple’s website mentions HTML5 ten times, and nine of those mentions refer explicitly to video playback.
Apple has posted some technical guides at the bottom of the page to help “ensure that your website looks and works great on the iPad.” It also has a form you can fill out to submit your site for its gallery of iPad-ready sites.
The arrival of the Apple iPad is still months away, and already the tech pundits are declaring the demise of Flash.
The view is based largely on the fact that the iPad, like the iPhone, will likely not support Adobe’s plug-in, but it’s also a result of the enthusiasm surrounding the current momentum of HTML5. The emerging web standard, which is quickly being adopted by browser manufacturers and developers, offers native video playback and animation tools that don’t require Adobe’s Flash plug-in. Google recently added its significant weight to the HTML5 camp when it announced HTML5 video support for YouTube. That Apple appears to have again shunned Flash is simply more fuel for the anti-Flash fire.
At this point, however, the demise of Flash is anything but assured. Even if it does eventually fade away, Flash will still be with us for quite some time because there’s currently nothing to replace it with.
While some proponents of the open web would have you believe that a viable replacement for Flash is already here — in the form of HTML5 –that’s not exactly the case. The HTML5 video tag does indeed allow you to embed videos in web pages without Flash, but it’s up to the browser to actually play that video. And that’s where the problem arises — what video codec should the browser use? Apple, with the iPad, iPhone and its desktop apps, is pushing the H.264 codec. But the H.264 video codec has licensing requirements and is not free in any sense of the word. Moving from the Flash plug-in to the H.264 codec is like moving backward — from Flash to a more expensive Flash.
The iPad then, even if it does hasten Flash’s demise, isn’t helping to bring about an open web, it’s just moving from one controlling body (Adobe) to another (MPEG LA, which controls the H.264 codec and is not, for the record, affiliated in any way with the MPEG standards organization). The iPad delivers Apple’s vision of the web, which currently happens to not include Flash. But the iPad isn’t some giant leap for the open web, no matter what Steve Jobs would have you believe.
Mozilla has already said that Firefox will not support H.264. Google’s Chrome browser does support H.264, but the company also recently moved to acquire On2, makers of another, competing video codec which means, if nothing else, Google isn’t completely satisfied with H.264 either.
Ogg Theora, which Mozilla has elected to support, is an alternative set of video codecs which might overcome some of the problems with H.264. But while Ogg is open source and free, there is some possibility that elements of it may be encumbered by patents. Apple has long cited these so-called “submarine patent” concerns among its reasons for not supporting Ogg. Critics dismiss these fears as misplaced. However, part of the reason Google acquired On2 may be to obtain these potential patents, and what Google does with them when the sale is completed — keep them or release them under an open source license — will have a significant impact on Ogg’s future.
So there’s no agreement on an open web video codec yet. This means no matter which option you chose — HTML5 with H.264 or HTML5 with Ogg Theora — the best case scenario is that 20 to 25 percent of the web sees your video without needing a plug-in.
Obviously that’s not ideal.
Adobe likes to say that if you use Flash, around 99 percent of the web will see your video. But throw in the iPhone, the iPad and other mobile devices without Flash capability and that number drops significantly. But even if Adobe’s penetration is lower than it claims, Flash still has a much deeper reach than any of the myriad other options.
So which option are developers going to chose?
Well, smart developers are going to chose all of the above. And indeed, they already have. YouTube has not abandoned Flash. The site is offering both Flash and H.264 video. We expect YouTube will add even more file formats to the mix before it’s done.
So if Flash’s dominance is slipping, then eventually it will just disappear right? Sure, just like IE 6 disappeared quickly as soon as something better showed up?
Flash isn’t going to disappear overnight, and probably won’t even fade significantly any time soon. Dion Almaer, who works at Mozilla and is editor of Ajaxian.com, put it best when he wrote about this in a blog post Monday:
HTML5 is slowly going to put a dent into [Flash] if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship… There is still much more work to be done. Flash and browser plug-ins have had a long history at forging new paths, and the web can come in behind them and standardize.
Flash will continue to exist because for many it will continue to be the best tool for the job. And let us not forget that while Flash has its problems — namely performance — it’s also been an incredible innovator for the web. All that Ajax and amazing desktop-like stuff we all love about today’s web? Many of the tools used create those interfaces were written specifically to catch up with Flash.
Instead of dancing prematurely on Flash’s grave, we ought to be hoping Adobe can turn it around and release something so innovative, so fast, so amazing — and so open — that even Steve Jobs has to smile.
Update 02-02-10: Adobe CTO Kevin Lynch weighed in on the debate over Flash and HTML5 video on the web in a blog post Tuesday morning. He expresses many of the same concerns about support and user experience inconsistencies across browsers, and offers comments about Flash’s ongoing future as a development environment.
In response to Apple’s iPad product announcement Wednesday, Adobe has posted a message to its Flash Platform blog assuring developers they’ll be able to use Adobe’s Flash authoring tools to build iPad apps.
Developers are currently able to publish almost any project built using ActionScript 3 into a native iPhone or iPod Touch application using a cross-compiler called Packager for iPhone. Adobe is tweaking Packager for iPhone, which will ship as part of Flash Professional Creative Suite 5, to work with the iPad SDK and support behaviors specific to the new device.
The biggest change is the difference in screen size. Adobe says it will first concentrate on getting ActionScript 3 apps to translate to the iPad properly, then build in support for the device’s larger screen size.
Keep in mind, this does not mean that Flash apps, AIR apps or the Flash Player are going to work on the iPad. There seems to be some confusion about this — probably because Adobe’s communications are purposely vague about this fact, and bloggers are unclear as to what Packager for iPhone actually does. When you export a Flash app to the iPhone, you’re not getting a Flash app, you’re getting an app that was built in Adobe’s ActionScript 3 programming language using the Flash authoring tool, then translated into iPhone-native code.
Flash and AIR apps don’t work on the iPhone or the iPod Touch and they won’t work on the iPad. Apple’s mobiles currently use hardware-embedded decoders to render YouTube videos, but we can expect that scenario to change soon, now that YouTube is moving towards HTML5 video playback using h.264, which Apple devices use as their native video codec.
In fact, during Steve Jobs’ announcement Wednesday morning, many attendees (including our own Gadget Lab team) noticed when a “plug-in missing” icon popped up on the New York Times homepage as Jobs was demonstrating the iPad’s Safari web browser.
Adobe was going to release a full beta of Flash Professional CS5, but the company decided against it so it could get the final app out more quickly.