First of all: This is completely off topic and has nothing to do with GoodNews or uPod or even Android at all. This being said I wanted to let you know that I am looking for a few Java/Scala-Developers to join my team at Beta Systems in Berlin. We will develop the next generation Web UI for our enterprise applications. So if you are a developer and you are looking for a new challenge or if you know someone how might be interested, please read the full job offer and learn how to apply.
Archive for April, 2013
Though the first release of the uPod app is still far away, I wanted to use the opportunity to let you know about the progress I am making. As I’ve already have a quite complete idea of how the user interface will look and work like I’ve decided to develop the app bottom up — meaning I start with the storage and synchronization stuff, so that I can use real data when working on the user interface. This also implies, that it will take some time until I can provide you the first screenshots of the app.
Today I want to tell you a little bit about the uPod service. Though you will never see it when using the app, it is a very important part of uPod. As a former user of Google reader and an owner of an Android phone and tablet I want to have full synchronization across all my devices right from the beginning. For example at home in the evening I want to use the big screen of my Nexus 10 to scan through new podcast episodes and add them to my library and playlist and when I am on my way in the morning I want to listen to this playlist on my Galaxy Nexus.
To make this possible my subscriptions, episode library and playlist need to be stored in the cloud and my devices need to synchronize with this stored information. And this is where the uPod service comes on to the scene — it will be running in the cloud and store all the information required by my devices including my subscriptions, my library, playlist (including episode ordering) playback positions and general listen preferences. The service is also responsible for checking the subscriptions of all users for new episodes and pushing them to our uPod inboxes. Keeping this logic on the server helps to reduce the synchronization logic and the amount of data to be transferred during a sync on the mobile device. Finally the uPod service provides a web service API which is used by the uPod app to access all the required information and push back changes.
Now you may ask how the authentication against the uPod service works? That’s simple: When starting the uPod app for the first time you will get an account picker providing you all your google accounts. Simply select one of them and all your uPod information will be linked to your google account — no need to create another account and select another username and password.
The good news is that the implementation of the service is nearly finished and it is working well. For the developers among you who are interested in the technical details: The uPod service provides a REST like web service API and is implemented using the programming language Scala and the Play 2.1 framework. MongoDB serves as the storage backend for the service.
Next I will start working on the uPod app, starting with it’s storage and synchronization layer. I guess it will require a comparable effort like implementing the uPod service. Stay tuned!