Okay, so for week six, I learned all about a click modular router, but before I talk about this software router, let me just say that technology is scary! Technology is advancing every single day, and with every day there are improvements to daily things that leave you speechless! You end up with thoughts like: “how did they do that? and “how is that even possible?”. This is exactly what happened to me during the presentation. I had no idea that a click modular router was even possible. I grew up watching the cable company come into houses installing their routers to connect to the internet, but now it’s finally time to let that go. Out with the old and in with the new! With these new software routers, you can easily customize and modify them to fit your likes, since it’s not being controlled by companies. The purpose of the click modular router is to be able to make any linux computer a router! How amazing is that? You don’t have to buy these expensive routers anymore and you definitely don’t have to be calling the company of the router to help you with troubleshooting problems. With the click modular router, you can easily implement it yourself, and tweak it to your needs unlike traditional routers who hide the low-level software from the user and limit the control you have over it’s configuration. I think I find this topic about software routers very interesting because it’s written in C++. Since, I already know C++, understanding the nature of these new routers, and how to install and implement them isn’t something out of this world. I truly believe that some day in the future, these click modular routers will replace the traditional routers to the point where everyone will start questioning why they haven’t switched to these new software routers earlier!

After giving it some thought, and asking some friends, I figured out a way to fix the problem I was having during week 5, but before talking about that, I have to talk about an important step I was forgetting. Without this step, how can I even think of sending a sticky note. I was getting so ahead of myself, that I completely forgot about the most important part: the list of files the user can select from! Without showing the user a list of sticky notes he/she currently has on their phone, how can they possible even send it? This is when all the problems started occurring. For starters, the most puzzling decision I had to make was whether to create a new list view activity to show all the sticky notes saved to the phone, or to simply use the one I already had and make changes to it. Now, the hard part about making those decision was the nature of interactivity the user has with the list view. My application has the list view registered with onClickListeners that is fired when a sticky note is selected, so the sticky note is then opened in a new activity in a full screen mode. I also have a contexual menu, so when you long press a sticky note from the list, it will show a popup of different options; however, I don’t need any of that functionality for sending it to another device. If I reuse the list view I already have, I will have to de-register the listeners I have and create one that will implement the sending using Wifi_Direct instead of opening it in a full screen mode. This felt like over-kill for what I wanted to do, since I don’t have enough time to fret over simple details like that. Maybe in the future I can change it and work on reusing the list view I already have, but with the time constraints I have, I felt that the easiest way was the best, and the easiest way is of course just creating a new list view with its own properties.

After I finished the second list view, I was finally able to work on the Wifi-Direct aspect of my project. Now After both devices were paired and connected to one another, the second list view will appear allowing the user to select a sticky note to send. Now it’s time to go back to the hardships I was facing with the actual implementation of Wifi-Direct. The sad part was that I still didn’t know the best way to go about doing that. Considering the way I implemented the host side, the receiver (host) will have  to save the .txt file, and then search for the actual file that has been saved, and if it matches the title of the .txt file sent, then it will open it. That’s the way I tried doing it, but the problem with that is that all of this is happening in a different thread, so I can’t save the title or information inside a bundle or shared preference since it cannot be called within a static function. So for example, if I save the information in a shared preference or a bundle and I commit it, then when I go to retrieve the content, it still hasn’t been created since the other thread is running parallel to the current one. In order to save the information, I will have to come up with a way to either slow down the other thread (which is not efficient, and may cause future problems) , or try to save it after the code has ran in the other thread. However, Using this method raises another problem because the other thread is what handles the renaming and sending of the actual sticky note. If I try to save the information to access in the main UI thread, the parallel thread never sees it. After messing with the code I was able to send the file successfully but the sticky note would not have the appropriate title and application would crash on the receiver side. This, however, was a problem I had to face in the next week. Hopefully all goes well in week 7!