What I don't understand is why the smartphone is the <i>server</i>. Naïvely, I'd expect the server to be the Raspberry Pi, and for clients to be the smartphones. Clients connect to the server and push content which the server displays on the screen. Something like X11, in other words. Looking at what the application does, I don't even think it would be that difficult to convert it to an architecture like what I described above - in essence you'd be reversing the arrows on your interaction diagram.<p>Can you elaborate as to why you built the server on the smartphone rather than Raspberry Pi? What does that get you? How do you get around the limitations that phone operating systems (especially iOS) impose on background processes? What's the impact on battery life?
We explored ideas around this space at Emotely and Brass Monkey. There is much yet unexplored. This approach basically gets you a WiiU/Chromecast second screen platform:
<a href="https://www.youtube.com/watch?v=NE8-TntjYB4" rel="nofollow">https://www.youtube.com/watch?v=NE8-TntjYB4</a>
<a href="http://francoislaberge.com/blog/my-time-at-brass-monkey/" rel="nofollow">http://francoislaberge.com/blog/my-time-at-brass-monkey/</a>
Built something like this at YC Hacks, except any device or even a webpage could function as the server and provide a real-time or REST interface. We had 5 demo apps showing off various examples, including a super cool two-factor auth demo..<p>Trying to explain the concept to people in 30 seconds was non-trivial.
This is neat. I have a hard time thinking of uses off the top of my head, but the idea of a no-installation phone-paired TV app has potential.<p>Thoughts of <a href="https://youtu.be/_mjxd47OVUI?t=57s" rel="nofollow">https://youtu.be/_mjxd47OVUI?t=57s</a> go through my head.