5 ms·

I'm curious how the Android share intent compares - it's been around a lot longer.

by ufmace 12y ago

lstamour 12y ago
Navigating on Android is vastly different -- it's designed so every activity (screen) is uniquely identifiable and can be referenced by other apps, browser URLs, etc. Activities can register which intents they support in AndroidManifest.xml, so it's not dynamic, but not heavy-weight either. Sharing from a third-party or launching from inside your own app, it's largely the same thing to an activity. As you navigate, it's like a web browser, your back button keeps a history of where you've been across apps that will work different than controls within the app to navigate back (Up). You can also pass content between activities, just as you would for sharing or viewing actions. Primarily, navigation to different activities is via Intents: http://developer.android.com/guide/components/intents-filters.html http://developer.android.com/guide/components/intents-filter... You can explicitly tell it which activity to load (as if using URLs) or you can identify the action (view or share) and mime/type of your text or binary data. http://developer.android.com/training/sharing/send.html http://developer.android.com/training/sharing/send.html Common intents: http://developer.android.com/guide/components/intents-common.html http://developer.android.com/guide/components/intents-common... So "sharing" or interacting between apps, or within your own app, or your app and system apps, is... basically baked in to Android, and far more common than you'd expect. It's like a more powerful version of "Open With" that isn't restricted to files saved to disk. I'm not sure you can send more than one type of data at a time, though it wouldn't surprise me if there's an Intent/Action for that as well. The counter to this is incredibly long lists of apps to pick from, prompts for which app to view something in (like a URL or media type) and other annoyances that you get with increased flexibility. It's pretty cool though. You can even have certain URLs open certain apps as you browse in Chrome, so if your Google search takes you to a blog that links you to Netflix, you could hop directly from the Google app, to the Chrome app, to the Netflix app and it could feel seamless, one screen to the next.
- gcb4 12y ago
  sadly this great idea is implemented like crap even in goggles own apps. open email, click a link which open in the browser, click a link which open in YouTube. now you have the email app activity in your recent app list, but if you switch to it you get a you tube video. now you either have the video/web page/etc, or the email message. not both. to get back to your email you have to press back all the way... it rarely creates such a clumsy situation, but every time it happens you're guaranteed to get very close to smashing the phone on the wall.
  - martiuk 12y ago
    You eventually get used to it, I think of opening each app from intents like a stack and you press back to 'pop' the apps off the stack to get back to email (in your example).
    - lstamour 12y ago
      Yep. And similar to seeing tabs in the switcher in L Preview, I expect we'll see a richer "switcher" that's more activity or history aware in some future release...
xpaulbettsx 12y ago
One thing that is different is that there is no "shared container" - data is serialized to the Intent bundle (an IPC mechanism that basically is just a bag of stuff), and the context that you receive the data in, is your app (with your file permissions, security keys, etc), not a tertiary one.
- lstamour 12y ago
  Yep. Effectively, your app can't easily communicate back and forth with a third-party app using stock Android code. And there's little support for "embedding" other apps into yours, just context switching and data sharing between screens. So that's new here. Android really was designed around these full screen "activities", and created "fragments" only for use by first-party applications, or included as libraries from third-parties. The idea of running someone's app within your own... that's not supported. Heck, even Chrome doesn't have extensions. For an open platform, Android does have its limitations... ;-)
  - habosa 12y ago
    That's not really true. If an app wants to be able to constantly communicate with other apps it can pretty easily launch a background Service which can be bound from other activities.
    - lstamour 12y ago
      Yes, third-party devs have flexibility in defining how apps can cross-communicate. But in Apple's case, they're doing it for us. Kind of like how Google tried to nail accounts and sync for Android. I write for both platforms FYI, so while I may not get the details 100%, and leave things out, I'm pretty happy with both platforms overall, just for different reasons for each.

I'm curious how the Android share intent compares - it's been around a lot longer.

by ufmace 12y ago

I'm curious how the Android share intent compares - it's been around a lot longer.

Navigating on Android is vastly different -- it's designed so every activity (screen) is uniquely identifiable and can be referenced by other apps, browser URLs, etc. Activities can register which intents they support in AndroidManifest.xml, so it's not dynamic, but not heavy-weight either. Sharing from a third-party or launching from inside your own app, it's largely the same thing to an activity. As you navigate, it's like a web browser, your back button keeps a history of where you've been across apps that will work different than controls within the app to navigate back (Up). You can also pass content between activities, just as you would for sharing or viewing actions. Primarily, navigation to different activities is via Intents: http://developer.android.com/guide/components/intents-filters.html http://developer.android.com/guide/components/intents-filter... You can explicitly tell it which activity to load (as if using URLs) or you can identify the action (view or share) and mime/type of your text or binary data. http://developer.android.com/training/sharing/send.html http://developer.android.com/training/sharing/send.html Common intents: http://developer.android.com/guide/components/intents-common.html http://developer.android.com/guide/components/intents-common... So "sharing" or interacting between apps, or within your own app, or your app and system apps, is... basically baked in to Android, and far more common than you'd expect. It's like a more powerful version of "Open With" that isn't restricted to files saved to disk. I'm not sure you can send more than one type of data at a time, though it wouldn't surprise me if there's an Intent/Action for that as well. The counter to this is incredibly long lists of apps to pick from, prompts for which app to view something in (like a URL or media type) and other annoyances that you get with increased flexibility. It's pretty cool though. You can even have certain URLs open certain apps as you browse in Chrome, so if your Google search takes you to a blog that links you to Netflix, you could hop directly from the Google app, to the Chrome app, to the Netflix app and it could feel seamless, one screen to the next.

gcb4 12y ago
sadly this great idea is implemented like crap even in goggles own apps. open email, click a link which open in the browser, click a link which open in YouTube. now you have the email app activity in your recent app list, but if you switch to it you get a you tube video. now you either have the video/web page/etc, or the email message. not both. to get back to your email you have to press back all the way... it rarely creates such a clumsy situation, but every time it happens you're guaranteed to get very close to smashing the phone on the wall.
- martiuk 12y ago
  You eventually get used to it, I think of opening each app from intents like a stack and you press back to 'pop' the apps off the stack to get back to email (in your example).
  - lstamour 12y ago
    Yep. And similar to seeing tabs in the switcher in L Preview, I expect we'll see a richer "switcher" that's more activity or history aware in some future release...

xpaulbettsx 12y ago

One thing that is different is that there is no "shared container" - data is serialized to the Intent bundle (an IPC mechanism that basically is just a bag of stuff), and the context that you receive the data in, is your app (with your file permissions, security keys, etc), not a tertiary one.

lstamour 12y ago
Yep. Effectively, your app can't easily communicate back and forth with a third-party app using stock Android code. And there's little support for "embedding" other apps into yours, just context switching and data sharing between screens. So that's new here. Android really was designed around these full screen "activities", and created "fragments" only for use by first-party applications, or included as libraries from third-parties. The idea of running someone's app within your own... that's not supported. Heck, even Chrome doesn't have extensions. For an open platform, Android does have its limitations... ;-)
- habosa 12y ago
  That's not really true. If an app wants to be able to constantly communicate with other apps it can pretty easily launch a background Service which can be bound from other activities.
  - lstamour 12y ago
    Yes, third-party devs have flexibility in defining how apps can cross-communicate. But in Apple's case, they're doing it for us. Kind of like how Google tried to nail accounts and sync for Android. I write for both platforms FYI, so while I may not get the details 100%, and leave things out, I'm pretty happy with both platforms overall, just for different reasons for each.