Deacon Demo App: Prettied up and Ready to Rock
For quite a while (read: since October) I've been meaning to spend some time improving the Deacon demonstration application. What we had before was OK - it connected to the Deacon test server, showed some messages coming in, and generally indicated that something was happening behind the curtain. But I wanted to add more configurability, and more visibility into Deacon's state. Most importantly, I wanted to switch to running Deacon in a service, rather than within the app's user interface activity.
With the 1.0 release of the Deacon Demo app, you can choose the channel to subscribe to on the Deacon project's test server, as well as stop and re-start the Deacon instance. Icons and text indicate whether the Deacon instance itself is running, as well as whether the device has a network connection. If you navigate away from the Deacon Demo app's UI, the corresponding service will create a notification if any push messages are received that contain a prime number payload - clicking the notification in the pull-down list will bring you back to the Deacon Demo activity.
You can download this app directly from GitHub using the QR Code below. Make sure you have the "Unknown sources" checkbox ticked in your device's Application Settings!
Please log any problems you encounter, or feature requests, at the Deacon-Demo issue tracker. For a look at the source code or more project details, check out the Deacon Demo GitHub project page.
January 12th, 2011 - 06:31
Hi David,
nice new app demo. Thanks for further developing.
I have a questition to you, what is about scalability of deacon, can we use multiple server and implement any load balancing service? I am looking for a while for a really performant push service. It has the following requirements:
- 50.000 – 100.000 notifiers (push) at the same time
- update interval ~ 30min
- data length ~ 1 Byte (1 or 0 to safe resources) + protocoll overhead
Do you think that is possible?
regards
René
January 12th, 2011 - 07:52
Hi Rene-
Thanks for your interest in the Deacon Project. Since Deacon is only the client, the scalability of the system depends largely on the Meteor web server. Since Meteor just uses TCP connections carrying the HTTP protocol, it should be operable with the same load balancing and performance techniques that are commonly used with other high-traffic applications. The issue of capacity and scalability has been raised in the past over on the Meteor Server Mailing List, which is a good place to start.
This is not the first time that this question has been raised, and I’m beginning to think it might be valuable to develop a scalability test for the Meteor + Deacon combination. It would be fairly straightforward to write a Java app that instantiates a large number of Deacon instances and connects them to a server, then measures push notification integrity (i.e. whether the push comes through at all) and latency (i.e how long it takes). The results could then be plotted (and blogged). I will look into doing this when I have some time available. Granted, it would be a limited simulation because all connections would be from a single host, but it would be a valuable to establish that an application such as yours is at least feasible.
Regards,
Dave
January 24th, 2011 - 09:31
Hi Dave,
Congrats for your work on Deacon, I think it’s a great solution.
I wanted to ask you what’s the best current solution, if any, for handling a connectivity loss with the server, whatever the cause is, as I see some problems with Deacon not reconnecting automatically.
Thanks,
Xavier
January 26th, 2011 - 15:47
HI Xavier-
Thanks for your enthusiasm and for trying our Deacon. Deacon should automatically handle connectivity changes, whether due to network conditions, disconnects by intermediate hosts (such as mobile network routers), network provider changes (such as from 3G to Wifi, etc) or mobile network status changes (i.e. wandering outside coverage areas). It differentiates little between these, except that in some cases the device’s network stack notifies Decaon (via a broadcast intent) that the network is down or up, and in other cases the connection is lost and Deacon simply tries to re-establish it. Meteor’s long-polling protocol is designed to minimize server load due to the zombie connections that can sometimes occur in the later situation.
If you can repeatably cause Deacon to fail to reconnect, please log a bug in the Deacon Project Issue tracker – this would be enormously helpful to the team! If you have any suggestions on where Deacon might be improved to eliminate the bug, these are also welcome and very much appreciated!
Regards,
Dave
September 4th, 2011 - 04:45
Hello Dave,
I build a push notification service using meteor and deacon which works very well untill droid v2.3.4 came along. On v2.3.4 after starting the app there is a first connection but that gets dropped after a short while and then Deacon fails to reconnect, no matter how long you wait. The same app is working fine on droid v2.2. Is this a known issue and is there a solution or workaround available? Appreciate your response.
Kind regards,
Franklin
September 4th, 2011 - 07:39
There has been an issue recently submitted for this behavior. It is under investigation; please submit any further information you have on the issue tracker: https://github.com/davidrea/Deacon/issues/8
March 14th, 2012 - 14:56
Hello first thing i’m sure that Deacon will be the best choice for my Graduate project.
second thing am new to android development
thierd when i clone the project from Github and import it to eclips i get an error message :
Project ‘Deacon-Demo’ is missing required Java project: ‘Deacon-Demo’
So does anyone got this problem?
March 14th, 2012 - 21:25
Muhmmad – Try doing a “clean all” on the project, and double-checking the include paths to your Android platform directory…