I originally put this together as a way to show my mom my Instagram photos without UI clutter or other things that might confuse her. I found browsing tags and locations in this format so fun that I decided to build a bit more functionality around it, while still attempting to keep things simple.
I'm trying to do just that with a project I started a few days ago called Khaki. It's a bit of a learning exercise and quite early, but you might find it useful in a month or two.
The new LinkedIn and OkCupid apps are primarily HTML5 based. Not quite the same, but every new release of the Facebook app seems to have more of its existing views replaced by HTML5 counterparts.
I'm fairly certain that the Facebook iPhone app does not UIWebViews to render anything. Their fast-scrolling tableviews are painstakingly crafted from scratch, natively, and (I believe) still use Joe Hewitt's framework for complex view rendering. I know some guys on the Facebook iPhone app team and they're die-hard Cocoa developers, I can't see them ever saying "screw it" and using a UIWebView with HTML.
Hm. How do you handle progressive loading? Do you even bother, or do you just load up the entire news feed and let the WebKit struggle with keeping images in-ram/in-cache etc?
I just watched this video (http://gigaom.com/2011/09/27/facebook-mobilize-2011/) where Facebook's head of mobile product talks (a tiny bit) about using HTML5 in their mobile products instead of all native development to keep pace with launches on the Facebook desktop site.
It took m a few seconds to realize what is wrong with "HTML5 fist of rage" logo in the article. The fist has 6 fingers. To be fair the original HTML5 logo isn't that much better...
not magic, TechCrunch and other blogs have been talking about Project Spartan for months. The screen shots were leaked yesterday, which is news worthy...unlike our comments.
Go to your profile and swipe left on a wall post and observe the "Remove" button and its animation. Now go to the bottom of your wall, and tap on the "See more posts..." cell. Notice that the activity indicator is an animated GIF. Open the app frequently and you'll see certain elements in the UI automatically changing without downloading an update. Or check out m.facebook.com and play around with the news feed that is identical to the one in the iPhone app.
Granted, there are other approaches you can take to get this behavior, but I'm not sure why you would. My impression is that they're using HTML5 in these areas.
I stand corrected! I got confirmation from both Joe Hewitt and JazzyChad that they are indeed webviews used in many places now instead of native tableviews. Disregard everything I said :)
Hmm, they're not using the native UITableView animation for editing, but that doesn't mean it's HTML. It's just clunky animation, mostly because each cell is doing a lot of drawing translation due to it all being three20. Also, the "see more posts" cell at the bottom is a TTTableMoreButtonCell (https://github.com/facebook/three20/blob/master/src/Three20U...) I believe.
I know that Facebook is very pro-HTML5 but I don't think there are any views in the native iPhone app that are not native UIKit or based on three20. I'll ask around, would be nice to now if there's any shared code at all on their end.
It is easy to get fast scrolling pseudo-UITableViews using UIWebViews, as long as 1) the tables aren't /that/ long, 2) you change the grid size to something larger than default (to avoid checker-boarding), and 3) you decrease the deceleration constant to match those of normal tables. (Note: I know this from experience with a very widely deployed application: Cydia.)
And I uninstalled the OKC app within a week of them making the switch. Changing it to every action being roundtrip-based made it unusably slow. A total misstep, if you ask me.
TileMill doesn't seem particularly well suited for that either. I did a rough calculation and it looks like getting a usable map of Washington D.C. would run several hundred gigabytes. I'm wondering if the only way to do something like this realistically on a mobile device is to move the rendering to the client.
The first is 17MB, the second is 57MB. One could probably get to sidewalk-level without cracking 1GB here. Where did hundreds of gigabytes come from?
That said - we'd like to start doing rendering on-client, and it would be great - the question is how to slice and dice data so that the data itself isn't gigantic and rendering it isn't slow.
I probably made a mistake when estimating this. I exported 21 tiles to MBTiles at 429KB, and extrapolated based on the 5.7 billion tiles it would take to do D.C. at 13-16.
I'm still waiting for a larger job to complete, so I don't have a sense of the file size there.
Edit: Got it. The default export is the entire world. Whoops.
Though perhaps not optimized for an urban solution like DC, we have done work around tile de-duping and tile data compression to combat things like this.
Really incredible work. Is there anything we can do to speed up exporting, short of manually parallelizing across multiple computers? Distributed export might be a nice feature.
When I first started using tilemill, I missed that you can create indexes for shapefiles. This turned a 12 hour render into a 15 minute render for my particular use case. The devseed guys show how to do it here : http://developmentseed.org/blog/2011/mar/29/speed-optimizati...
Mac(Book)s (and Macs with the magic apple mouse) have two finger scroll which is the same thing, but isn't supported (but should be, please!) on say the headline box in the Skimmer "Spread" layout.
They are almost the same thing. They perform the same function but because they are physical invisible they are even less likely to be used by an average computer user.
I have some anecdotal evidence on the contrary. My wife is a very casual computer user, but uses two-finger scroll all the time. My sister-in-law is very similar - not a computer person, but has an Apple laptop and uses two-finger scroll. Also, Apple mice support scrolling[1], and almost any third-party mouse you buy will have a scroll button as well. Scrolling with a mouse or trackpad seems like an integral part of user interaction.
And every Mac user I know is well aware that for the web, <space> scrolls a page forward, <shift-space> a page back. So still no good argument for on-page controls.
