<input type=”file” >

Finally, it’s here. You can now upload photos and videos from the Photo Library using a regular input element. This was previously only possible via the use of Phonegap etc.

This is a real game changer for mobile apps.¹

Apple unveiled a lot of interesting things at the start of their WWDC this Monday. There’s been a lot of talk about new hardware, hardware that weren’t updated and new things in Mountain Lion and iOS but the fact that it seems like Safari in iOS 6 will support the <input type=”file” /> element has largely been overlooked.

I myself have a couple of ideas of apps that I’d like to build, but I don’t have the knowledge necessary to build them in Objective C and I currently don’t have the time to acquire that knowledge. I do, however, have the knowledge necessary to do those things using HTML, CSS and JavaScript with a PHP backend. The problem with this is that web apps in iOS can’t do some of the things that native apps can. For example, up until now it’s been impossible to upload pictures taken with your iPhone to your blog/web page/facebook/twitter etc. without using a natively built client.

To me, ”this changes everything”. Enabling the same (limited) access to the filesystem from web apps as from native apps is a huge boost for those of us that has an interest in web technologies. I can’t wait to try it out for real.²

A letter from Tim Cook(!) to a Mac user.

Franz,

Thanks for your email. Our Pro customers like you are really important to us. Although we didn’t have a chance to talk about a new Mac Pro at today’s event, don’t worry as we’re working on something really great for later next year. We also updated the current model today.

[…]

Tim

via Cook: Apple planning professional Mac for 2013 | Macworld.

After two years, the Mac Pro was “updated” today, sort of: now we can choose slightly faster two-year-old CPUs at the top end, and the other two-year-old CPU options are cheaper now.

[…]

The message is clear: Apple doesn’t give a shit about the Mac Pro.¹

Marco Arment is pissed.

Many Apple observers also wonder if Apple thinks that desktop computers are dead, since not a word was said about the iMac and Mac Pro. An executive did assure me, however, that new models and new designs are under way, probably for release in 2013.²

But David Pogue is reassured.

As I wrote in my Follow WWDC from a distance post, my only real wish was a new Mac Pro. I wouldn’t call the updated model ”new” in any way, but I still have faith. (And, fortunately, I’m not in pressing need for one right now.)

If you’re going, to San Francisco …

Apple’s Worldwide Developer Conference starts tomorrow. (If you don’t know what that is you’ll likely not want to read this blog posts.) A lot a people is going. I’m not one of them. I didn’t even try to get a ticket because Apple development is just an area of interest for me, it’s not by any means my job, so it’s way to expensive for me. If you’re reading this you’re likely not going either. If you are going and you’re reading this right around the time I publish it you should likely stop reading and start packing your bags.

Anyway, this post is for those of us who is not going. I just want to share a couple of, presumably. great ways for those of us who’s not there to get the best information in the most entertaining way.

The Keynote

The WWDC keynote is going to be covered absolutely everywhere since it’s partly a press event and since no NDA is applied. It will likely be available as a video download shortly after being given (usually around Tuesday morning here in Sweden). Still, most of us likely want to get the information as fast as possible.

There will likely be all kinds of live blogs and those live blogs will likely be completely flooded with traffic and down about four seconds into the keynote. The best and most reliable source of information for me will be, and has been for the last couple of years, MacWorld’s twitter account @macworld. The guys at MacWorld will be live-tweeting and their coverage is usually very good.

For personal preference and amusement I’m also following Marco Arment (@marcoarment) and John Siracusa (@siracusa).

The rest of the week

Everything after the keynote will be covered by the NDA so the participants will actually not be able to talk much about the various sessions, but I’m still planning to keep myself up to date by following a few people that will be there. After all, they can talk about everything in the keynote and a lot of stuff from it will be more or less important as the week progresses.

I’ve already mentioned Marco Arment and John Siracusa. I’ll also start following John Gruber (@gruber) and keep an extra eye on his blog, Daring Fireball.

These guys will also do there respective podcasts in a special WWDC format during the week. On tuesday both Build and Analyze and The (new) Talk Show will be broadcast and on Friday we’ll have Hypercritical.

An Apple TV SDK?

One of the many rumored announcements for the week is a developer platform for the Apple TV, with an SDK, App Store etc. Should this become true, you should definitely follow Tobias Hieta (@tobiashieta) on twitter. He is part of the Plex developer team and the man behind the current version of Plex for jailbroken Apple TVs.

My wishes

I don’t have any predictions for this years WWDC, but I do have one wish. Please, Apple, give us a new Mac Pro! That would silence a lot of the talk about how Apple is abandoning the pro market.

In issue #350 of A List Apart Jake Archibald writes a great article about the HTML AppCache. Yes, the article is long. Your reptile brain will scream

TO LONG! WATCH YOUTUBE VIDEOS INSTEAD!!

but don’t listen to it. If you do any kind of web development, you should read the article. AppCache can really be great for certain things bit, as Jake will show you, it’s so full of caveats and weird behavior that you might be discouraged from using it.

The ApplicationCache spec is like an onion: it has many many layers, and as you peel through them you’ll be reduced to tears.¹

For an older version of this blog’s theme, I tried to use AppCache to increase download speed of a few assets, fonts in particular. It turns out, ”the road to hell is paved with good intentions”. The end result was a whole lot of pain when I updated the theme and a giant bag of hurt when I tried to switch it to the one currently in use. On my computer it looked fine, but on my iPad a broken version of the old theme was still in use and no matter how many times I’d hit the ”update” button in the browser, nothing would happen.

Ever since I finally figured what caused all the pain I’ve been meaning to write a blog post about it, but I’ve kept pushing it in front of me. Archibald’s article made me sick of my own postponement, so here is the short version of why AppCache together with WordPress makes for a giant pile of hurt.²

The problem of using AppCache with WordPress

Remember Gotcha #1: When the user visits a page a second time they’ll get the ApplicationCached version. If you’ve changed the url to the manifest, bad luck, the user’s cached version still points at the old manifest, which is obviously byte-for-byte the same so nothing updates, ever.³

When you (in this case me) develop a WordPress theme, you usually put all its files in wp-content/themes/[theme_name]. Logically, this is also where you’d put the AppCache Manifest file.

THIS IS A BAD IDEA!

Sorry, I didn’t mean to scream at you, it’s just all the frustration built up inside of me from actually making this mistake.

If you put an AppCache Manifest in your regular theme folder, this is what will happen.

1. A user will visit your site. Her/his browser will see the cache manifest, download it and cache everything according to it.
2. The user makes another visit some other day. Unless the manifest file itself has changed or been deleted, nothing will happen. If it has changed or been deleted, new assets will be downloaded according to it, but they will not be displayed until the next time the user visits.

So far nothing seems problematic. However, some day you will decide to switch theme. You’re assumption will be (at least mine was) that the user will once again visit you, her/his browser will download the new theme in the background and on the next visit the new theme will be showed in all its glory. There is just on problem…

The manifest file is still present in its old location, and remains unchanged.

This means that regardless of how many times you, or the visitor, hits update in the browser, the old cached version of the blog will show up. The best solution is to delete the old theme, or at least the old themes cache manifest. That way, things will go as you originally planned; the visitors browser will stop showing the old theme on the next visit.

So as you can see, things can quickly get out of hand with AppCache. Don’t use it in your WordPress themes without thorough testing. And read the A List Apart Article.