1.6 Second Iteration

For iteration two:

• Identify a new core functionality of my system.
• Present a live demonstration of this functionality.

Risks:

There are no real impeding risks in this iteration. The main "risk" would be time. As I am under a deadline for this iteration, I need to make sure that I do not make the same mistake in iteration one in regard to the back-end. This new back-end needs to by maintainable and more importable, compatible.

My core functionality, like initial iteration was to establish a back end. I decided that I would also set up my basic architecture of my project and have all suitable components communicate between one another.

After the first iteration, I learned that my initial resource for storing data in the system was not universally compatible with the majority of the technologies that I had intended to use in my project. This was a risk that I had noted in my first iteration. Therefore, I went back to the drawing board, and my drawing board I mean Google. I began to research other technologies that would suit my needs. The two technologies that I seemed to encounter over and over again were Asp.net and AMP (Apache server, MySQL, PHP). In section 1.5, I discussed the pros and cons of both technologies. However, I decided to adopt Asp.net to manage and set up my new back-end.

 Using a "Code First" approach, I set up my Db-context class. This class is used to model and generate real database tables in my back-end. Using Entity Framework along with asp.net, the two technologies are able to generate actual SQL tables in my SQL database which is hosted on Azure. For this iteration, I created a single "Employee" table. The table contained basic attributes of an employee.

Furthermore, I also configured a basic REST service using Asp.net. The purpose of this service is to allow the Android application to make GET calls to the service and retrieve data that it use in the application. Using a REST GET call, the service would return a list of employees in the database formatted in JSON. The service was then hosted with Azure, allowing the service to be accessed over the internet and not longer running on a localhost.

The next step was figuring out how my basic android application could make one of these API calls to my service. After some extensive research, I discovered that Google had developed a framework that allowed android applications to make API calls easier to implement. This framework is called Volley. Using this framework, I was able to make a basic GET request to my service, store that response in a String value, and then set it into a textview in android.

Pretty cool huh?

After meeting up with my supervisor, I presented a small demonstration. It was all very successful but more importantly, it helped identify what needed to take place in iteration three.

References:

http://developer.android.com/training/volley/simple.html