This past weekend was the Indianapolis AT&T IoT Civic Hackathon – 24 hours of building, making, and playing with IoT hardware and software. The theme of the event was for projects to be related to the economy of Indiana – specifically in the areas of manufacturing, agriculture, and logistics/transportation.
I was invited to join an existing team by a friend from college. They had a group of four hardware guys already, and needed someone who knew software to build the app portion. We held one group meeting before the event to come up with ideas. We generated a lot of good ones, but most of what we came up with would have been far too much work to complete for a 24-hour hackathon.
It didn’t matter how neat our ideas were – if we couldn’t execute on them in 24 hours, then the project would be doomed before it started. At the end of the meeting, we had developed one single (but fuzzy) idea that we thought we could execute in a day. One of the team members had some old lockers in his office – and our group’s idea was to make an app to control access to them. For an interesting hardware angle, we thought we could integrate Bluetooth Low Energy (BLE) in some way. And given the three broad hackathon categories, we thought we could probably make it fit in one of them. All we had was a vague idea – but it was good enough to get started.
How can you build anything useful in 24 hours?
Now at the hackathon itself, the first thing we realized when we started working together was that we had a lot of ideas about what we wanted to build – too many ideas in fact. If we tried to build all of them into the final product we would never get done in 24 hours. We had some great ideas about authorization and access, Alexa integration, social features… and on and on – but we knew that even if we could build them in a day (which we couldn’t), then we would still have to fit all of that into a three minute presentation.
To be successful, we had to focus our efforts on two things. Particularly, we focused on what we could possibly
- build (in the next 24 hours)
- present (in the three minutes we would have onstage to make our impact on the judges)
With too much to do and not enough time, we got started. Not by building, hacking, creating…but the opposite: cutting features.
Working backwards, we started with the presentation – what could we present in our three minutes onstage? With the focus on what would matter for the final presentation, we decided on the core functionality of our app that we would demonstrate:
- Use a mobile app to unlock a box
- “Check Out” a piece of equipment
- Return that equipment to a different box
We also decided to focus the app on one vertical in the theme of the event: manufacturing. We chose this specifically because of the amount of tools and equipment that could need to be secured in the manufacturing vertical.
With those constraints, we felt that we had a plan for what we needed to build in the next 24 hours – so we got to work.
Know Your Strengths, Then Focus
I was the only “software person” on our team, as the other members were the hardware experts. So when I started designing the React Native app, I knew I had to keep it simple. My design process started like this:
I decided to use the React Navigation library, since I had used that before, and skip the fancy animation I had planned. I skipped logging in (since that’s not interesting in a three minute demo), and made the text large and readable. The whole app was designed and built with the presentation in mind. I knew that if the presentation was rushed, or the audience couldn’t read the app – it didn’t matter how cool it looked up close to me!
Leverage React Native
During the hackathon, I had to make a conscious decision to not waste time fighting the technology to get every last visual detail to be perfect, but instead to leverage the strength of React Native to get a functional UI in the minimum time. When you have 24 hours, it’s not important if you get the app to look exactly how you want it to look – what’s important is that you get it to look good enough…and then move on. You can always go back later to fix design flaws if it’s absolutely necessary.
When designing a native app, it’s easy to get caught up in tiny design decisions that take a long time to work through. To make a native app quickly, you have to learn how to let go of those battles, and do whatever is easiest. I used Tab Navigators and Stack Navigators – because that’s what’s easy to use for me. I had grand designs for a unique card list interface – but that would have fought against React Navigation’s natural navigation flow, so I dropped that too. In the end – it was more important that it worked.
When it came to integrating with the BLE beacon, I wanted to keep that as simple as possible too. I found an existing library (react-native-beacons-manager), and as soon as I got the phone to read RSSI from our beacon with it – I moved on to the next feature. Choosing a library for a hackathon is different than picking one for a real product. I didn’t care about future support or how robust the library was – all I optimized for was getting it to work as fast as possible. It’s not often that I get to develop that way; I’m usually worried about features, support, and community – so it was fun just to see how fast I could get something working with the tools I had.
A hackathon isn’t just about building something cool in 24 hours. I met interesting people, learned new things, and had a lot of fun creating something new. Plus now I can say that it’s possible to build a complete React Native app in 24 hours!
If you’re interested to read what kind of code is possible in 24 hours, we’ve open-sourced everything! Check here for the source of the React Native app. Here’s the video of our presentation:
Besides our own, I was impressed by how much was accomplished by all the teams collectively over the course of this short event. In the end, 25 other teams presented a bunch of great projects as well.
Thanks AT&T, thanks Launch Fishers, and thanks team!
Like this post?
Subscribe to get our latest content by email.