That's all Folks!

What started out as a simple project to kill time in between lectures, turned into all embracing monster from the shallows of the Android underground, which consumed every bit of spare time, and could only be tamed by making sacrifices in the form of long nights and code driven weekends (yes, it was that dramatic ;)).

In any case, 2015 is over, we had a super amount of fun, and now want to take this post as a form of Good Bye to the Android Challenge. So, there it goes!

For starters in January we wanted to do something small. We didn’t feel the urge to revolutionize the world quite yet, but rather wanted to make sure we could actually deliver on our promise. So we started with the little well know game Memory (yes, the children’s game), and decided to make a multiplayer version where multiple phones / tablets could be connected to form one giant memory playing field.

Initial progress was quick. We split the app into three rough components (network communication, game logic and UI) and started dividing tasks. For combining multiple devices we wanted to try out Bluetooth P2P, but quickly discovered that the world of Android Bluetooth P2P really wasn’t as advanced as we had hoped, and definitely not as developer friendly. After about a week of digging through documentation and trying out different libraries, we dropped the idea of Bluetooth altogether and went with a regular client-server pattern over Wifi. Not as fancy, but simple and functional. Heads up: Google Play Games Services would have been a good candidate here retrospectively.

For the UI we spent some time on scrapping funny robot images from robothash.org, which generates peseudo-random robot images. The pseudo part is important. Turns out the robots are generated by simply combining various robot heads with torsos and different eyes. If you try playing a game with 5 screens full of them, boy does that game become hard!

Lesson learned: unless you are trying to come up with a new fancy network protocol or have very specific requirements, just pick a well known and established network library and stick with that. Your time is needed elsewhere.

Flippy Pairs got us pretty excited. It was our first app and looked half decent, so we spent a couple of extra days in February adding additional features to Flippy Pairs (bad idea …). At the same time February is also traditionally crammed with exams so we were slightly struggling to find yet another small app idea which we could make happen in just a couple of days. Eventually somebody suggested an advanced weather app which would show you the forecast along a particular route as you travel, which we thought sounded cool and so we went with that.

This gave us a chance to play around with the Google location services (which there are a lot of!), but also led to us maxing out our available Google quotas on a daily basis just by doing simple testing (we then learned the value of caching). We used the Google Places API for translating user input into actual addresses, the Google Maps Geocoding API for converting those addresses to GPS locations, and finally the Google Maps Directions API for getting routes between start and end locations. Based on this route we simply interpolated between the wayspoints and fetched the forecast from OpenWeatherMap. Retrospectively we didn’t nearly spend enough time on fine tuning the weather data (the free tier on OpenWeatherMap is very roughly grained when it comes to forecasts), but spent most of your energy on getting the locations part to work.

Lesson learned: four weeks per app sounds like a lot of time, but in reality it usually boils down to one or two at the maximum, since there is always other work to catch up on or cool features you can add to one of the previous apps.

Finally we had some time on our hands! University was over, no more exams and no excuses for not getting an early start with the app for March: a single player boxing game with sensor controlled punching. In fact, we were even lucky enough to have a new addition to the team: Julia! She had seen us hacking away out our little apps in the previous months and wanted to help, which was awesome :)

Box Club was the first (and only) really graphic “intense” game we made at FauDroids. Everything in the game is homegrown: the graphics, physics, sensor reading, AI. Other than logging, Box Club does not use a single external library!

Lesson learned: drawing nice graphics takes time, a looooot of time. Best to have somebody who is okay with only drawing and not coding for a while.

We are on a roll! Box Club looked awesome, we had grown from two to three people and now even managed to pick up Richard for anything server / Python related.

April: another month between semesters and without any exams. Great, so we decided to tackle the biggest downfall of blogging via Jekyll on GitHub: you need a computer to do that! Sure, nobody really wants to type a super long blog post without a proper keyboard anyways (confession: this post was not written using MrHyde), but we sometimes wanted to make quick changes on the go while still enjoying the luxury of getting a full preview of the updated blog, without (!) having to publish the changes first (another confession: this post was edited using MrHyde!).

MrHyde uses the pretty straight forward GitHub API for fetching and editing files in repositories on demand. In addition we also created a backend which would take an existing repository, plus a git diff and render those files using a Jekyll installation on the backend. The resulting HTML files are then hosted on the backend for a couple of minutes, which gives the app a chance to show a preview of your blog including the changes you just made.

Yeah, our first app which solved a very real problem. FauDroids is on fire!

Lesson learned: the more excited you get about an app, the more time you want to spend on it. Remember the four weeks problem?

Enough serious talk, back to games! Over barbeque we started to combine fun old arcade games to see if we could come up with something new, and eventually landed at Team Blocks: a multiplayer version of Tetris (yes, heard that before), where you don’t play against one another (uh, ok?), but have to work together in order to remove lines (yes, great!).

This time, having learnt from Flippy Pairs and the rather messy state of Bluetooth, we turned to the Google Games Services for managing communications. From past experience, getting started with Google APIs usually involves a fairly steep learning curve, especially since the APIs have changed over time, often times leading to contradicting documentation. Luckily integrating the Games Services “just worked”.

So, with network and game state out of the way, building the rest of the game really wasn’t that hard. Instead we managed to spend quite some time actually playing the game (it got addictive for a while. I hear a certain Simon and Philipp are still at the top of that highscore, cough Julia :D).

Lesson learned: there is hardly a more satisfying feeling than walking into a classroom, only to discover that all your peers are busy playing your latest game (oh, and Google Games Services really do rock).

Building apps makes students hungry. Hungry students have to go to the local cafeteria to eat. That cafeteria is biiiig and finding each other difficult. SigLocate to the rescue!

SigLocate is a small app for marking your location inside the cafeteria and sending a picture of that to other friends (via Whatsapp, Facebook, etc.). From a technology point of view this is probably the simplest app we built. But the simplicity is what makes it awesome ;)

Only mayor bump we experienced here was getting a somewhat accurate map of our cafeteria. We didn’t want to do all the measuring ourselves, the management wasn’t going to help us (and I quote: “it will be too difficult to administer this app”. Hm, what?), but the local public construction office was kind enough to give us copy of the original floor plan for the cafeteria. Pretty cool to see one of those, it even contained all the conveyor belt routes.

Not many people know this, but if you are a student at the FAU there is a 3 weeks summer course in the alps which you can attend at pretty much no cost. Not only do you get free food and lodging (do I need to say any more?), but you are thrown together with students from all disciplines and given the chance to build pretty much anything you want. In 2014 one those projects was about motivating people to do more sports, by letting them tackle various challenges in groups. One example would be to run a total distance of 1000 km in a group within a certain time period. While the app didn’t quite get finished in those three weeks (lots of students in one location also leads to lots of parties), the general idea still found resonance with us at FauDroids, and we decided to build a very rough prototype of this game for August. Proptype really is the keyword here because everybody was busy rapping up the university semester, so we really only managed a single player version of the game, which gave just a hint of what a future version might look like. At the moment the app supports tracking running exercises and lets you sum up your traveled kilometers to win a number of distance trophies.

Lesson learned: developing sports apps is actually pretty great. Not because the code you are writing is particularly different and more exciting than with any other app, but rather the way of testing is. When building a website, all you have to do is press F5. When building an exercise tracker to have to … well, do exercise to see the result. So to test KeepOn we got our bikes and spent an afternoon driving around the park in Erlangen, trying to collect just enough kilometers to crack the KeepOn challenges.

Maybe you have seen this video: Time Lapse Lotte. The video is 2 minutes and 45 seconds long and shows a girl (Lotte) growing from the age of 0 to 12. Her dad made this video by taking a small video of her every couple of days and later combining those to a time lapse video.

With BabyFace we wanted to create something similar, only instead of taking slightly shaky videos, we wanted still pictures with a face detection software working in the background, to steady the position of the face. We weren’t so much afraid of handling the regular photo capture part, although implementing custom image capturing turned out to be pretty painful in Android, but were more focusing on the image detection part. In our initial approach we saved the photos in a Google Drive folder of the user and had a separate server which would download this folder and take care of creating the video. This approach had the advantages that we could

take advantage of the awesome OpenCV framework for detecting faces and manipluating the photos in pretty much any way we wanted.

On the downside we had a server which needed to be maintained, paid for and integrated with the Android app in a reliable manner.

No sooner than when we were finished with a early prototype and were gaining confidence that, while not super pretty, we could get this client-server setup working, Google added face detection to the Google Play Services. Ok, so we just put a lot of energy input into building our (very beautiful!) server, but doing all that on the client was just too good to be true. So we threw our backend over board and integrated the “native” face detection Sigh.

Lesson learned: if you are building one app every month, think really carefully about whether or not you need a server. Sure, todays frameworks are powerful enough that you can hack something together in a couple of hours, but the real price comes when having to maintain that setup over a long period of time.

September is Oktoberfest time! If you have read the last part about BabyFace you might have guessed that we spent more than 4 weeks on that. So with that in mind we needed something simpler for September. Luckily a friend suggested that we take SigLocate and make it work for the Oktoberfest, and not just the Oktoberfest area in general, but also with maps from inside the tents. The code was already in place so we only needed to get our hands on some maps. Some tent providers have those online, but most did not. We tried calling but nobody seemed to be particularly thrilled about sending us any materials. In the end we tried to piece together maps from the inside, by watching videos on YouTube, and browsing through tons of party pictures. Not the most effective way to do things, but after some time we got a pretty good idea of how the tents were laid out. In any case we managed to finish the app just in time for the “Anstich” (opening) of the Oktoberfest, and even got an interview at kultradio.fm (thanks so much at Katharina!).

Lesson learned: reaching the audience of an event like the Oktoberfest is not easy at all. Another app for an event of this kind would have to have better distribution channels, an official partnership with organizers for example. The customer acquisition cost were way higher than we thought. We tried Instagram, Twitter, Facebook and various blogs and online magazines, we even were on radio - but did not get real traction. At the same time everybody who saw and/or used the app was thrilled about it. The problem: the target audience is very heterogeneous and usually visits the Oktoberfest only once. So if you can’t get your app showcased through big/official channels or maybe directly on site, you will have a hard time.

We believe advent calendars a great, and that everybody should have (at least) one! In case you are not familiar with the tradition (seems to be a German thing?): an advent calendar is usually a box with 24 doors (one for each day in December until Christmas Eve) filled with chocolates or some other sweet goodies.

MyAdvent lets you create advent calendars online by uploading images, text and audio. Those calendars can then be shared via URL with family and friends. You can see an example calendar here.

It was by far the biggest and most complex app we have built at FauDroids, largely because it is so much more than just an app, but rather a web client, and android app plus a backend for managing all those calendars. Besides being the biggest app from a technology point of view, it also received quite a bit of media attention, ranging from an interview with the ERLANGER Nachrichten to numerous blog posts and a nice Facebook fan community. In the end over 500 calendars were created, and those are just the ones with 20 or more pictures. All in all it there were more than 3000 calendars.

Lesson learned: if you are building an app with a time critical component (like advent calendars where the second door really should open on the second of December), make sure you have somebody on call for technical support. In MyAdvent the logic for deciding which door can be opened was the following (Javascript):

leti='1';// idx of door, starting at 0letd=i+1;// day in Decemberif(today>=d)openDoor();elsedoNotOpenDoor();

Remember the days back at the schoolyard when the first snowflakes began to fall from the sky? Still remembering the urge you felt letting one of these tiny crystals melt on your tongue? This is what Bored Rudolph brings to apps having boring loading screens!

Bored Rudolf is a small library for Android developers who wish to replace their standard pull-to-refresh layout with something a little more suited for the Christmas season: a quick game about catching snowflakes!

Lesson learned: initially we had bombs dropping from the sky, and only later changed that to snowflakes. So I guess the lesson here is think about the kids?

Do you like the party game Werewolf? Great, we do to! So for our final act in 2015 we sat down one last time and create a little app for helping you getting started with playing Werewolf, in case nobody remembered to bring cards. The app does not try to be any more than that, no fancy director which guides you through the game and no strict rules about how to play Werewolf. Instead it gives you the standard Werewolf cards and helps the game manager by distributing those cards among the players.

Lesson learned: December is a tough month. You have already created 11 apps, are probably in the middle of the pre-Christmas stress of having to finish work projects and getting all presents ready, such that there is little to no time to think about that final app. So, unless you find that magic bag of free time, pick something small and get it done before Christmas (yes, not the greatest advice, I know, but figuring it out is half of the fun :)).

Summary

These apps wouldn’t exist today, if it hadn’t been for a team of students which spent their spare time hacking away at Android. To finish of this post, here are some final thoughts from each of the FauDroids heros:

Android actually wasn’t my first experience with mobile systems (although the other experience was just cracking a game for my once beloved Blackberry). But somehow this experience got me interested in stuff like that.
I got in touch with Philipp and Julia while programming our world famous Fliegeviecher Simulator (the result of a university course), and one day had chat with Philipp about the lacking motivation to keep personal projects going.

So me being interested in learning a bit about Android programming, which I had absolutely no clue about at the very time, and Philipp being the awesome guy he is, got this whole thing started.
After we tackled the first hurdles and actually got started I soon realized how much fun this whole thing was. Spending hours in front of computers may sound boring as hell, but believe it or not, we always had a good laugh. It got even better when our team began to grow (which caused other people to leave the room as soon as we entered it :D), and I still remember the excitement about our first pull request. Thanks for all the fun and good times, FauDroids!

I met Philipp at the notorious Ferienakademie of our university (where also the inspiration for Keep Going emanated from). When the next semester break came I had some spare time and Philipp suggested me to join the FauDroids. At that time I had no idea how an Android App is developed but I thought: Why not, sounds like fun! Consequently I was not a big help at the beginning, struggling with the easiest commands (but hey, something is better than nothing). As time passed by I learned quite a lot: not only programming, but also the whole production cycle of software (from brainstorming sessions about the next month’s project to design sessions (all the cute robots and reindeers have to come from somewhere and you cannot imagine how many different shades of green there are and how hard it is to decide for one…)). And finally when the app was released I always felt really proud about what we have accomplished in one month! The feeling got even better when the first comments and requests from people who were actually using our apps reached us. Unfortunately I could not take part in the last three months of the challenge because of going to Boston as a visiting student. But it was an amazing time and I’m deeply grateful for this experience! So last but not least, thanks to my crazy FauDroid guys and all the people supporting us and our ideas!

I joined the team when they started developing MrHyde. It was a huge project and I really liked developing server infrastructure in python, so I decided to board the crew of FauDroids. It was awesome. It was nice to work in a team of talented and kind people, it was interesting to figure out how much work one could put into an app in a single month. The most awesome part was the moment when you released the app that you put so much work into for the last month. Especially Mr. Hyde took a lot of effort on my side and when all the cogs finally decided to work together, I was a very happy man. I want to thank both the FauDroids team and everybody who supported us or uses our apps from the bottom of my heart!

I joined FauDroids quite late towards the end of August. Overall it was a great experience to work with really passionate, nice and talented developers. I especially enjoyed the part of creating the idea of a product from scratch with the team and carefully evaluating the different features and their implementation order. I also learned a lot by experimenting with different marketing channels, seeing what works and what does not as well as finding out why to make it better next time. Finally, it was a pleasure to see our “big hit” MyAdvent have more than 500 created calendars and over 700 people opening their virtual doors every day.

The first few Android apps I touched, aside from the obligatory “HelloWorld”-primers, were actually malware samples, which I reverse-engineered in the context of some activity at our IT-Security chair. Consequently, as a member of FauDroids, I forward-engineered apps for the first time :)
Although I joined pretty late (MyAdvent was almost done), I have learned a lot in regard to the whole cycle of developing ideas over implementing them up to actually releasing stuff. Especially the last part, having “customer” contact, was a new and really satisfying experience. In that sense, thank you, if you have contributed to this experience.
Another aspect of joining late was that my mates were much more experienced than I was in regard to Android app development. This in combination with their helpful nature enabled me to pick up things fast and actually contribute to our projects, which I really enjoyed. Amigos, thank you very much, it was a great time!

Most of my previous “developer career” has been about doing one thing and making sure it’s “perfect” before going public. Well, turns out that even after a couple of years doing that not much has actually gone public. For me FauDroids was an attempt to break free of this “it’s not ready” mentality and enter a more goal oriented one. Doing a one app a month challenge has definitely helped, and I am super grateful for all that we have accomplished. Thanks to everybody at FauDroids for taking on this challenge with me and thanks to all the numerous supporters that have donated their time to give feedback and try out all the crazy stuff we built. Thank you.