Efficient design for a auto refresh mobile app

Question

I was presented this problem few days back. Requirement was to design a mobile app which serves sports content to the user (say soccer). The app will allow the user to subscriber to specific team. Based on user's team selection, the apps serves only content related to that team on the user's home screen. Of course user has option to see content for all teams (via menu options).

Special focus was on how would the content on user's home screen get refreshed automatically and should also take into consideration that user has (or has not) subscribed to a specific team.

To the last question, I suggested following 2 solutions:

1) The app can send tiny requests to the server which would only contain user's identifier, user's team selection. Based on the team selection in the input request, the server would return only the content related to the team.

2) If the content volume is less and the number of distinct teams are few then broadcast all the information and let the app do the necessary filtering (of course this is less efficient compared to #1).

Sharing this on forum to get other possible design decisions. In case this is not the right forum, please answer in comments and I'll post in appropriate forum.

Thanks

Phlegmy

Answer 1

Basically when you want to do an auto-refresh system you have only two way :

1 : The client send request(s) periodically. This is enough if :

1. The interval of refreshing is not too short
2. You don't expect your application to run for millions of people
3. Computing the result don't cost too much

This can be implemented with just a naïve use of some query on a database server-side. Of course if you need some more performance you can have some intermediary layers.

2 : Pushing result from servers : this is a bit trickier to architecture properly but here is somme good points :

• You send only new data to clients
• Performance wise it's the best

However the limits are more important :

• Handling lost of connexions is a bit harder
• You need to catch every events that update the datas in order to push your refresh to the clients.

But because there are more than you that need this architure solution exists : here is the one that fits the best for you in the Javaworld :

JMS : Java Message Service, which is a Message Oriented Middleware (MOM).

JMS is a specification with different implementation, personnaly i would go for activeMQ which is the Apache one. Here is a topic about that : Which JMS implementation do you use?

If you don't/can't use JMS then just remember this : Messare-Oriented-Middleware. Google that should help you to find what you need.

Mishnah

Answer 2

Definitely option 1).

We developed something similar in other industry where users are interested in getting information about states of different resources. The architecture is like this:

1. Server keeps all users subscriptions. That's where you keep things like: SubscribedUserId, EventType (win, loss, numberOfPointsChanged, all, whatever the case might be), deliveryChannel (http notification, email, push notification for mobiles)
2. Whenever something happens with the resource, we put message in a queue. Message contains things like: teamEventIsFor, subscriberUser, deliveryChannel, deliveryAddress, etc...
3. Separate windows service(s) (one that handles all deliveryTypes [email, http, push] or one for each channel) consume queue messages and deliver actual content to users. In your case, it would be through push notifications.

Now, having on mind that push notifications are not guaranteed delivery (although you get pretty good delivery rate overall) you might also want to implement some kind of a http resource where mobile app could poll from time to time to check if there are some news for that particular user (that's optional).

Verrazano

Thanks for the response. I'll start the bounty so we can get more comments/responses. – Phlegmy

Answer 3

You have a third option:

3) Follow a publish-subscribe pattern.

To implement this you could use an system such as Amazon Simple Notification Service (SNS). First you would need to set up a platform application containing your API key (for Android) or private key and APNS certificate (for iOS).

When a user starts your app for the first time, the app would ask the user to authorise push notifications access, contact your server and send a token (which is used to register an endpoint on the SNS platform application).

This allows you the ability to send push notifications to the app running on the user's device (which can be handled silently, or be displayed as a real time notification that there is new data available).

You can then set up Topics for each team, that a given user can choose to subscribe to. When the user selects a team, the app sends a request to your server to subscribe to the topic, which you forward to AWS using their API. If a user wants to unsubscribe from a topic you once again forward this request to AWS.

This allows you to send updates for each team to the appropriate topic and have this information distributed -only- to users who subscribe, scalably, and in real time. Your server will only need to ping the topic once and AWS will handle delivery to each user.

Of course, you will need to implement logic to handle the notification, subscribe, register etc. but it does allow your users to receive updates in real time.

Reviewing your options:

1) Easiest to implement and probably necessary for new installs who have not yet registered. You will need this either way so I would recommend you implement this method initially. Your servers will be under load proportional to users however so it would be worthwhile to consider option 3) as you scale (and using a HTTP cache such as varnish or squid to minimise compute and database load)

2) It's not necessary to broadcast this information to -all- of your users but it is effectively publish-subscribe with a single topic (all users). It would be more efficient to only notify users that care.

3) This is the most scalable option and has the added advantage of being real-time. You would be able to notify the user of an update even if they are not using your app at the time. Under a publish-subscribe architecture you will we able to notify only the users concerned with your information, and once updated you can set a timeout value that prevents the user updating from your server until XX time. This way if updates are more frequent than your timeout value users will never need to hit your server.

Sandysandye