I've written a series of blog articles on multitasking between applications and external accessories. And possible ways of inter application data sharing.
I wouldn't call it a tutorial because it is a work in progress. There are undoubtedly misconceptions on my part, missing information and grammatical and spelling errors. Its far from finish. We are leaning towards what we hope will grow into a general protocol for inter app communication. There is a lot of material here.
I am interested, in opinions, ideas, corrections and yes critiques. But again I know the spelling and grammar is not the greatest, yet.
I've written a series of blog articles on multitasking between applications and external accessories. And possible ways of inter application data sharing.
I wouldn't call it a tutorial because it is a work in progress. There are undoubtedly misconceptions on my part, missing information and grammatical and spelling errors. Its far from finish. We are leaning towards what we hope will grow into a general protocol for inter app communication. There is a lot of material here.
I am interested, in opinions, ideas, corrections and yes critiques. But again I know the spelling and grammar is not the greatest, yet.
I haven't read all of your posts yet, but I'm definitely impressed. iOS inter-app communications is a subject I've thought about sometimes, but your posts go to much greater length so I really appreciate it. One thing that I thought about: in IOS multitasking and external accessories part II - Life in The Clouds you talk about finding out possible applications to open by going through the running processes. Wouldn't UIApplication canOpenUrl: be a better alternative? You could iterate through a hardcoded list of URL schemes to see which supported apps have been installed on the device, as opposed to just detecting running processes.
I haven't read all of your posts yet, but I'm definitely impressed. iOS inter-app communications is a subject I've thought about sometimes, but your posts go to much greater length so I really appreciate it. One thing that I thought about: in IOS multitasking and external accessories part II - Life in The Clouds you talk about finding out possible applications to open by going through the running processes. Wouldn't UIApplication canOpenUrl: be a better alternative? You could iterate through a hardcoded list of URL schemes to see which supported apps have been installed on the device, as opposed to just detecting running processes.
Thanks, interesting idea.
we was thinking though mostly of including applications that are backgrounded or suspended .
But maybe thats irrelevant, We are trying to come up with a general protocol for this type of inter app communication, the more feedback and suggestions the better. thanks again.
__________________
Help us build great applications or let us make your applications exceptional. find us on Facebook
I haven't read all of your posts yet, but I'm definitely impressed. iOS inter-app communications is a subject I've thought about sometimes, but your posts go to much greater length so I really appreciate it. One thing that I thought about: in IOS multitasking and external accessories part II - Life in The Clouds you talk about finding out possible applications to open by going through the running processes. Wouldn't UIApplication canOpenUrl: be a better alternative? You could iterate through a hardcoded list of URL schemes to see which supported apps have been installed on the device, as opposed to just detecting running processes.
fiftySixty
The more I think about this the more I like it.
Originally we were thinking we would keep a hard coded list of the applications that where compatible and compare against the process list, so we get all suspended , background and running processes that meet the protocol criteria.
but your right, we could design a url scheme in a way such that it is unique to our applications. then iterate using canOpenURL and compare that to the process list, thus eliminating the need for a hardcoded list. Again we are looking for any and all feedback and suggestions.
__________________
Help us build great applications or let us make your applications exceptional. find us on Facebook
Originally we were thinking we would keep a hard coded list of the applications that where compatible and compare against the process list, so we get all suspended , background and running processes that meet the protocol criteria.
but your right, we could design a url scheme in a way such that it is unique to our applications. then iterate using canOpenURL and compare that to the process list, thus eliminating the need for a hardcoded list. Again we are looking for any and all feedback and suggestions.
Well, I'm glad you found my suggestion helpful With the approach you're proposing, you could create a two-layer (or three-layer) interoperability approach:
- can't open url => app not installed
- can open URL but no process => app installed but not running
- can open URL and process found => app running
So, depending on the situation, you could then propose a suitable action, e.g. downloading the app if it's not installed.
Well, I'm glad you found my suggestion helpful With the approach you're proposing, you could create a two-layer (or three-layer) interoperability approach:
- can't open url => app not installed
- can open URL but no process => app installed but not running
- can open URL and process found => app running
So, depending on the situation, you could then propose a suitable action, e.g. downloading the app if it's not installed.
If we are iterating through UIApplication canOpenUrl I should not get any apps that are not installed.
Also here is yet another variation of launch scheme to consider
I meant that if you iterate through a list of url schemes using canOpenUrl and it returns false, then you could suggest downloading a suitable app to handle the scheme. This of course means hardcoding (or downloading) the list of schemes and apps that go with them.
I meant that if you iterate through a list of url schemes using canOpenUrl and it returns false, then you could suggest downloading a suitable app to handle the scheme. This of course means hardcoding (or downloading) the list of schemes and apps that go with them.
You seem to be quite interested (and helpful) in this area, are you currently also working with external accessories, if you would like to continue more discussion your more than welcome to contact me via pm or our facebook app developers group for mooncatventures group.
I'd be willing to share info I do not want to post in an open forum.
Thanks again for the help
__________________
Help us build great applications or let us make your applications exceptional. find us on Facebook
You seem to be quite interested (and helpful) in this area, are you currently also working with external accessories, if you would like to continue more discussion your more than welcome to contact me via pm or our facebook app developers group for mooncatventures group.
I'd be willing to share info I do not want to post in an open forum.
Thanks again for the help
I'm not working with external accessories, and I'm not currently even working on anything related to inter-app communications. But I have been playing with an idea for an app that could act as a central hub. So far I haven't actually decided to implement anything because I'm kind of hoping that Apple would step up to the game a bit more.
Idea for IOS inter app with external accessories
With the approach you're proposing, you could create a two-layer (or three-layer) interoperability approach:
Linear Mode
