This semester I took an Android development course. I’ve struggled with Android programming in the past, mainly due to my Web background. Most web apps have a different architecture and different API style, and I always found Android development quite difficult to wrap my head around due to its embedded nature and lifecycle methods.
Doing the course gave me a deeper understanding of how to bring together an application with all the fragments, activities, services, and interface components. I eventually came out the other end with a fairly polished Android application that I’m quite proud of.
I’ll go through a few things that I had troubles with throughout the semester, in this article.
Android Studio’s default templates around Activities and Fragments tend to assume a lot about the setup of your application, so I had some initial issues involving Android v4 Support fragments that aren’t compatible with the custom Material Datepicker library I use. After doing some research, I found out that with an Activity that extends the AppCompatActivity, you can use the SupportFragmentManager and the FragmentManager interchangeably, depending on the version of the Fragment you want to push into it.
Due to this initial confusion, I feel it’d be better if Fragments were covered within the scope of the course, as I am unsure whether I’m causing potential memory leaks in the application by merely doing TransactionManager replacements rather than manually calling detach and destroy lifecycle methods.
Android Permissions Models
The Google Maps API documentation skips over the actual requesting of permissions for location data, which blocked my progress until I could piece together the various pieces. I feel this could be more fully covered throughout the course perhaps.
Overlap of advanced system design concepts
I was surprised to find that significant concepts and design patterns I learned from working on web-based systems overlapped with those power developers use in their Android applications. For example, view binding libraries such as Butterknife and dependency injection, found in Dagger as well as most enterprise applications.
The EventBus pub/sub concept suggested by Ryan Heise, whilst not needed for a low-complexity application such as QuestionTime for Android, is something I have worked with before.
Similarly, the annotation-based conventions found in the DBFlow data binding ORM are similar to the lightweight ORMs (Dapper, MongoDB C# driver) I’ve used in C#.
This overlap made it easy to implement shortcuts that I’ve used in the past, and highlighted key areas which could be improved by my existing knowledge of design patterns.
Weird Async Computing Model
I used a bunch of different libraries within my application, and I’d like to highlight some here.
- Material Date Picker - because the inbuilt DatePicker is not fully featured enough
- Android LINQ - I still need to learn more about this library but I really like the idea of using LINQ statements to manipulate collections in Java
- DBFlow - really simple POJO annotations and a declarative type-safe database query interface, as well as Observables and inbuilt RecyclerView-compatible lists made it a joy to talk to the onboard SQLite database (which is significantly more complex to setup, oddly enough)
For next time
- EventBus for a pluggable event stream; the guy marking my work suggested I make use of it for inter-fragment communication, rather than the Android Studio suggested method of an onFragmentChange listener interface
I hope to get this on the Play Store by the end of the year. In the meantime, here’s some screenshots of it: