We use cookies on our websites. Information about cookies and how you can object to the use of cookies at any time or end their use can be found in our privacy policy.

Developer's Diary Part 2: App Conception in Detail

Developer's Diary Part 2: App Conception in Detail

How is an app “developed”? What kind of considerations must be made regarding its design? What does programming entail? Is the development of an app primarily spent behind a computer, typing code all day long? In our developer diary, we’d like to give you a glimpse at the day-to-day life of an Android app developer. Rudiger Merz offers part one in a three part series about his work developing the e-mail app “Compail.”

By Rudiger Merz

When designing an app, there are lots of considerations to take into mind. How much time do I have? On which version of Android do I want my app to work? Is this a business or hobby project? How can I convince my wife that it's a good idea for me to stay glued to my screen every night? Unfortunately, I'm a programmer and curiosity often gets the best of me – it's not until after I've invested a good three weeks or more in a new project do I even try to resolve these questions.

"Fragments" and "Activities"

When working on Compail, however, one important question had to be settled at the very beginning: namely, would I like Compail to work on both phones and tablets? If so, I would have to enable Google's "fragments." Fragments are modular "activities" which, among other things, allow for a user interface to be more dynamic, and to take advantage of a larger tablet screen. It generally corresponds to my philosophy to keep my development under Google's guidelines. I think it's ugly when apps work with different controls and structures. How would a normal user cope if everything looks different, foreign? Naturally, I wanted to use fragments. 

Google recommends that you use "fragments" on newer versions of Android. At the time I was coding, "Gingerbread" (API 10) was still the dominant OS, followed by Ice Cream Sandwich (API 15) at a distant second. To offer maximum compatibility, my app would have to work with API 10 – 16. But the devil is in the details. API 10 does nto support "fragments." Although Google offers a work-around, it still runs differently than on native "fragments." Accordingly, I would have to respond differently depending on the various operating system versions. All this is solvable, but it's more work, especially since the different versions of Android will respond differently to the software. More on that later. 


There are essentially two established protocols for accessing e-mail. However, neither POP3 nor IMAP are appropriate for a mobile e-mail interface. POP3 can only hard sync , while IMAP is more suitable for connections that are durable and reliably available. A mobile phone requires fundamentally different systems. It must keep the server up to sync as often as possible, be quickly alerted to new incoming e-mail, while keeping the data volume as low as possible. It must also keep functioning without draining the battery.

Fie Unterschiede zwischen IMAP und POP3 / (c) signinx

Honestly, I imagined this project being easier when I first started.

Since POP3 is not supported by so many vendors, I ended up choosing to use the IMAP protocol. Anyone who has ever employed this protocol knows that the process of implementing it could fill a book. And there are many differences between IMAP providers. But of course I have no particular desire to develop an IMAP client "from scratch" and luckily there is help out there. The JavaMail API was created to make it possible to construct platform and protocol-independent e-mail solutions. Too bad that it's still in its experimental phase and I had to completely re-write a good third of the app all by myself. 

Problems, Both Big and Small

But back to the development considerations. E-mails can be read without needing power, and data must of course be stored in a local database on the Android device. But there are problems. For example, a message is transmitted to the smartphone and added to the database. At a later date, I go to check my inbox, and I read the message, or even begin a response, without any internet connection. Of course, my server no longer reflects what the app reads. Accordingly, the app must remember all offline actions and update the server when you're back online.

One can easily imagine the strange situations which arise there isn't a stable network connection – IMAP simply isn't designed ti account for this and other similar scenarios.

I wish I would have considered all of these possible problems in advance. But to be honest: a complex project like Compail is not entirely plan-able. One thing I knew from the outset, though, is that I wanted my app to be ad-free. That wish never changed.

In a way, I'm glad no one told me how hard it would be to create a new e-mail interface for Android. Nobody told me it would be impossible, so I went ahead and created it. 

In the third part of the series, Styx will explain how he designed the interface for his app. Missed the first part? Click here for Part 1: Every App Starts with an Idea.

Recommended articles


Write new comment:
All changes will be saved. No drafts are saved when editing
Write new comment:
All changes will be saved. No drafts are saved when editing
Write new comment:
All changes will be saved. No drafts are saved when editing