So after talking with matzew for a bit, I've put together this list of
things that need to be done on Android to have a good push experience
(for the user). My goal is that we discuss these things to inform a
(eventual) push client spec.
1) Gobs of XML Boilerplate.
the Android manifest needs permissions and uses permissions stanzas
as well as defining the Google Cloud Message receiver. *We should
probably have tooling which does this for the user*
2) A Intent handling Service.
This Service class extends *GCMBaseIntentService*has three
responsibilities, *Registering* clients, *Unregistering* clients, and
I would prefer developers not have to extend this class, but that is
a talk for a different day.
3) Some utlities for handling/parsing/routing notifications to other
bits of code. Again, this is a talk for a different day.
Here is a link to a class based HEAVILY on Google's Service Utilities
class from their demo apps
while evaluating the PicketLink IDM for our "storage" requirements (see
older emails), I started writing a Java EE version of the
AeroGear PushEE -> https://github.com/matzew/pushee
(Dont' worry to much about the name :) )
Compared to the vert.x version it's using a more complete/richer API (real
classes, instead of a large JsonObject). Also it has slightly more of an
(abstract entity base class, DAO access for all the entities, services
accessing the DAOs, RESTendpoints simply accessing the services).
Oh, also, the "iOS" variant is now supporting a _real_ upload of the
certificate (stored as Lob)
I tested the WAR file, on my private OpenShift Account (with the JBoss
7.1.x config there), afterwards I tested the messaging:
I could send message to my iPhone and to my Android device - so the
Openshift cloud does NOT permit connecting to Apple's APNs (and Google)
* All "beans" are JPA entities
* No IDM integration, due to the IRC suggestion to simply model the beans
==> However, since the Database for the push is a _standalone_ thing, and
there is no real user (just an optional "client identifier"), this means I
could move the "beans" and store the in IDM
Regarding IDM, please review also older threads regarding this, on the ML
I am Nityata Nagendra Kumar. I'm a grad student in Information and Computer
Sciences at UCI. I'm very interested in the Mobile Document Collaboration
App. I have been an avid mobile and web apps developer along with interning
at a startup CloudMPower Techonologies where we built applications using
PhoneGap, JQuery Mobile and HTML5. One of my web app projects has been made
open-source and can be found here <https://github.com/nityata/Edu-Corp>
I wanted to know the work that I could begin to make my proposal stronger.
I'm really interested in this project and look forward to contributing to
Hello, guys! My name is Eugene Nazarchuk, I'm a postgraduate student
Research University of Information Technology, Mechanics and Optics in
Saint-Petersburg, Russia. My colleague, Dmitry Zamula (
club.brantner(a)gmail.com) has already written a letter to Mr. Jay Balunas
about the project of mobile document collaboration app.
I have about a year experience in enterprise software development using
experience in enterprise development (also java) and works on his own app
for Phonegap platforms. We are interested in project of mobile document
collaboration app because it uses advanced mobile technologies. It's a good
opportunity to get a lot of experience in this area.
Today we've spent some time developing a prototype of that application. Now
it has a functionality of concurrent editing of a document by several
clients and some base document markup. All communication with server goes
through web sockets. Client is implemented using Phonegap. Prototype is
pretty raw but it helped us to pinpoint main difficult parts of the system.
First of all is lack of support of websockets in android (and integration
of existing websocket libraries with Phonegaps API). Also the task of
markup the text is not so easy, because the majority of WYSIWYG editors
aren't adapted for mobile devices. In particular we faced the problem of
positioning the caret while other clients are concurrently modifying the
In current prototype we intentionally used not very optimal algorithm for
transferring document changes between clients, because we just wanted to
roughly estimate the whole scope of work.
In the project description there is a mention of Aerogear framework. As far
as we understand it does not support websockets right now. So we have a
question: will this functionality be implemented soon, so it can be
integrated in the project?
We are glad to answer any questions about us or the prototype. We can
expand its functionality, if necessary.
Eugene Nazarchuk (megistion(a)gmail.com)
Dmitry Zamula (club.brantner(a)gmail.com)
mobile client - https://github.com/Brantner/mdc
server - https://github.com/Brantner/mdc-server
the server is deployed here - http://mdc-brantner.rhcloud.com
We cannot provide a compiled version of the client, because it doesn't work
for android right now (lack of native websocket support) and must be
compiled for iOS using UUID of the particular device it will be used on.
Right now when a user calls logout on the HttpBasicAuthenticationModule
the library clears all the cookies for the URL the module providing
Is this correct? If not is it correct enough? How is everyone else
handling log outs and cookies?
So I've gotten a draft of the Pipe document up.
Some things I would like to call out and discuss include
1 ) Pipe implementations should be thread safe. Specifically calls to read, remove, and save should not change the internal state of a Pipe object.
2 ) Pipeline.get is not guaranteed to always return the same instance of a Pipe.
This is something that came up with Android. Loaders are 1:1 on the Activity or Fragment which references the Loader. Therefore if a Pipe is reused between multiple Activities each one is proxied in a different Loader.
3 ) A Pipe may proxy or delegate to a handler and this handler can be exposed as a property.
This is an Androidism as well. I think it can probably be dropped from the spec but I wanted to see what other people thought about it.
Some things which we may need to flesh out to make the spec more complete are
1 ) Authorization and Authentication. This is probably another document
2 ) A callback spec/definition. I am not sure whether this is a separate document or not. Either way it should be short and sweet.
writing this email to describe the issues I faced with the current iOS API trying to add a paging test case for Reddit and the changes I made to support it.
To explain better I will start with the reddit response:
Currently in the iOS API with our default paging mechanisms (body and header), we don't support page parameters to be deeply nested in the body. Here the "after" and "before" params reside nested in the parent "data" element. Further, the value of those parameters are not 'query params', just simple strings pointing to the next and previous page.
For the Reddit case and for others that may come in the future which may have "unknown" paging mechanisms, I followed the approach Android does and introduced a PageExtractor interface. It's only purpose is to parse the appropriate content and return us with the "next" and "previous" links. Existing header/body mechanisms were refactored to separate classes that implement the PageExtractor interface. Further an additional configuration option in the PipeConfig was added [setPageExtractor] that set the appropriate extractor class.
Important to state is that this config option is entirely optional. Internally if not set, we will still use the appropriate page/header mechanism (still depending on the metadataLocation config option). Having this option will allow different and "exotic" page extractors to be plugged in by the users if necessary or if not still rely on our defaults.
You can see the Reddit page extractor in the test case here
Reddit authentication relies on setting more than one headers in the request, named "Cookie" and "modhash". The way these headers are set :
--> client issues a login request
<-- reddit responds with 'cookie' and 'modhash' elements in the body of the response
The client then post process the response. That is, it creates two headers, the 'Cookie' header with the value prefixed to "reddit_session=<cookie value from the previous step.>' and the 'modhash' from the previous step.
Our existing AGRestAuthenticator couldn't support this. Here there is more than one header returned in the body of the response and further it requires a small post-processing on the 'Cookie' element to add a 'reddit_session=' prefix. In order to support this, a new AGRedditAuthenticationModule was created that follows the AGAuthenticationModule interface. You can see it here
I've seen that a similar approach is followed in Android too.