The 3rd Year Software Development Experience… Signed, Sealed, and Delivered.
The third year of software development has been a very entertaining year, out of all the years I have been in this box called University. In third year, students are tasked to form groups and create a fully working system. There have been many ups and downs, but I am glad to say I started well, and ended well. One thing that made the project module so cool was the freedom it gave students – we could pretty much build anything, and use any technologies as we see fit. Websites, desktop applications, and mobile applications manifested from this freedom.
I had been making preparations for the 3rd Year in my 2nd Year – I started playing around with Android, making simple, ugly-looking apps. At that point, I didn’t want to make hectic apps, I just wanted to familiarize myself with the platform – the real fun will start in 3rd Year.
When third year came, I knew I’d have no desire of play the game safely – If I wanted to be safe, I could have opted for creating some sort of web-based management system, using ASP.NET Web Forms. I wanted to do something different, in the context the usual 3rd year project. The people I joined forces with also shared this view; that we want to be different from the rest, and we want to use new technology. After much discussion and consultation with our project supervisor, we decided we would give birth to iBaleka, a Personal Fitness Journal.
iBaleka (pronounced eye-Baleka) is a system that fuses Athlete’s and Event Organizers into one generic solution. The athlete uses the mobile app to record their running activity – running activity can be classified as a personal run, or an event run. While the athlete is busy running, the mobile app will collect the athlete’s speed data, calories burnt data, distance data, and time information. This information is saved and then summarized in easy to read reports.
The Event Organizer uses our web application to create events (Eg: Iron Man, Spar Ladies Run, etc. ). With each event, the event organizer can create one or more routes – a full screen map is displayed to the event organizer where he/she can plot route checkpoints. Once they save the event, this information is available for athletes to see – the athlete views event information, and decides if they want to join the event. For each event, the event organizer can see how many people have joined the event, and view a little more information on each person (name, surname, etc. ). Event Organizers can create clubs – these clubs would then be available for athlete’s to join. We could have taken this idea way further, but due to time constraints, we kept everything standard.
This project idea stemmed from how I loved attending the weekly ParkRun’s (Sunrise-on-Sea) in East London. I saw how if I wanted to track my personal runs (running in the hood), and event runs (ParkRun, etc), this meant I would have to have separate apps installed on my mobile phone (Nike+ app, ParkRun app). Why don’t we try to create one solution for all parties?
Earlier, I mentioned how we didn’t want to play the game safely. After a quick meeting at the cafeteria, we decided the website should be built using Microsoft’s latest web technology – ASP.NET Core 1.0. As for the mobile app, we decided we would build an Android app. We could have gone other ways (using UWP, or Swift for iOS apps), but we decided Android is best… because I have some history with it (even though it isn’t too deep at this point). A few months down the line, we thought of building a standard Web API for the website and mobile app.
To host the website, the database, and Web API, we decided we used Microsoft Azure, because they had free options which supported ASP.NET Core. Despite the free options being a little slow, it was sufficient enough to get us through the year. As the guy who built the Android app, I am thankful my team went and built the API – it made my life so much easier, and made my code look a little classy 🙂 Within the Android app, here are some of the 3rd Party Libraries I used:
- MPAndroidChart – This is an amazing library which produces all sorts of graphs with ease. The hardest part was fetching the data 🙂 . For the sake of the 3rd year project, I kept these reports simple. I know if I were to do my own projects which needed complex graphs, I am gonna look to MPAndroidChart. I am thankful such a library exists.
- Retrofit 2.0 – Thank the Gods at Square Inc for creating such a beautiful, powerful and easy to use API client library! I love how I didn’t have to worry about going through JSON objects manually and making sure data is mapped correctly. I didn’t lift a finger when nesting List collections inside my model classes… Retrofit took care of this! All I had to do was add annotations to my model classes. Getting data in and out of the Web API was super easy! The only “complex” part was trying to make multiple calls to the API in such a way that each call is completed before moving on to the next call. I have honestly fallen in love with Retrofit… I found a link which goes in-depth with this Library… cannot wait to see what else Retrofit has up its sleeve! Volley can miss me 🙂
To get the search box working, I decided I would use Google Places API PlacesAutoComplete… it was a little tricky implementing this… I remember having a problem with the Android App crashing when the user navigated back to the search fragment. The solution was to use a <fragment> tag, then, when the fragment is fired up, use the Fragment Manager to load the PlacesAutoComplete search within the fragment placeholder. For search results, I made use of a RecyclerView and CardView to hold each search result. For the profile view, I made use of a ViewPager and TabLayout so I could have nice tabs at the top of the screen.
To calculate the calories burnt, I had to do a little scratching on the internet… I am not a mathematics wizard (I got 56% for Mathematics in high school 🙂 ). It was not long until I discovered these links which clearly explain how to calculate the calories burnt:
Getting the core of the personal runs, and event runs to work, took some time to do. I initially thought the best way to do these would be to use the Google Fit API, but, for some reason, things just didn’t work the way I wanted them to work. I have a feeling Google Fit works best with wearable’s (Fitness bands, smart watches, etc. ). I ended up using Google’s Location API, with help from their amazing documentation. With this API, the app uses the devices location data (through its GPS receiver) to get speed readings, distance, and height from sea level. The results from this approach were okay, not too bad and not super accurate. I could have used more sensors on the mobile device to get more accurate readings, but, to keep the project straightforward, I stuck with using GPS (with the help of an internet connection).
The only hack I am not proud of using, is using the Singleton Pattern to move data from one Fragment to another. Months after starting the project, I found there was a better way of moving data between fragments and activities… thank goodness I still had time to remove that Singleton business.
There are a few glitches here and there, but overall, the mobile app does what it needs to do without bombing out (That’s why I would shake a little on presentation days; I felt Murphy watching my every move).
Here are a few screenshots of the mobile app. To test the mobile app, I used both my Android Devices – I have an LG G4 Beat, and a Samsung Galaxy Note 3 LTE.
Here is the event run being demonstrated (video). Please excuse the heavy breathing, I had been dormant for months 🙁
As much as getting down to work is important, group dynamics should not be forgotten. I can understand why we were told to form groups and get a project going… this is typically what happens in the real world. You work with other developers, who have different working styles and personalities. We have had our ups and down’s, but I am glad to have started project as a 4-man team, and ended it as a 4-man team. There were some groups who split for various reasons.
One thing that was cool with working in a group was the fact our skills complemented each other. My web skills have gone from standard to trash now (I am working on it). When it came to building the website and making changes to the Web API, my “comrades” had that covered. When it came to the Android app, I had them covered. Some people preferred working during the day, others preferred night-time… I really don’t know where I sit… if my mood is good, and I have my coffee, I am pretty much set.
I had a lot of fun working on this project. I had my fears on building an Android app because of the issues I faced while I was trying to acquaint myself with the platform. Now that the 3rd year has happened, I am not so scared anymore. I know anything is possible if I refuse to give up, and scratch long and hard on the Internet. I can only hope on taking what I know now to the next level… get comfortable with Material Design, create mobile apps which scale nicely on phone and tablet (I have done a little Googling on this and it doesn’t seem like it will be rocket-science). Hopefully after I get my much-needed upgrade (a laptop that doesn’t choke on Android Studio), I will speed up development on the next app.
I had fun in 2016, project was lit. I am ready for 2017.