Prior to 2008, cell phones came pre-programmed, as manufacturers determined features, and customization was often limited to screensavers and ringtones. Then, in August of that year, Apple debuted the App Store, transforming cell phones from communication devices to mobile computers, altering the world as we knew it forever.
Apps not only assisted users in personalizing their mobile devices, but they also empowered a new generation of software developers who specialize in designing applications for these app stores.
Despite Apple being the industry pioneer, today, Google’s Android is the global leader in the mobile operating system market with a 72% share and over 2.87 million apps available for download on the Google Play Store.
In Africa, Android accounts for over 85% of the mobile OS market. This high concentration of Android users has created a significant demand for African Android developers equipped with the technical skills to build world-class solutions and the cultural competency to design them for African users.
Apps:Lab, the Kenyan software development company with a vision to become the leading solution provider in Africa, has a team of Android developers, led by Harun Wangereka, that are developing innovative mobile applications for Africa.
I spoke with Harun Wangereka, Senior Android Developer at Apps:Lab, about his role and experience as an Android Developer, in building a school management system for Uganda, one project among the many projects he’s done, and how he’s contributing to Africa’s tech ecosystem through community building and writing technical articles.
Meet Harun Wangereka
I’m Harun Wangereka, an Android developer based in Nairobi, Kenya. I got into development five years ago as a computer science student at Moi University.
While on campus, I enrolled in a training organized by the Science Students Association (SSA) to learn the basics of computer science and later I began specializing in Android development. Since 2016, I’ve been an Android developer at Apps:Lab, where I’ve worked alongside my amazing team to build over eight applications for our clients.
Marvin Collins Hosea, the CEO of Apps:Lab, and I went to the same university. He was two years ahead of me, and at that time, Apps:Lab was a group of tech enthusiasts who enjoyed teaching and sharing their knowledge with their up and coming classmates.
After a couple of years of training students, Apps:Lab officially incorporated and we've been running ever since. Our focus is building solutions for our clients which include web applications, mobile applications (Android), USSD applications, websites, or payment integrations.
Outside of my role at Apps:Lab, I’m involved in building communities and helping developers across Kenya and East Africa up-skill by sharing my experience and knowledge. I’m also a technical writer for raywenderlich.com where I write tutorials for Android and Kotlin for the Android Team.
Share a project you’ve worked on at Apps:Lab
Over the course of my four years at Apps:Lab, I’ve worked on a handful of apps. In 2018, a client from Uganda hired us to build a school management system for a segment of the Ugandan school system, which included 20+ private and public schools.
Our role was to digitize the school’s manual processes. The team included three back-end developers and me, the Android developer. It took us almost a year to complete, but it was really interesting because it involved solving a problem students face with a combination of hardware and software solutions.
How it worked was there was a dashboard where schools registered students and parents. Once registered, each student received an ID card that was NFC “Near Field Communication,” enabled. The ID Card gave students access to services like the school canteen, library, dispensary, and gate.
We also had an application for the parents to send pocket money to their student without calling the student or teacher. Using their NFC-enabled ID cards students would be able to buy items at the canteen.
What were some of the challenges you faced building the school management system?
The first challenge was learning Uganda’s education system. The material differences from the one in Kenya initially affected how we understood the structure of the application. Throughout the development process, we had to be conscious that we were not building from a Kenyan bias.
Also, in some areas of Uganda, the internet is not as accessible or integrated into the school system as it is in Kenya. This is not to badmouth the country, but because many schools didn’t have access to the internet, our client required us to make the application work offline, which was a challenging task for certain parts of the system.
For example, the canteen operation, in an ideal state, would rely heavily on the internet to sync data after transactions, so making it an offline web application was difficult. Though research, internal debate, and creativity, we were able to devise a structure to support the client’s offline goal.
Android gives offline storage, so we used that to store transaction data. How the canteen worked was the transactions were recorded in both the student and the canteen applications, instead of sending it to a centralized online database. Then the canteen owner would sync up once a day.
What is Apps: Lab process for translating business requirements into code?
The first thing we do is have a meeting with the client—all the developers on the project are usually present. Depending on the client’s technical knowledge, it can either be one introduction meeting or several. Those with a tech background usually come with the requirements, while with non-technical clients, we assist them in creating them.
For this project, we spent three full days gathering the requirements and creating the user stories. Once complete, we write a detailed software content document that guides us throughout the development process. Then our UI/UX person designs the application, and we confirm with the client that it’s what they would like, making tweaks where needed.
Before we begin development, the team sets the key milestones and a roadmap to help us and the client manage expectations. We update our clients every two weeks or once a week during the development process to inform them of the progress we’ve made.
After development is finished, we have internal testing where the whole team tests the application from end to end to make sure that everything is working and ensure we catch any errors before the client sees them. Lastly, we show it to the client, and once approved, we deploy.
What do you believe are the keys to building successful software solutions in Africa
Market Research
Market research is essential. Most developers try to copy-paste an existing solution that is working. Let’s say there is a product in Uganda, someone in Kenya might try to copy-paste it and bring it here, but oftentimes that does not work. You have to tailor your solutions to meet your specific market’s needs because each country/ market is different.
Perfection
You’ll find that developers and entrepreneurs will attempt to have the perfect product before they launch. Not realizing market needs are constantly changing and evolving and that the longer you take, the longer you delay the feedback loop. But if you deploy quickly, you get the feedback faster, making it easier to iterate.
Lastly, if you’ve stuck trying to evaluate how much time to spend before you launch, here’s the answer. When you have your minimum viable product (MVP) or the major features required for your application are done.
Logistics
Logistics is another part that can determine whether your product is successful. Many people overlook the impact of logistics on their business, only realizing it after they’ve launched.
Logistics in Africa is very expensive due to different government limitations and the many other moving parts. It becomes even more difficult if you don’t have enough capital and your competitors are well-capitalized.
What advice do you have for Junior Android Developers?
Read the documentation extensively:
When you start as a junior developer, if something doesn’t make sense, you’ll probably ignore it, and/or if you have a piece of code working somewhere else, you’ll copy and paste.
As you move to the senior level, you realize that you need to have a deep understanding of the concepts to tweak the code to your specific use case.
Let’s say you have to create a button. It’s possible to copy and paste the code from online or another project. But if you are required to customize it and don’t have the basic understanding of how the button works or how it was built, you’ll find it challenging.
Some developers struggle because they try to find an existing solution that meets their current use case to copy and paste the code, but you will never find one that is 100 percent what you need. That’s why it’s important to read the documentation extensively in order for you to apply any piece of code to your use case.
Be results-oriented:
What I’ve found to be effective is aiming for results. Over time, results are better than perfection because you’ll have more experience. You can work on one application for two years trying to make it perfect, but you’ll grow a lot more if you work on a couple of different applications in that same two year period.
Focus:
Some developers try to do everything, which is difficult to do because programming languages keep evolving, new features are added almost every day. What I like to tell people is to specialize in one particular stack. Get to know the ins and outs of that stack instead of being everywhere at the same time.
Small wins go a long way:
Most of the time we developers want to see significant progress early in our careers, which may not happen. So, be proud of the small wins. Allow them to serve as the fuel that keeps you motivated. Also, when you face problems programming, break them into the smallest unit possible and solve the small units one by one. Before you know it, you’ll have solved the big problem in a small way, and that’s a win!
Developing your creativity as a developer
Read:
I read a lot. I read people’s code, articles, and what other developers are saying online. Reading can broaden your horizons. Maybe you have one particular way of solving a problem, but if you see how Person X solves or approaches that same problem, you’ll become aware of other approaches.
Join a local community:
In Kenya, we call developers who don’t interact with other developers or join communities, bedroom devs. With time you find what you know is limited and biased. And it’s easy as a human being, I guess because of our psychology, to think you’re the best and that you know it all, and not receive feedback. But the more you interact with other developers, the more you gain knowledge to solve problems differently.
How are you involved in Kenya’s tech community?
As an Android specialist, I’m most active in Android254 and Kotlin Kenya.
In 2017, I became a member of Android254, a developer group that brings together android developers and enthusiasts to learn about Android technologies, best practices, and hear talks from industry experts.
It’s the only chapter in sub-Saharan Africa and has a community of around 3,900 members from across the continent. After a couple of years of being a member, I became a co-organizer last year. My responsibilities include helping run the meetups, finding speakers, and engaging our partners.
I’m also involved in Kotlin Kenya, a community centered around developers who use or are interested in learning the Kotlin programming language. Kotlin Kenya and Android254 also oversee the DroidCon KE conference, which I’m a co-organizer.
DroidCon KE is an Android focused conference for Android developers across Africa. It has been running since 2018, but unfortunately, this year, we didn’t have it because of COVID. The conference also has an app, and I helped develop it along with a couple of other devs.
Technical writing
My technical writing started when I launched my first application, AppKazi, a project management application. After the project, I wrote my first technical article, which detailed how to use the application.
A couple of months later, while working on my next project, I ran into this problem. I was attempting to get the app I was building to work in the background of an Android phone, specifically devices manufactured in China. I spent over two months trying to get a solution that worked 100 percent of the time, but I couldn’t.
After finding something that worked 90 percent of the time, I decided to document all the steps that I had taken to solve the problem and all that I learned in the form of an article, Android Background Services. When I published it on medium, the reception was positive, and I got a lot of encouragement from my peers, which motivated me to continue writing.
In Africa, you rarely find developers producing technical content in written form. I decided that it was a gap I wanted to fill. Now when I run into a problem that has not been written about yet, I write an article addressing it.
Earlier on in 2020, I joined raywenderlich.com as a writer on their Android team. raywenderlich.com is a community site focused on creating high-quality programming tutorials. This was a highlight for me because I was once a consumer of their content, and now I’m writing my own articles. I have published four articles: Database Views with Room For Android, Beyond the basics with Sealed Classes, Paging Library For Android with Kotlin: Creating Infinite Lists, and Deep Links in Android: Getting Started.
Technical writing is something I’m passionate about, and it’s helped me polish my writing skills and become a better developer.
Built In Africa? What does that mean to you?
The first thing that comes to mind is products built by Africans for Africans. In Africa, we have this problem that we are trying to solve, which is that we’re mostly consumers. And this goes beyond tech users and extends to the tech community, us, the builders of tech products.
As developers, we’re often using libraries that were created by other people. Although tech is global, it worries me because the more we consume, the more we’re not standing out as developers, and the less of a voice we have to represent Africa on the global stage.
The other problem with over-consuming products that are not built in Africa is that they often don’t incorporate how life works here. But once we have products that we build ourselves, we can customize the solutions.
Stay up to date with our newest posts and special happening here at Built In Africa. Your information is safe with us, we hate receiving pointless emails also. :)