Someone confirm my suspicion

[Warren]

I think I know what the answer to this question is, but I thought I
would ask it anyway to confirm to myself that I'm either way off or
close to being correct.

The question I received this afternoon from a friend who is taking a
usability course:

Can one iPhone application feed information to another iPhone/iPod
Touch application?

For my last user experience class project, we have to provide use
cases for a device for managing bicycle messenger deliveries. I
immediately thought of the iPod Touch to use as the base, with added
features of a bar code scanner and ability to accept signatures.

I had planned to have two iPhone/iPod Touch applications :
a delivery application that allows the messenger to manage deliveries
maps application that displays the delivery locations and allows the
messenger to get directions for each delivery
Each application would be available as one of the four applications
available on the main screen.

Keep in mind that I'm not an iPhone/iPod Touch user:
Can the delivery application feed location info to the maps
application? When the delivery person clicks on the maps location,
they will see a map with pinpoints of all the deliveries.
I'm assuming the answer is yes, but again, I know nothing about iPhone
development.

Regards,


---

Anyone...

[Rudy Richter]

I'd take a look at the mapkit Apis that apple recently introduced.
Apps are sandboxes on the device so you wouldn't be able to have two
apps accessing the same data, mapkit sounds like where you want to look.

-rudy

> --
>
> You received this message because you are subscribed to the Google
> Groups "Syracuse Area CocoaHeads" group.
> To post to this group, send email to syracuse-are...@googlegroups.com
> .
> To unsubscribe from this group, send email to syracuse-area-coco...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/syracuse-area-cocoaheads?hl=en
> .
>
>

[Leone Anthony]

Warren --

Please someone jump if I get something wrong here ... but ...

A Cocoa touch application can not really feed data to another application on it's own. All of the applications on an iPhone/iPod touch are sandboxed and can not communicate to another application on the phone/ipod. This is not really a problem for the application you are describing because, one can include map views in your application and make use of the included map data for location.

A couple of other points ... the iPod touch does not have a camera -- so no barcode scanner, but the phone does and many developers have created barcode scanners for the phone. If you really wanted to have a set of applications communicating data between each other, one could do it by creating a server application running on a 3rd device, say a web server. The 1st application could post messages to the server, and the 2nd application could retrieve the data. There are probably other ways.

Hope this helps somewhat.

Tony Leone

[Warren]

Thanks Rudy and Leone, both your answers closely match what I had
thought initially, much appreciated.

[Bill Garrison]

On Dec 4, 2009, at 8:39 PM, Leone Anthony wrote:

> Warren --
>
> Please someone jump if I get something wrong here ... but ...
>
> A Cocoa touch application can not really feed data to another
> application on it's own. All of the applications on an iPhone/iPod
> touch are sandboxed and can not communicate to another application
> on the phone/ipod. This is not really a problem for the application
> you are describing because, one can include map views in your
> application and make use of the included map data for location.

Yeah, one application can handle both map display and a deliveries
database. No need to have separate apps.

In the case where you really must have separate apps, you could hack
some kind of data exchange using custom URLs. An iPhone app can
register to handle a custom URL scheme (e.g. bonjovi://). If
application X opens a URL of bonjovi://blah/blah?oh, and application Y
is registered to handle the bonjovi:// scheme, then application Y will
launch and process that URL. You can load up the URL with arbitrary
data, so the URL would be your data transfer channel.

One limitation of this approach: you can only pass data to another
application by launching tha app via URL. You're limited to what
would be reasonable UI behavior. If two apps are continuously
launching each other, passing data back and forth with custom URLs,
that would get to be annoying pretty quickly. Also probably would
make it through the gauntlet of App Store review. You have to keep
the data exchange down to something that would fit a reasonable
workflow between the user, application X, and application Y.

Another limitation: without defining a whole protocol on top of the
custom URL, you will be limited to passing arbitrary data as part of
the URL proper. There are encoding specs for URLs and I think there
might be a length restriction (1024 characters?). That said,
there's nothing keeping a developer from creating a custom URL (e.g.
bonjovi://) and treating it as identical to the HTTP protocol. As
long as you don't mind writing the code, there's nothing keeping you
from defining GET, PUT, POST, DELETE requests (identical to HTTP) on
top of your custom protocol. Then you'd get all the power of HTTP
with respect to data passing in your custom protocol, with the price
being that you'd have to write code to process the bonjovi:// requests
and responses in the same way that HTTP is processed.

Bill