Week 5’s lecture on routing and transport was interesting but didn’t really leave a huge impact on me like the previous weeks. Probably because I still haven’t switched over from the current network model we use today to the mobility first one. For starters, the idea of being able to communicate with other devices without having an internet connection is incredibly absurd! I feel nothing but admiration towards the ones who developed and are still developing mobility first. They are trying to create a movement that will undoubtedly shake the whole world! During the presentation, however, there was one topic that actually got me a little bit interested.The whole idea of sensor networks and how they are used in real world scenarios. The example used in the presentation was volcanoes. As soon as a volcano is ready to erupt, the sensors, or nodes, detect the vibrations caused by the seismic event and send them to the main device, or base station, which is being monitored by scientists to record the data being received. The problem with these nodes is that they have to run on battery, since there are various factors that prohibit people from changing them such as the amount of danger, cost, time consumption and the distance, so the network may get partitioned when a lot of the sensors run out of battery. Using these sensor networks, scientists are able to figure out when a volcano may erupt before it actually does, which, to me, is just plain awesome!

To be honest, even in week 5, I still didn’t have a concrete understanding of how to use Wifi-Direct. It’s been two weeks since I started messing around with the Wifi-Direct API’s and source code, but I still didn’t know how to use it to work with my app. I knew  how to create a simple chat application using wifi-direct but that’s about it. The problem was learning how to change the type of data being transferred. For my application, I had to find a way to send the sticky note across the another device, but there was nothing online to serve as a reference. So for about half the week I was focused on breaking down the sample source code that android provides. I added debugging logs everywhere in the code so I can understand what exactly is happening and when. With only two days left until week 6, I finally figured out how everything was tied together. It was finally time to start working on my application! The first thing I had to do was to try to connect to another device via Wifi-Direct. Even though I spent so much time reading through the documentation and everything, when it was time to actually implement my own code I was completely lost! So for the rest of that day, all I did was mess around with code to see how it fits and reacts with my application. Finally the last day of the week came and I still didn’t have any concrete work done! Finally, At the verge of despair, my cousin came up to me and said: “Why don’t you just use the sample code from the android website as a placeholder to build your app? After that you can stress on how you can change it to fit your needs”. As soon as my cousin said that, I felt so dumb! Why didn’t I think of that sooner? I wasted so much time on trying to build my own foundation, when in fact it was already built for me! Okay, so for the rest of the day I worked on making the android sample program work with mine, which was an obstacle in itself, but after countless hours of learning what goes where, I was finally able to piece them together! So, when a user clicks on “Share with friends!”, it will switch to the Wifi-Direct activity where it will connect to other peers. The first picture is what happens as soon as you select “Share with friends!”, and the second one is how it looks when another device becomes available to connect to.

After Selecting another device it will pull up a view with specific details about the connection as well as information about the device itself with two buttons allowing the user to either disconnect or select a sticky note.

After the user selects “Select Sticky”, the app crashes. It took me a while to figure out the problem. It just so happens that the program was trying to open any type of file, instead of the actual sticky note, so it didn’t know which file was trying to open, hence the crash. I had to deliberately change the mime type as well as make a few changes to the client code, to make it receive the sticky note. Just when I thought the code was perfect, it crashed yet again! After putting logs everywhere, I came to the conclusion that I could not send sticky notes, since the application did not know what a “sticky note” was. It took me so long to figure out the answer, even though it was so simple! The sticky note that I am sending is simply a .txt file, so instead of sending the “Sticky note”, I just have to send a .txt file to other device. Now this is where it starts to get complicated. In order to successfully send a .txt file is pretty easy, but I have to send a “sticky note” that is completely the same as how the user last had it. For example, if I create a new sticky note, and add a title and some content to it and I save it, I want the user to receive it the same exact way as I have it. Now my first thought was sending an empty .txt file, then populating it over at the client side, but thats repeating a lot of code and breaks the very first rule every programmer should follow: DRY (Don’t Repeat Yourself). Aside from breaking this rule, it wouldn’t every efficient. For the rest of the week, I focused on coming up with an idea of how to handle this problem. I even went out to staples and bought a white board so I can write pseudocode and draw diagrams to help organize my thoughts. Hopefully in week 6, I will have thought of a way to address this issue in a proper and efficient way.