Good stuff. Can't wait for the android version. One more thing, I just spent 15 minutes figuring out how to change a co-worker's profile pic in the new app. I fear that simple use cases are becoming complicated.
If you go into IOS Settings and then click Facebook > About you can see all of the open source components that they use (An enormous amount). It has everything from AQGridView to Boost to Chromium (what?) to PHP (again, huh?).
Since Facebook is a big PHP shop, it could be that they have some standard libraries where they prefer to use PHP's version as the canonical implementation. Then they port these to various languages. In some licensing interpretations, this would bind them to the license of the original code.
Definitely aware, just normally accustomed to license credits meaning "we used this in source code/binary form in our distributable app." I missed the fact that it was referring to the Base64 encoder/decoder which makes more sense.
Facebook is a pretty huge contributor to open source. The Three20 framework that they made which powered their original iPhone app was open source and used by tons of developers.
I wonder if they are done or are they going to still work on making it faster. Responsiveness when viewing your own profile is still atrocious on an iPhone 4.
I think that staying HTML 5 is a mistake. As the needs of your app expand, there will be a greater and greater need to use native API's. The longer you develop in HTML 5 the more code you will have to port when you finally do decide to transition to native. You're better off minimizing your pain and transition to native early when there is less code to port.
I don't know enough about their app to give a detailed response, but it seems like the optimizations they performed could have just as well been applied to their HTML5 version. WebWorkers, for example, are available on iOS.
It could be that they could never get true native speed without writing it natively. However, in my experience their HTML version was so awful that I suspect a lot of it was from bad decisions on how to use HTML5. That may be the problem though: that it takes deep knowledge to know how to leverage it correctly and speedily.
If a company has the resources to support native development, I think there's no reason to stick with an hybrid HTML5 app. It's well-known that (because of security reasons) JavaScript is slow in a UIWebView compared to a real website, see: http://blog.mobtest.com/2012/05/heres-why-the-facebook-ios-a...
Yea, I call complete B.S. Look how well the LinkedIn app performs. It's not as good as it could have been if it was 100% native, but it's no where near the bag of rocks the FB app was. I work on native iOS and HTML5 apps every day, HTML5 isn't close to native, but you can still get it to perform damn well enough. FB had no excuse for that shit they released, they should have held onto Joe Hewitt to fix it. (I don't know what the inside story was though).
I read the story on FB newsroom. I see that site is built on OLD asp.net webforms. Not even asp.net MVC. If their devs are constantly using the oldest of tech to create their site, it's no wonder their shit performs so badly.
Now I have no idea or backstory to why they choose these routes, they most probably simply didn't have any developers with enough experience or skill set to use newer better performing tech (I hear it's hard to find good developers).
The press room site is not their main site, and I believe is not even run by Facebook. Many companies outsource their investor relations and press websites. None of Facebook's primary site is running ASP or anything Windows-related (they use PHP). It's pretty safe to say that none of the people developing Facebook's main site, services and mobile apps are behind the press site...
Facebook develops their main site in PHP. They even wrote their own PHP compiler[1], and various other pieces of infrastructure (e.g. [2]). I'm not a huge fan of PHP, but compared to other PHP projects I've worked on their infrastructure looks nice and modern.
I read a venturebeat article on the LinkedIn app, seems like they used some Node.js, a bunch of work arounds and A LOT of domain expertise to get it to work as well as it does. I personally found the article interesting as I'm trying to figure out native vs. HTML5. seems like, barring incredible expertise about the quirks of html/js, native is the way to go.
I think that Facebook has enough resources that they should go native. But I also don't think that HTML5 is as bad as Facebook has made it look (having made an HTML5-native hybrid app myself), and I think it's still a valid choice for smaller outfits.
That said, my greater concern isn't performance on HTML5, it's interface. iOS, Android and (particularly) Windows Phone have very defined UI metaphors and design styles that vary a lot- if you have to replicate all of them then it removes a great deal of the benefit of a cross-platform app.
The answer may be, weirdly, in C#, using MonoTouch and MonoDroid. You'll always have to tailor UI to each OS, but having an entirely consistent backend to that UI is an attractive option. I just haven't managed to convince myself to drop the cash on a license yet, though.
What a strange article. I'm not sure who this is written for. There's no real details about anything technically interesting that they did other than including the whole messages app codebase in the new app. But explaining how their objects share protocols? Listing some data that they precalculated and the methods it saves them time in? This stuff is obvious to any current ios dev and useless to anyone who isn't an ios dev.
Wha? The UI needs to keep processing events to remain responsive. If you have a long-running (relatively speaking, say 10 milliseconds) process like uncompressing an image, you don't want your UI to lag for that long.
You could have the image decompressor look up every millisecond or so to see if there are any UI events to process, but that leads to the sort of spaghetti code that multithreading/multitasking was built to address.
not sure if you're an obj-c dev but for me the surprise was that it even needed to be mentioned since it's extremely easy and common place to do processing outside of the main thread in current apps.
I'm impressed with how quickly FB, able to transition from emphasizing their web experience, to emphasizing their mobile experience. Most established web companies are moving much slower on this (ie Microsoft, Google, Yahoo!, Amazon, eBay, Flickr, Yelp, Craigslist, Tumblr, etc...).
Meanwhile FB Android app is still unusably slow and bug-ridden. It's just not acceptable for someone who wants be perceived as a strong technology company.
prior to this FB update, I'd argue that the Google+ app was one of the best iOS apps. It's both responsive and intuitive, and they've put mobile first in their mobile UI design, rather than trying to simply mirror the desktop UI.
Who voted this advertisement up, I wonder? Fuck you Facebook. I'm never signing back up, your site is harmful to people, everyone who works there can go to hell.
I'm fully willing to say that to their face though. If I made a dumb website that accidentally caused even one divorce I'd shutter it, Facebook must cause hundreds every year. It created, intentionally or not, a culture of bragging and narcissism. They're stockpiling facial recognition data. It's a terrible company. If you work there, Fuck You. You're a bad person. I don't know how else to say it.
Running a block async on the main thread can still hurt UI performance. Having worked on an app that deals with a lot of image downloading and processing, we needed to use a different runloop for downloading, and background operations to do image resizing and caching.
Between blocks and NSOperationQueue this all feels pretty natural in iOS development. You're not explicitly managing thread creation, etc.
The blocks themselves don't, no, they're just anonymous functions.
I'd hope NSOperationQueue[0] and maybe GCD composes most of what they mean by "use background threads".
And as sandyarmstrong notes, using things like operation queues will still impact your performances more than separate threads, as the main thread's runloop will still have to go through them, stuff like that.
[0] Which can take a block if an NSOperation is too much overhead for the work, see addOperationWithBlock:
pretty much every iOS app uses multi-threading (if they don't they should). GDC makes it pretty easy to implement, its defiantly not over-engineering. I highly recommend any new iOS programer to learn GDC when building their first app.
I know we're all interested in the content, but that is a seriously bad reading experience. Just because the content is technical doesn't mean the font size has to be tiny and the line height squashed. It's way too dense.
66 comments
[ 3.8 ms ] story [ 115 ms ] threadWere you not aware that Facebook is a PHP shop? Or are you just questioning its inclusion in the app's credits?
https://gist.github.com/3441055
Appirater AQGridView AutoHyperlinks Boost Chromium CocoaLumberjack CoreTextHyperlinkView EGODatabase EGOTableViewPullRefresh HPGrowingTextView jQuery JSONKit libphonenumber mosquitto OpenUDID PLCrashReporter protobuf QSUtilities Google Toolbox for the Mac Base64 library from PHP re2 SDWebImage UIImage+Alpha UIImage+Resize UIImage+RoundedCorner
They have a ton of repos on their github https://github.com/facebook
Who here thinks that Facebook should have stayed with HTML 5?
It could be that they could never get true native speed without writing it natively. However, in my experience their HTML version was so awful that I suspect a lot of it was from bad decisions on how to use HTML5. That may be the problem though: that it takes deep knowledge to know how to leverage it correctly and speedily.
I read the story on FB newsroom. I see that site is built on OLD asp.net webforms. Not even asp.net MVC. If their devs are constantly using the oldest of tech to create their site, it's no wonder their shit performs so badly.
Now I have no idea or backstory to why they choose these routes, they most probably simply didn't have any developers with enough experience or skill set to use newer better performing tech (I hear it's hard to find good developers).
[1]: https://github.com/facebook/hiphop-php
[2]: https://github.com/facebook/xhp
Do you work on an HTML5 cross platform app everyday like FB engineers did? Guess what. That's when shit gets really tricky and hard.
That said, my greater concern isn't performance on HTML5, it's interface. iOS, Android and (particularly) Windows Phone have very defined UI metaphors and design styles that vary a lot- if you have to replicate all of them then it removes a great deal of the benefit of a cross-platform app.
The answer may be, weirdly, in C#, using MonoTouch and MonoDroid. You'll always have to tailor UI to each OS, but having an entirely consistent backend to that UI is an attractive option. I just haven't managed to convince myself to drop the cash on a license yet, though.
You could have the image decompressor look up every millisecond or so to see if there are any UI events to process, but that leads to the sort of spaghetti code that multithreading/multitasking was built to address.
I still can't send messages with return, though, which is a huge pain in the ass.
Still waiting for the Sparrow rebranded Gmail app for iOS
> While we’ll be working on new things at Google, we will continue to make Sparrow available and provide support for our users.
http://sprw.me/
Maybe I was to brief on my reply, but... What I mean, was more of the know-how generated on Sparrow making its way in to Gmail app.
http://ycombinator.com/newsguidelines.html
It's also that link in the footer called "Guidelines". Read them.
Consider not.
Between blocks and NSOperationQueue this all feels pretty natural in iOS development. You're not explicitly managing thread creation, etc.
The blocks themselves don't, no, they're just anonymous functions.
I'd hope NSOperationQueue[0] and maybe GCD composes most of what they mean by "use background threads".
And as sandyarmstrong notes, using things like operation queues will still impact your performances more than separate threads, as the main thread's runloop will still have to go through them, stuff like that.
[0] Which can take a block if an NSOperation is too much overhead for the work, see addOperationWithBlock:
That doesn't seem to be the case, I have no facebook account and I got in just fine.