The Story behind the DevConf 2018 App.
Imagine being tasked to develop a mobile app for one of the most important events in the software development community. An event that will host local and international guest speakers giving them a platform to share their knowledge and explore the latest industry trends. This event attracts developers from all over South Africa, provides a great learning and networking opportunity for everyone in attendance
Code Name: Snowball
The task was to develop a mobile app for DevConf 2018. The development team was made up of 2017 DVT Graduates and junior developers, and all we had to begin development was the event website and the prototypes designed by the mentors. The Event organisers were not aware of the existence of the project, and within the organisation, no-one knew what project snowball was except people involved in the project. We needed to develop a mobile app for both iOS and Android platforms. On the Android platform, the twist was to use Kotlin and Android Architecture components. We had three months before the event, and we needed to have a production ready app to present to the organisers.
The Process
Every decision was taken with careful consideration. For the back-end, we used Google’s Firebase real-time database. With that came the painful task of copying data from the DevConf website then adding it to Firebase manually. While designing the back-end we had to make sure that it was suitable for both iOS and Android.
We knew we were developing the app that was going to be used by developers, so attention to detail was vital. We had to make sure that the user experience is right, the data is correct, and that the app is not saturated with unnecessary information.
Architecture and Best Practices
Clean code, design patterns and selection of the appropriate architecture made a huge difference in the success of this project. From the initial stages when we had to decide which architecture to follow to understanding exactly when to use fragment over activities.
Applying architectural design patterns reduced bugs, made our code more testable, simple to read, isolated complex code and maximised our development time. This proved to be beneficial when we needed to change to Firebase Real-time database from Firestore. All we had to change was our repository and module on dagger 2, but everything else remained the same.
Firebase Firestore
@Inject
override fun getListOfSpeakersFromFirebase(callback: SpeakerRepository.RepositoryCallback) {
val db = FirebaseFirestore.getInstance().collection("speakers")
db.get().addOnCompleteListener { querySnapshot: Task<QuerySnapshot> ->
if (querySnapshot.isSuccessful) {
val speakerList = querySnapshot.result.mapTo(arrayListOf()) { it.toObject(SpeakerModel::class.java) }
callback.onSuccess(speakerList)
} else {
val getException = querySnapshot.exception
callback.onError(getException)
}
}
}Firebase Real-time database
@Inject
override fun getListOfSpeakersFromFirebase(callback: SpeakerRepository.RepositoryCallback) {
val db = firebaseRef.child("speakers")
db.addValueEventListener(object : ValueEventListener {
override fun onCancelled(error: DatabaseError?) {
callback.onError(error?.toException())
}
override fun onDataChange(querySnapshot: DataSnapshot?) {
querySnapshot?.exists()?.let {
val speakers = arrayListOf<SpeakerModel>()
querySnapshot.children.mapNotNullTo(speakers) { it.getValue(SpeakerModel::class.java) }
callback.onSuccess(speakers)
return
}
Log.d("SpeakerRepo", "Nothing in speakers")
}
})
}One of the most important requirements was to make the code dynamic and white labelled. Adhering to this paid off when the DevConf organisers requested changes days before the event. We only updated our back-end, and the codebase remained the same. White labelling ensures that the same codebase can be adapted for future and different events. Even the smallest details were considered like time zones, paddings, colours, font and text size. Tools such as build servers and project repositories are necessary for the project, for example, build servers assisted us with achieving continuous integration and served as a safety net when pushing code.
Open Source Contribution
Before we began developing the DevConf app, we researched how existing event apps approached their solution. The following open-source apps contributed: Riga DevDays, Squanchy and Chicago Roboto.
Open Source Libraries and Apps that contributed to project snowball
The use of open source libraries made a massive contribution to the success of this project. It simplified code, minimised development and made our code more testable. These libraries include Glide, dagger 2 and Kingfisher. As good practice it was befitting for us to pay homage to the developers on our open source page. The developer of the Sqaunchy was impressed with our app and gave a positive review.
Mentorship and Peer-Reviews
This project was a team effort and included mentors Rebecca Franks, Paul Cloete, Chris Dawson and Peter John Welcome. They assisted with reviewing our code and offering direction when we encountered some difficulties. Peer reviews played a pivotal role in ensuring that as developers we understood each other’s code and logic behind a particular feature. These were necessary because during our daily stand-ups we were all on the same page due to such practices. Gitflow was a branching model that we used to take up features, and after the reviewer and peers are happy with your code, then it can be merged.
DevConf 2018: Johannesburg
Using Google Analytics for Firebase we monitored the traffic, the number of users active at a particular point in time, which feature was being accessed and more. From the morning of the event, DevConf users were using our app to navigate to the venue and planning which talks they wanted to attend. It was incredible to see that people from different parts of the world were downloading and using it.
By using analytics, we were able to see which part of the app had the most activity and number of hits at a particular point in time.
However, the highlight of my day was when I was walking behind a group of delegates that were going through the event pamphlet. Someone walked passed them and suggested that they use the app.
Milestones
- Developing a stable app in Kotlin and using Android Architecture Components.
- The positive feedback received from users.
- The contribution our app made to such an important event in our software development community.
In conclusion, it was a great experience to be part of the Snowball Project Team. I have learnt many things such as the benefits of clean code, architectural design patterns, writing tests, Agile, teamwork and mentorship. All these things played a crucial role in ensuring the project was a success.
Get in Touch
