Okay, so for week 1 I had to come up with an idea that emphasizes on the user being able to input a lot of text. Resumes, surveys and application forms seemed way too common, so I decided to create a post-it type of application. Starting off, it seemed really simple…but man, was I wrong! After countless hours of research I came to the conclusion that I am alone. Having just started the transition from C++ to JAVA, I had no idea where to start, and definitely not a clue on how to use the android API to start my own application, and to top it all off, all of the source codes and suggestions I found in different forums and community sites relied heavily on xml; however, for my application I had to use dynamic Java programming. Everything had to be decided at run time, since there is no real way to know exactly what the user wants. Finally at the edge of despair, I randomly got an idea–using EditText views with backgrounds to simulate the ‘effect’ of a post-it note! Okay, so my dim journey towards the goal of completing this almost-impossible app started! To start off, I nested a Frame Layout inside a Relative Layout to create this full screen kind of effect (obviously with the action bar present) and created two views: a Button and an EditText view where users can type into. I positioned the button on the top and the EditText view in the middle and it ran fine.

So far so good, but now I have to make the button create new EditText views every time the button is clicked. Looking through the official android documentation for any ideas on how to implement the code for when a button is clicked, I found some ‘listeners’ that didn’t look that hard to use. Okay, so I tried using a special listener called ‘OnTouchListener’, and then boom! I encountered my first problem. The listener uses anonymous functions! I have never seen that or even heard of it in my entire life. The scoping rules are different as well. After researching and having a better understanding of how anonymous functions work, I was able to somehow make the button create a new TextEdit view. It was created in the top-left corner of the screen and not in the middle like how I wanted to, but hey, at least it worked! After customizing the view by adding highlighting color, text size, view dimensions, and a function that randomly changes the background color, I ran into my second problem! This time, the problem was that when I clicked on the button more than once I just saw it change colors and it wasn’t creating different EditText views…or so I thought. In reality, it actually was, the problem was just that the views were being created in the same exact position. Now I think this was the hardest challenge I ever had to face in my life regarding code because I had to understand advanced concepts in a language I barely knew as well as the algorithmic thinking needed to implement the code and change everything dynamically in such a short amount of time. After 5 days, I finally figured it out and was able to change the position by using the top and left margins of every newly created view.

The homework assignment for week 1 ended here, but something about the way the app worked bothered me. After playing around with the code for a little bit, I asked myself: “What if the user wants to select one of the TextViews already created?”. This led me to the idea of being able to drag around every single EditText view. The problem here was that since every view was created dynamically, there was no way to refer to them using the common way of getting the id from an xml file. After looking through the android documentation some more I was able to figure it out quite rapidly, but now a new problem arose: how to use the motion event callbacks that are fired in the touch listener that I had implemented earlier to update the position of every EditText view as the user drags them along. After a whole day of playing around with the code I was finally able to move the views by dynamically creating new layout rules that overwrote the original ones and then adding them to the original layout along with the view resulting in the following screen shots:

Oh no! Not another error…I already had enough of debugging and dealing with the bugs and glitches android studio has, but little did I know that this problem was the biggest of them all! Just as I was finally happy that the dragging of the views worked, this error had to come along and sweep all my happiness away with this cruel–yet very serious–problem that will drastically affect the way users will treat this program. The problem was that every single EditText view was able to go off the screen! This is horrible and it’s definitely not going to be warmly welcomed by users. After using the little time I had left into researching how to retrieve the device’s screen dimensions, I only found one way but sadly it has been deprecated. There were no other suggestions or tips online nor did I manage to find anything relevant in the android documentation, so I will just leave it like this until I have some extra time after completing the next few weeks worth of homework! With that said, onto week 2 and the wonderful world of creating and switching between activities!