rizwan

I attended SIGGRAPH 2005, and there was a group in the booths that had some headset you would put on that would alter your balance to make you walk in different directions. They had a video playing if someone walking with this device and blind folds on, and someone with a joystick could turn them left and right.

Looked it up and it appears to be a similar type of technology: Galvanic Vestibular Stimulation:

https://dl.acm.org/citation.cfm?id=1187315

A while back they added it again, so you can use + in your searches now.

If what you do doesn't make an impact for customers and/or other teams in the organization, was it really worth doing?

The problem is that, at review time at Google, you have to be able to "quantify" the impact. Many types of impact are quantifiable (e.g. "Made server request scale from 100 query-per-second to 1,300 qps", "reduced code size by 30%", etc.).

It's much harder to measure, say, the impact of a refactor where you made the code easier to reason about and more maintainable, so that future work can be done on it more easily.

I witnessed the same thing at Google; I worked on a project that everyone joked only existed because the person who wrote it wanted promo, and the best way to get it was to design a very complex system, and convince others to adopt it. (He did get it, and promptly switched teams.)

Some things have been made better, though. I've heard that going from L4 → L5 now involves much more influence from your manager, since they would know and, without quantifying something like a refactor, can speak to the positive impact you had in a project.

In the context of sales, you can have a conversation about perseverance and not taking no for an answer. However:

At the end of that example, Brandon laughed and said, “I was about to say something.” He paused, and then went on to say, “No doesn’t necessarily mean no.”

Brandon _changed_ the context into something offensive and then made the joke. This was an attempt at rape joke. He even prepped the audience for it by laughing and saying, "I wasn't going to say this, but..."

Glad it's here, so I no longer have to Airplay from an iOS device. But can we talk about the UI? It seems Amazon's dumped an entire web renderer into the app (https://twitter.com/stroughtonsmith/status/93857361817446400...), and loading their "smart" TV UI.

It ignores the tvOS human interface guidelines (https://developer.apple.com/tvos/human-interface-guidelines/...), discarding all the accessibility features and the focus model.

I get that, to Amazon, the Prime Video app on Apple TV is probably not worth spending any time and effort on. But it's unfortunate for those of us that are paying the strategy tax and getting a "smart" tv app designed for low-powered CPUs.

AIM did go mobile. It was in the iPhone App Store on day 1. Push notifications didn’t even exist back then. When push notifications were announced by Apple in June 2009 as part of iPhone OS 3.0, AIM was the “partner” they used to load-test it during WWDC.

Source: I worked on AIM for iPhone.

IMO AIM struggled because: - it was a highly tuned, specialized C backend, and it never migrated to something that could be improved easily. - backend technical challenges (as well as legal issues) made storing chat history very difficult - Hardly any info was collected about AIM screennames, so it was hard to build a social graph from it - AIM registration was the same as AOL signup, and that registration process was very cumbersome, imo. - Most AIM accounts had no email address associated with them, so it was impossible to do password resets, for all the locked up AIM screennames.

As a client developer on AIM, it was hard to make a material improvement to AIM, though we certainly did try

I get the meaning of the "Cobra Effect", but I'm not understanding it here w.r.t. disabling paste on password fields.

I think the way they framed The Offer is a good one. He makes it clear that he wants you to stay if you want to stay, and is giving you a way out if you're not passionate or happy in your job anymore.

Many years ago they did that at AOL (a voluntary severance package), and IIRC I don't think it came across as that sincere.

To further expand on Apple's recommendation to not make Swift libraries just yet — It's also an matter of compatibility. You could certainly make a Swift framework, but given that Swift as a language is changing every 6 months or so right now, it doesn't make sense to make a framework using Swift.

You could easily hold up another project if you haven't changed your Swift code to the latest, or the opposite is true as well: Your Swift framework is up-to-date with the latest language, but the app using your framework is not, etc.

In addition to some constraints on the type of product (i.e. watch apps have to be focused, super-quick interactions), there's another reason we haven't seen a lot of app, imo:

This year was an unusually crazy year for iOS developers. Apple released: - watchOS 1, with a slow and clunky experience - iOS 9, with adaptive multitasking - watchOS 2, requiring a rewrite of the watch app – tvOS, a whole new platform, with more easily translatable app experiences.

Additionally, with the "2-versions behind" strategy for Xcode, a lot of app developers (myself included) dropped iOS 7 support. This was actually one of the most complex transitions ever. (So many backwards incompatible changes (size classes, presentation controllers, push notifications).)

So something had to give. For me, and for many others, I'd say it was probably the watch.

Choose whatever works for you. Interface Builder can save you so much time building some of the smaller aspects of your app (help/about screens) etc. that it's foolish in my opinion to just "do away" with IB on principle.

Sure, if you have 1 storyboard for your entire app, and 9 people are working on it, you will have collisions. 9 people on an iOS project is bound to have merge conflicts in code too, unless it's coordinated.

Xcode 7's storyboard references should help avoid some conflicts here, as it breaks up a single, conflict-magnet file into several. Hell, you can organize them like XIB files before Apple started pushing the 1 storyboard "simple" approach to ease the learning curve.

Side note: The title of this post should have been "Reasons we are switching away from Interface Builder", as it doesn't actually answer the question. But then it wouldn't be interesting enough to click on.

This article is from July 8 (48 days ago). Anyone have any more recent information?

Forgive me for asking, but how is "no default timeout" a sensible default for any technology?

OP here. iOS 9's SFSafariViewController, unlike UIWebView or WKWebView, runs out-of-process and cannot be data-scraped. Beacause of this, SFSafariViewController shares cookies with Mobile Safari. The use-case here is essentially loading a special URL on the website that will take any logged in session and return back an oAuth token that the native app can use.

The communication method in the demo is as if you were talking indirectly with Mobile Safari, using a custom url protocol (e.g. fooapp://), or by using the new (safe) Universal links (apps can register specific domains/urls that will redirect back to the app, using their Associated Domains entitlements).

Any suggestions on how to wrap it in insulating foam? Can you by a spray-on foam or something?

Do you guys have a link to the VLC app on the iOS App Store? I ask because there are so many clones it is very hard to find it.

On a related note. Is there anything you can do (trademark, etc.) about getting the scammy clones off of the store?

iOS 8 added many useful APIs, but I find many are hard to use while maintaining support for iOS 7.

For example: - To share code between your app and your iOS 8 extensions, you want to put them in a shared framework, something which was just added in Xcode 6, and compatible only with iOS 8. So using shared code from iOS 7 means you'd have to keep copies of your source in the main app framework.

- Photos.framework is really great, but is completely different from Assets.framework, so building a photo app means writing your code twice. Yes, you can use Assets framework from iOS 8, but it's unclear how iCloud Photo Library will work with it (iOS 8.0 inadvertently removed "Camera Roll" from Assets framework, for example)

- Can't clean up your UIActionSheet, UIAlertView, UIPopoverController code with UIAlertController until you go iOS 8+

So iOS 8 moves a lot of things forward really nicely, and building an iOS 8-only app has been really great, but I feel, more so than before, that it's harder to maintain support for older iOS versions.

I was hoping iOS 8's adoption numbers would be rising faster than it did for iOS 7, so it'd be easier to justify dropping iOS 7 support sooner, but anecdotally it seems the large installation binary has made it hard to update 16GB devices.

It doesn't appear to have positional sensors (the Oculus DK2 does, with a stationary dongle to compare your relative head movements).

It is very disorienting if you only have rotational support (as if your head's at the same point in space) and not also positional (head moving forward, backward, up, down, left, right, etc.)

100% agree with this. Anecdotally, I know a lot of people who would be great at programming but they'd never consider it because of their pre-conceived notion that they'd have to be good at math first.

I've never been particularly good at math, and learned enough to get by in my CS theory classes. I hardly ever use math to program, unless the problem is specifically math-based or geometry-based. To me, programming is communication and organization.

Sure, that's possible. When you're passing around the links to other people, it gets old to have a bunch of "[link] and search for 'Keychain|HealthKit|HomeKit'"

This article is so very thorough and great.

I'd love to have some anchor links within the piece though, so when I'm referring my team to some of the changes, I can direct them right to the relevant information.

Cluster might suit your needs. It's not photo storage, but it's photo/video sharing that's only to private groups of people. In fact, people can't even know what other clusters you belong to, other than the ones they share with you. Works on the web at https://cluster.co and it's on iOS and Android.

Disclaimer: I'm the iOS developer on Cluster.

As always, feedback appreciated if you do check it out.

Hah! This brings back memories as in 1998 I had Professor Feldman as a CS freshman at GWU. And, you guessed it, we learned Ada as our first language.

The main thing I remember is that it was very annoying to be fixing indentation issues on a terminal text editor, although learning about packages was very cool. Irrationally, the indentation strictness annoys me in modern languages like Python, too :) that, and using := instead of = felt like a waste!

You can always try the app. Though I'll stress that it is not a storage/backup solution for your photos. It's for creating private spaces with other people where you can share photos/videos.

Yeah, totally agree about the problem of massive, disorganized mountains of images. A lot of companies shy away from trying to solve that, because ultimately it's profoundly hard to scale it (e.g. Everpix). Loom and Everpix are the closest to really trying to tackle it. Dropbox can "solve" it, as long as you are willing to pay to store your photos in a sync-everywhere folder.

Cluster isn't trying to solve the "organize and share" problem, it's trying to make the stuff you share reach the right people in the right context. I think what Dropbox is doing fits their business model really well and adds a beautiful layer on top of your photos/videos in your Dropbox account.

[cough](http://cluster.co). I work on it. It's less "storage/archival" and more "private photo/video social network".

UIViewControllers fall somewhere between an Activity and a Fragment.

In particular if you use any kind of view controller containment (custom container view controllers), you can only do that with fragments, and only then with Android 4.0+.

As someone who's looked at building tablet apps, the containment is a good thing to consider. In these cases, iOS makes it easier to combine your existing view controller hierarchies, while there are some idiosyncrasies (only 1 action bar across the top of a "split view controller") on Android still that don't always make things easy (in my opinion).

This: http://relogik.com/eko (referenced in the article) is a better design, because it keeps the same structure of a traffic light but enhances the edge of each light to reveal a countdown.

Something to consider: Xcode's UI, particularly for editing Interface Builder stuff, really benefits from a larger screen.

On a smaller screen (13" or 11"), you'll find yourself constantly toggling panels on/off so that you can see what you're working on.

It's true that Android initially didn't support touch; they were making a Blackberry competitor (http://www.talkandroid.com/109966-how-did-android-look-in-20...).

I'd argue that it wasn't because of doing a "good job" adding touch that allowed them to succeed. It was the price of free.

Even now all "touch" events are treated as 'click' events. And it's not easy to get access to the number of fingers on a view or to track them like iOS can.