Blog post for my internship
-
My boss kept nagging me to make a short blog post about my internship project, so I did. Some of you might know that I’m having trouble getting feedback on my work, so I put in some comments about that in this post.
Android application development
I’ve been working on the Projectcampus Android application since September, and I must say I’ve learned a lot about Android and personally think the application is coming along nicely.
It all started as a very simple list of hardcoded data, but gradually grew to make use of various Android components such as a Content Provider, Authenticator, Sync Adapter and even custom views. Besides these components I’ve learned about using various mainstream libraries such as Retrofit, OkHttp, Glide, Butterknife, Eventbus, Crashlytics and the Android Support Library.
Retrofit powers the REST communication with the Projectcampus backend in combination with EventBus. EventBus is exactly what it sounds like, an event bus. This makes it possible to launch a REST request from anywhere in the application and also to allow any part of the application to receive any REST response. EventBus is also used for other inner-application communication.
Glide is an image loading and caching library used for the various images used throughout the application. All of the networking is backed by OkHttp.
Butterknife is a view “injection” library for Android and is used to reduce the amount of boilerplate code. Crashlytics is used to report crashes and errors.
The Android Support Library is used for a couple of things like Material support for API levels below 21, Toolbar and new Swipe Refresh Layout.
In the current structure, all REST request events are handled by a Retrofit client. This client posts all the results to the event bus. A database service listens to all the response events and writes these to the database through a content provider. Any fragment or activity subscribed to the affected URI’s will be automatically updated through the magic of cursor loaders.
I’ve also made sure to improve performance where I can. Making use of the View holder pattern, reducing layout XML complexity and depth and reducing overdraw are a few examples I can currently think of. I’m sure there are parts in my code that can be refactored to be more performant, but that’s hard to determine when you’re the only person looking at the code.
The application is also configurable at build time using gradle. There are several properties that can be set to configure the application, most important being the URLs and client ID for the API. There are also properties to disable certain features of the application.
All in all I’m fairly happy with the current state of the application. However, I also feel like it could be a lot better and further along if I had occasional feedback. A very large portion of my time has been spend redoing something I did the previous week. On the other hand, I’m also kind of proud of myself that I’ve managed to put together the application in its current state all by myself.
