Future Path - JayThomason/Tutti GitHub Wiki

We have several future steps to complete as we move forward with this project:

Master UDP Broadcast

  • Our most immediate goal is implementing auto-discovery of nearby Jams. As of right now we are planning to do this using a UDP broadcast sent from the master phone. We also considered using centralized servers on AWS or a P2P architecture for discovery, however after an in-depth discussion we've decided against it (see pros and cons list below, as well as closing comment on https://github.com/JayThomason/Tutti/issues/68). A simple example of UDP broadcast code on Android can be found here.

Debating pros and cons of different network architectures Debating pros and cons of different network architectures

  • Below is a more detailed sketch depicting how UDP broadcast will allow us to perform service discovery. In short, each phone hosting a jam will regularly broadcast a message with information about the jam, such as the phone's ip address and port. A client phone that wants to view local jams will just bind a listener to a UDP socket and wait for incoming UDP packets containing jam information. The user will just select a jam that he/she wants to connect to; there will be no need to enter a jam-specific ID or IP address.

More detailed diagram of UDP discovery and Jam syncing with more than 2 phones More detailed diagram of UDP discovery and Jam syncing with more than 2 phones

  • Our second step will be to get the application working over more than just two phones. If we are successful in using a UDP broadcast for jam discovery, then we will just continue working on expanding the phone-to-phone HTTP API. We'll focus on scaling it to work with n phones, where n is some number of phones that we determine can all use the jam at once without our architecture becoming a performance/UX bottleneck. This will mostly involve keeping track of all the phones connected to the jam and writing more code to synchronize changes made to the master phone on all of the client phones.

Whiteboarding designs for network architecture Whiteboarding designs for network architecture

  • Decide on a final design for our UI and continue to make it even sleeker: So far, we have been going with a black/red/silver color scheme. We like what we have, but still want to consider other possibilities as we eventually decide on our final design. Therefore, we want to spend some time designing a few other color schemes/layout possibilities, just on Photoshop/Powerpoint, not even in code. When we decide on what we want our final product to look like, we can then code that in. In addition, we have a sleek-looking main menu with cool custom 3D buttons, but there's still more to do. The rest of the screens follow the same color scheme, but are pretty basic with their ListView layouts and buttons. We want to decide exactly how we want those screens to look and make them look even better.

  • We also want to add in some more music player controls:
    We want volume control, dragging to the middle of a song/showing a song's progress, shuffle vs loop, reordering songs in a playlist, and possibly album artwork shown as well. We also potentially want to be able to control the song from other screens besides just the View Jam screen. Perhaps when adding songs to the jam, you should be able to view the music player buttons at the bottom of the screen. Finally, we need some kind of "View Current Jam" button, so that from the main menu, you can view the jam you are currently a part of.

  • Add custom modes: Once we get the basic functionality working, we want to add a few custom modes. We still want to maintain simplicity and ease of use, but one thing we would like to add is the ability to create a new jam from an existing playlist. A lot of people have existing playlists saved on their phones, and instead of starting a jam from scratch, it would be nice to be able to start with a playlist you already have. So we are thinking of having a Quick Jam mode, which just starts with a blank jam, and a Custom Jam mode, where you can start from an existing playlist. Along the same lines, we want to implement some Settings, such as a public or private playlist. Perhaps a public playlist could allow you to join anyone's playlist without requesting permission (ideal for a larger group, like a bus ride or something), and a private would require requesting access.