Pushing messages to connected clients has always been a need on the web, growing with the apparition of new Rich Internet Applications, like realtime feeds (Gmail, news, market quotes), social feeds (The Twitter, Facebook and consort) and many other providing realtime collaboration, monitoring and control like new Internet of Things applications (FlightRadar24, Arduino #1, #2).
Comet technics (ie. polling, long-polling, streaming) and more recently, the WebSocket protocol, have made possible various webpush applications.
Today, when you want to enable realtime push on your own Java-based webapp, you have several solutions:
Use an externalized system that will handle that for you (like Pusher), avoiding you the providing of any additional server
Use a commercial solution (like Kaazing or Diffusion), generally implementing a Message Broker underneath, with both embedded and standalone server
In this article, I will focus on Atmosphere. After a brief presentation of the framework, I will demonstrate how easy it is to make push-capable applications, whatever the container you use and the nature of your clients.
Before we start, you can take a look at the following video, that demonstrates what I achieved thanks to the Atmosphere framework (more details below, of course):
I just migrated my website (the one you’re reading actually!) from www.colomern.net to the new URL www.ncolomer.net. Normally, you should have felt no difference thanks to some tips gleaned here and there on the web.
My first approach was to put a custom index.php file on the old domain that permanently redirects all root requests to my new domain:
But what about the old URLs that map my blog articles, the one that was indexed by Google? In a such situation, the best way to do the least possible harm (ie. do not lost SEO robots) is to redirect all old URLs to my new domain. This can be done using a simple .htaccess containing the following:
RedirectMatch 301 ^(.*)$ http://www.ncolomer.net$1
In my precedent blog post, we introduced the way to install and start playing with Redis. Now, I propose you to go further, with a more advanced use case. In my personnal project development (f.ollow.us), I faced a new problem:
How can we manage efficiently a fixed number of “slots” that have a TTL (i.e. Time To Live) and can be held (i.e. be available or not) in a high concurrency context? Don’t look further, Redis is the solution!
Redis is a – take a deep breath - nosql key-value in-memory storage system, also called memcache. It is written in ANSI C and works in most POSIX operating systems. Its features are numerous: high perf, on disk persistence, replication, pub/sub and TTL (i.e. Time To Live) to name a few.
The community around Redis is very active, resulting a lot of client for many languages: Java, Node, Ruby, PHP, etc. On this post, after a brief “How to set up Redis”, I will focus on one of the most active Java API, Jedis.
The price of HDD declined significantly last years. Today, you can afford a 2TB one for less than $100. Why not take this opportunity to increase the capacity of your Time Capsule?
For that matter, prefer a silent and energy efficient HDD (e.g. “green” products from Seagate, Samsung or Western Digital). These HDD rotate more often at 5400 rpm. That’s enough to do daily backups (not so IO intensive).
Here is a step by step procedure to change your Time Capsule disk in no more than 15 minutes!
OpenStreetMap (i.e. OSM) is a community which creates and provides free and open geographic data. The project started because most available maps, such as Google Maps or Bing, have legal or technical restrictions on their use: lot of content are not exposed due to copyrights, belonging to mapping companies (e.g. NAVTEQ or Tele Atlas) or national agencies (e.g. Ordnance Survey or IGN). To see how rich is OpenStreetMap data, you can have a preview via the ito! map project.
The main feature of OpenStreetMap is to provide a map, as Google do. You can access it on there main site or embed it in your own website. But you can also access OSM data in other ways than viewing them in a browser…
To start using Google Maps on your Android application, you need no more than a MapView and some GeoPoint. Nevertheless, in order to show map tiles loaded and drawn on your Android application when debugging (on AVD or phone), you’ll have to obtain a Maps API Key.
The procedure splits in three steps:
Obtain the debug certificate (official procedure here)