You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Lou Moore <lm...@hi5.com> on 2008/03/21 09:24:58 UTC

requestShareApp callback

Has anyone else implemented requestShareApp yet? Just got started on our
implementation, and we have it all working except the callback. We register
requestShareApp as an rpc method which sends the user to our invite page,
passing along the reason and callback, and on completion we send them back
to the view they came from. What was the thinking on how containers are
expected to invoke the specified callback at that point? Also, it seems like
it might actually be more useful to just pass along view-params similar to
requestNavigateTo, as the desired behavior for developers is really just to
show a specific post-invite page to the user, but the spec calls for a
callback function instead.

Or, are we going about this in a totally unexpected way?

Thanks,
Lou 

Re: [Hi5-opensocial] requestShareApp callback

Posted by Akash Xavier <ak...@gmail.com>.
Yeah,
Might give applications a chance to say something like a 'thank you'
message. :)
This seems to be useful.

On Sat, Mar 22, 2008 at 2:49 AM, Lou Moore <lm...@hi5.com> wrote:

> Definitely, I misunderstood thinking if the callback was specified it had
> to
> be executed.
>
> I do think developers will need the ability to do some post-invite action
> via some extra parameters though, will follow up on the spec mailing list
> once I¹ve got something to propose.
>
> Thanks!
> Lou
>
>
> On 3/21/08 5:37 AM, "Cassie" <do...@google.com> wrote:
>
> > The contract of the callback is this:
> > - it is either executed -or- the entire gadget is reloaded
> >
> > so, if you stay on the same page when sharing the app (ie with a pop up
> or
> > something) then you have to call the callback. if you go through an
> different
> > page flow entirely then its fine for the gadget to just have its onload
> > handler called.
> >
> > which means, that as far as the spec goes your implementation is good.
> it does
> > seem like we may want to give developers a way to know what happened
> though...
> > or the ability to request a view to navigate to like you said. perhaps
> propose
> > something on the spec mailing list if you figure out a good way to do
> it.
> >
> > I hope that helps.
> >
> > - cassie
> >
> >
> > On Fri, Mar 21, 2008 at 9:24 AM, Lou Moore <lm...@hi5.com> wrote:
> >> Has anyone else implemented requestShareApp yet? Just got started on
> our
> >> implementation, and we have it all working except the callback. We
> register
> >> requestShareApp as an rpc method which sends the user to our invite
> page,
> >> passing along the reason and callback, and on completion we send them
> back to
> >> the view they came from. What was the thinking on how containers are
> expected
> >> to invoke the specified callback at that point? Also, it seems like it
> might
> >> actually be more useful to just pass along view-params similar to
> >> requestNavigateTo, as the desired behavior for developers is really
> just to
> >> show a specific post-invite page to the user, but the spec calls for a
> >> callback function instead.
> >>
> >> Or, are we going about this in a totally unexpected way?
> >>
> >> Thanks,
> >> Lou
> >>
> >> _______________________________________________
> >> Hi5-opensocial mailing list
> >> Hi5-opensocial@google.com
> >> https://mailman.corp.google.com/mailman/listinfo/hi5-opensocial
> >>
> >>
> >>
>
>


-- 
Akash Xavier
akashmanohar@gmail.com

Re: [Hi5-opensocial] requestShareApp callback

Posted by Lou Moore <lm...@hi5.com>.
Definitely, I misunderstood thinking if the callback was specified it had to
be executed.

I do think developers will need the ability to do some post-invite action
via some extra parameters though, will follow up on the spec mailing list
once I¹ve got something to propose.

Thanks!
Lou


On 3/21/08 5:37 AM, "Cassie" <do...@google.com> wrote:

> The contract of the callback is this:
> - it is either executed -or- the entire gadget is reloaded
> 
> so, if you stay on the same page when sharing the app (ie with a pop up or
> something) then you have to call the callback. if you go through an different
> page flow entirely then its fine for the gadget to just have its onload
> handler called. 
> 
> which means, that as far as the spec goes your implementation is good. it does
> seem like we may want to give developers a way to know what happened though...
> or the ability to request a view to navigate to like you said. perhaps propose
> something on the spec mailing list if you figure out a good way to do it.
> 
> I hope that helps.
> 
> - cassie
> 
> 
> On Fri, Mar 21, 2008 at 9:24 AM, Lou Moore <lm...@hi5.com> wrote:
>> Has anyone else implemented requestShareApp yet? Just got started on our
>> implementation, and we have it all working except the callback. We register
>> requestShareApp as an rpc method which sends the user to our invite page,
>> passing along the reason and callback, and on completion we send them back to
>> the view they came from. What was the thinking on how containers are expected
>> to invoke the specified callback at that point? Also, it seems like it might
>> actually be more useful to just pass along view-params similar to
>> requestNavigateTo, as the desired behavior for developers is really just to
>> show a specific post-invite page to the user, but the spec calls for a
>> callback function instead.
>> 
>> Or, are we going about this in a totally unexpected way?
>> 
>> Thanks,
>> Lou 
>> 
>> _______________________________________________
>> Hi5-opensocial mailing list
>> Hi5-opensocial@google.com
>> https://mailman.corp.google.com/mailman/listinfo/hi5-opensocial
>> 
>> 
>> 


Re: [Hi5-opensocial] requestShareApp callback

Posted by Cassie <do...@google.com>.
The contract of the callback is this:
- it is either executed -or- the entire gadget is reloaded

so, if you stay on the same page when sharing the app (ie with a pop up or
something) then you have to call the callback. if you go through an
different page flow entirely then its fine for the gadget to just have its
onload handler called.

which means, that as far as the spec goes your implementation is good. it
does seem like we may want to give developers a way to know what happened
though... or the ability to request a view to navigate to like you said.
perhaps propose something on the spec mailing list if you figure out a good
way to do it.

I hope that helps.

- cassie


On Fri, Mar 21, 2008 at 9:24 AM, Lou Moore <lm...@hi5.com> wrote:

>  Has anyone else implemented requestShareApp yet? Just got started on our
> implementation, and we have it all working except the callback. We register
> requestShareApp as an rpc method which sends the user to our invite page,
> passing along the reason and callback, and on completion we send them back
> to the view they came from. What was the thinking on how containers are
> expected to invoke the specified callback at that point? Also, it seems like
> it might actually be more useful to just pass along view-params similar to
> requestNavigateTo, as the desired behavior for developers is really just to
> show a specific post-invite page to the user, but the spec calls for a
> callback function instead.
>
> Or, are we going about this in a totally unexpected way?
>
> Thanks,
> Lou
>
> _______________________________________________
> Hi5-opensocial mailing list
> Hi5-opensocial@google.com
> https://mailman.corp.google.com/mailman/listinfo/hi5-opensocial
>
>