My First Published App (part 1)

Intro

Hello Everyone,
I just finished publishing my first app into Google Play. I decided to write this to commemorate the experience and to give a few tips on building and publishing.

This post should not be followed to the 't'. I am only recently certified as an Android App Developer and there are many ways to build your own professional apps. This post is intended for those who want to go through the building and publication process, and feel they want to know others experience to help them get past the nervousness throughout publishing.

About

OWL Flash Cards Level 1 en-cn. Code Repo, App

Created using Android Studio version 3.3.
Requires a minimum SDK level of 19.
Compiled for SDK level 28.

Additional Dependencies: Firebase, Support, Arch.Persistence.Room, Arch.Lifecycle, and Expresso for testing.

Starting a New Project

Creating the Idea/concept.

Well first I am terrible at speaking Chinese, but I married a girl from China. So after being married for a while I attempted to learn Chinese and I basically hated the way most programs taught you. I wanted a quick way to learn a word or two when I had free time, and the best way to do this seemed to be flashcards.

For creating your own app idea the best method is usually just, what do you want and then expanding it outwards to help other people too. This can make it helpful for similar minded people to be easily attracted to your app idea.

Creating a look for the Idea.

Many people have heard of flashcards and probably used them, but how do you design an app to appear like them?

First off you can try reading designers tips and tricks for making beautiful card animations, but that will usually lead to a road block if you do it too early on. The best method I have found is to start smaller:

1. Create a single app page and design its layout.
   • this can be done by drawing on paper or using an editor.
   • start by placing required items first "title bars, nav bars, etc...
   • don't pick colors too early, styling the background and elements may be fun but doing it too early leads to messy code and lots of cleaning later.
   • Fill in the rest but don't forget to leave spaces for your own logos and titles.
   • Lorem ipsum is a great way to put filler text, until you've organized your layout more. *remember to draw buttons for apps with more then 1 screen, or look into other options like the navigation drawer.
2. Reference other apps, does the page you created look like a home page, a menu, the main content, etc...
   • If not a normally used design, think of ways you can either improve your own design by referencing others or go try and explain how to use your design to a friend. If you can't explain it in person there is almost now way users will understand it by only seeing it.
   • You don't need to look exactly alike other apps, but people tend to do sloppy designs unless designing is their profession. So use other apps as reference when possible.
   • Doing all this helps build validation that you are creating a professional app.
3. Create a story board for apps with more then 1 page.
   • This way all your designs and pages are in a line so when you jump to functionality you remember who connects to who.

I personally redrew designs and storyboards for about a week straight until I discovered that for now I just needed the most simple of layouts.

Android Studio first time build

So Android studio gives you a few basic templates, now if you don't need any extra templates you can use the empty activity layout. But remember to not just jump to this as a default, look at what you did when designing your app, did you push all your buttons for changing screens to a nav drawer, well if so android has a layout already for you.

• Remember to look at what's available, so you don't have to recreate the wheel later.

Building the app layout

Finally we can start coding. This app's prep work took me quite a bit of time, but it was super worth it to be able to start coding and see the layouts I made popup on a phone screen.

Now for the home screen and menu screen, it was quite simple at first. I needed only a LinearLayout to hold my views which consisted of Textviews, ImageViews, and Buttons, But that was a wrong assumption on my part.

Linear layouts are great but they are only one direction, so if you want two items in a row you have to add in another layout group. If you add in a second Linear layout to hold the two items you also need to worry about layout weights. Layout weights are great because they can help organize your content for multiple screen dimensions but can cause performance issues when nested inside of each other. This is caused by the computer having to call onmeasure and ondraw multiple times in order to correctly process the dimensions of each item, which slows down all other resources, usually annoying the user greatly.

So what did I do then to maintain flexibility for different screen dimensions?
For the Title Screen I used a constraint layout as the parent and placed a scrollview inside. The scrollview wrapped around my linear layout allowing my app to go past the boundaries of the phone... and yes I know this is wrong for a title screen, because if parts of your title, or following content goes off bounds, what user will think, 'oh i can just scroll to it, its ok'. None that's who. But when I was testing on multiple device screen I allowed this early mistake, so that I didn't have to build a horizontal orientation at the moment.

I did later go and build horizontal layouts for my pages, but at first I focused on functionality, and that's ok. If you do decide to focus this way, make sure you implement a //TODO reminder so that you don't forget about something later.

Fragment layout building

Fragment layouts are included into a pre-existing layout, so remember your view hierarchy and avoid nested weights, forgetting the parent already had weights, can cause serious performance issues.

My app currently uses 2 fragments, one for the settings preference fragment and one for the flashcards themselves. Building the layout was semi straightforward, except that it took me a while to figure out, how to make the card flip over and show the translated side. But more on that in Part 2.