I'll try to answer at least some of your questions:
> LiftActor. This is a pretty common use case, so I'm sure I'm missing
> something obvious.
I think I have only seen one other question like this, so I don;t
think this would be something obvious. That being said, I have been
thinking for a while that a push notification would do just what you
are trying to do.
> After digging through the documentation and reading about liftActors,
> stateful rest, and the asynch REST. I'm assuming that REST with asynch
> returns is the best way to do it, but I'm a bit confused on the exact
Yes, I would use rest async, but the idea may be a bit different.
REST Asycn means that you do a request (call
http://app/host.com/notifications), the client will have something
like a 70 second timeout (this number is totally made up, you may want
to adjust the value), and Lift should respond with some new data
(something some other client sent), within those 70 seconds. Now,
using async, Lift will put your request in continuation (assuming you
are using jetty > version 7 or tomcat ( I think version 7 has
continuation). this basically means that you are not holding that one
thread locked until you get an answer. So this helps you scala better,
as fewer threads can handle more http /iOS clients).
Now, your iOS client will have to implement a good chuck of logic,
that most of us get for fre when we develop a web app using regular
1- If you don;t get an answer in 70 seconds, you timeout the request,
and make a new one
2- when you do get some data, start a new http request, to ask for more data
2.a - I don;t know if iOS allows this, but ideally you would process
the just received data on a different thread, while there is a new
3- Make sure you have only one http connection per cell phone.
4- you may want to send some kind of sequence id with your http
request, so that Lift will know how much data you already have on your
Let me explain this one
1- my cell sends a new update to your lift app, let's call this the seq 1
2- the 3 other iOS clients have been sending http request to Lift with
seq 0, because nobody had sent any updates yet
3- as soon as my cell data made it to the Lift app, all other 3
iphones get the new data, including the seq id 1
4- when the other 3 iphones send new requests, they need to include
the new seq id 1, so that Lift will not send the same data to those
So, there isn;t really an iPhone registering with a lift actor, you
can have one one LiftActor that knows how to retrive the updates, and
will just see which seq id the iPhone saw last, and will return a List
of notifications greater than that ID
> I'm a bit confused on the following items:
> 1. How do I register the iOS client so that the BroadcastServer LiftActor
> will push back the client message to the iOS client?
There is no registering
> a. What's the url that I need to poll in order to get the response?
only returns the 200 response and doesn't seem to
> register the client to the LiftActor
you can have any url, in your case, it could be
but in your async call don;t return an answer, unless you have one (or
your reached the 70 second timeout)
> b. The iOS client has the sessionid, but that doesn't seem to be
> sufficient. There seems to be a auto generated GUID that corresponds to the
> LiftActor. Does the iOS have to implement this as well? It seems like the
> web client implements them seamlessly with CometActors. How does this work?
so, with my idea, there is no need for the session info, actually, it
would be better if you go the stateless path (but doing a login on
each request may be too much overhead, I guess you will have to see,
but if you can, try to go stateless, so there are less resources being
used on the Lift server) I'm only saying this for a RESt service, for
a web app, you most of the time want stateful
> c. I've read Diego's post
It's good that the cells
> are updating via different web clients via comeactors, but how do you
> implement it so that the iOS client receives the updates and how does the
> registration happen?
I'm glad you read that post :)
I think I answered this a few paragraphs abode.
> d. What parameters does the iOS client have to have to autogenerate the
> url that it's constantly polling?
The url is always the same, just keep incrementing the seq, ah, and
think of what to do when your lift app has been running for a months,
you don;t want to give a new iPhone client 2000 notifications, just
because it was restarted or something. (so, you will not always start
from seq 0.
> 2. When I get into the code block respondAsynch. It loses the session and
> context. Is there a way to maintain sessions while doing asynch processing
> or is this not possible?
if you put together a sample app that shows this, I can play around
and see what I find, you may need to copy the info you need into a
> 3. If I cannot maintain sessions during asynch processing, how do I maintain
> a session for a *single* iOS client while providing a url to continuously
> return back msgs from the LiftActor?
You will not need this.
> 4. The asynch rest api returns a response code immediately
> (NoContentResponse of OkResponse) and then asynchronously returns a
> response. How do I make it so the resthelper asynch function registers
> itself to the LiftActor so that it will constantly get the callback from the
I'll skip this one because I'm not sure right now.
> I've been reading a lot of examples that have a bit of CometActor, a bit of
> Rest API and a bit of asynch Rest api implementation. It would be great if
> someone can point me to either a github example of this specifically with
> the iOS client implementation, a blog article where it explains the exact
> url in which the iOS has to generate, and any/all of the 1-4 questions I
> have above. I'm having a hard time synthesizing all the examples into what I
> want. Thanks for your help in advance.
You are going where very few people have gone before, or at least they
don't talk about it, so thanks for the questions and I hope I have
been helpful, if we get it working, I'll try to blog about it and
include a working example (it would really help me if you can post a
sample with the rest part of it (even the skeleton).