The marketers are a plague, they destroy everything.
> Android has intents which are a big step in the right direction. With a few tweaks to user experience they could solve this problem on the platform.
What tweaks would 'solve this problem'? As far as I can tell, Android intents work flawlessly for transferring content between apps. I can click an attachment on an email, open it in an editor, make changes, and then share that file back on a social network or another email. Each step taking only two taps. The speed of downloading attachments could do with some work in most cases, but that's just a hardware issue and will probably be far faster in another generation or two of hardware.
I have a feeling the author has never really used an Android device much? Or am I missing some key piece missing from intents?
1. No app discovery -- I want to find out about apps that can work with my content.
2. Action curation -- I want to see the actions that other people think are most useful when dealing with my content.
3. No "Return" actions -- eg. The context knowledge necessary to reply to the same message, or overwrite an existing file.
4. Cross device and cross OS: If this is done right, there's no reason for the action to be bound to just one device or even one person.
2. Each app defines what intents it can handle, so I don't think curation is necessary. The app select popup window is already curating that for you?
3. This context knowledge is provided inside every intent. Not all apps choose to use it, though. In some cases I'd guess the sandbox would get in the way as well. I'm not sure how much practical value this would have anyway? Can you explain it a bit more?
4. There is nothing stopping Apple from adopting Android intents, but obviously they won't. This is a 'pie in the sky' suggestion that won't happen for the same reason there is more than one flavour of Linux. It's like asking why you can't pipe results from your unix system to a Windows system - it just won't happen for political reasons.
According to Michael, it's creator, it uses Mach Ports to communicate between apps. Apple embraced it and included it with GarageBand.
http://createdigitalmusic.com/2013/09/audiobus-for-ios-7-upd...
It is a shame that we can't get more app functionality sharing in place, but really I don't know if we necessarily want to bring that much dependency management into the mobile space at large either.
Some of the UX around intents isn't great, but the core concept and implementation is very clever and doesn't get the attention and respect it deserves. Much like many aspects of Android.
[1]: https://developer.apple.com/library/ios/documentation/FileMa...
In my app, I went one step further and when the user doesn't have an app installed for the given file type, I recommend one, but that isn't a requirement. I keep track of what percentage of view file requests are fulfilled by an already installed app, and it is generally over 95%.
I think you guys should better understand Intents before you trash them (and actually try to replicate them on iOS). Why was the use of Intents so minimal in the Filepicker.io Android library? I replaced that library with a intents and have a much more robust application.
If there's a document viewer, it'll listen in for the file types it supports when you try to open a file (I think its a VIEW intent). It's all very impressive and very, very useful.
If iOS is so great and there is demand, Apple can sell us a license to run it on our device. My guess is that few would pay for this. More likely, the market would demand a windowing GUI, not an entire OS (e.g., one borrowed from CMU, FreeBSD and NetBSD; hello again Apple). Could developers respond and deliver one?
UNIX can do lots of things well. And well enough. That's probably why iOS relies on UNIX and not some other OS. But iOS won't let you do all the things that UNIX will let you do.
Conclusion: iOS is inferior to other, more open, more traditional UNIX alternatives. Apple does make a nice windowing GUI. And some very nice enclosures. Each worth a price, no doubt. But UNIX, the code that does the important stuff, has always been free.
To be truthful, my "requirements" include first and foremost, a great looking enclosure. There is a reason for that. I want be able to buy the enclosure separately. This is important.
In my vision, there would multiple sources for boards that might fit inside. Not every user might want or need the same computing power or peripherals.
Imagine, to take an example, if there were multiple RaspberryPi-sized boards. Then you could mix and match different available enclosures[1] with different boards.
1. We are seeing the market respond with many, varied enclosures for the Pi.
There are lots of development boards for sale to consumers, and there are dedicated people porting UNIX OS's to run on them.
What I don't see, generally, are reasonably-priced and attractive enclosures for these boards. The RaspberryPi may be changing this state of affairs, as the Pi enclosure market continues to grow.
Separating out the parts of the device, from the enclosure to the PCB to the OS to the third party software is, you might say, like the UNIX userland philosophy of isolating functions to their own individual utilities. This separation allows more flexibility and more power, in the example of the UNIX userland by allowing the user to filter and redirect output and connect utilities together with pipes.
What are the things Apple does well? Enclosures and graphics, in my opinion. (And controlling their users :) UNIX is not on the list. There are better UNIX alternatives than iOS. My opinion.
Or, as in the article, you can wait and hope that iOS can be improved to be more like those UNIX alternatives.
Having concept of "files" to be able to open pdf you just downloaded from email/browser inside pdf reader?
They do need a filesystem and interoperable components. What they do NOT need is a hierarchical based filesystem that limits you to a directory trees. It's an organizational nightmare, and unless you've ever used git before it's a literal hell for the average user.
Instead, a flat filesystem with smart names, tagging, and metadata is the way forward. Subdirectories will be relegated to those who want them.
As for security, that excuse is nonexistent when Apple has the final authority to application interoperability and analysis. If an implementation is flawed, they can reject it at will and tell the developers to improve it.
Time to rethink the mobile OS as a whole.
You want to do something with an image, for example, and you're greeted with a huge list of apps that all claim to handle images. Not only is it hard to find the app you want, most of the ones in the list have nothing to do with the task you're trying to accomplish. Hardly user friendly behavior.
FWIW, I personally don't really mind the huge list and can find my way around it, but I'm a heavy Unix user that does most of his work in the terminal already. Most consumers are not.
Apple had once an approach to this in the old Classic OS, by a switch that would enable or disable some access and features in the OS (esp. Finder). While this wasn't a great success on the desktop (like any other easy-suites), it might be worth to rethink for the mobile platform.
(Edit: This would also afford to expose system calls to the end user, being the end of consumer haven.)
See "communicating with other apps": https://developer.apple.com/library/ios/documentation/iPhone...
In one app framework we built we had a fairly complicated parser and it could handle a pretty wide variety of URL paths and the supplied data. But there in turn lies the problem - each app must have a mechanism to handle the parsing and routing for these URLs.
They offer certain advantages, too, but this is no different from any other software-engineering tradeoff.
There's a reason why the winning kernel is a monolithic kernel, and the winning init system is one large God-daemon that replaces many smaller legacy daemons.
iOS doesn't work that way, and for good reasons.
