Apps Need Room To Breathe!

Share if the site was helpful

Apps Need Room To Breathe!

Android is a complex operating system.  There’s a lot more variable when developer for Android.  Things are unpredictable when it comes to knowing what phone your user will be on.  There’s literally no limit to how many different kinds of phones could be running Android on a given day.  If you don’t know what you’re doing this can be dangerous for your layouts.

How so?  Doesn’t everything work the same from phone to phone?  Well, no actually.  Things function very similarly, but different phones have different characteristics that can drastically change a user’s experience.  Take screen size for example.  You could design an app and have one user download it on a phone with a 4’’ screen and another on a 6’’ screen.  This may not sound like a huge difference (2 inches is rarely a big decider life), but when it comes to a screen size that’s literally 50% more screen space on one device than another!

How things can go very, very wrong:

If you don’t take different screen sizes into account, then users will most likely miss out on important info. When you’re first learning about how to develop Android apps you’ll most likely use LinearLayout a lot to organize your apps.  This layout takes one view (text, image, button, etc.) and then lines up the next one in a list side by side.  Or you can change it to go vertically.  Either way the end result is a neat row/column of views.  Here’s an image to help you visualize:

But what happens if when your developing you only test the layout on your phone (let’s assume its huge).  Things may look great to you, but when you publish the app and someone with a smaller phone uses it this is what they might see:

How we can prep for things to go very, very wrong:

Trust me as I made this mistake on the first app I ever published: It’s not a fun mistake to make.  Your app is a work of art.  It’s something that you created from nothing and want to show off to your friends, family, and the world.  So when you have someone download it and instantly their greeted with a funky looking layout…well it’s not the best feeling.  Luckily, we can learn from our mistakes and prep for them in the future!

There are situations where you want to use LinearLayout and there are situations where its best to avoid it.  Sometimes you may want to keep the row/column but add scrolling capability to it instead.  Android developers have experienced all these scenarios, and that’s why there’s more options than just LinearLayout.

Layouts like ConstraintLayout and RelativeLayout allow you to position views in relation to one another as well as to their parent.  So you could position pictures on your screen to “attach” to the right or left side, and make your layout look a lot more professional.  That’s of course just the tip of the iceberg though.  There are different screen densities to account for when choosing what images to use.  And you can also have portions of your screen appear/disappear by using fragments. Don’t worry we’ll have posts on both of these topics coming up soon!

If you’re interested in learning more about styling your apps for different screen sizes and how to make your layouts ready for professional use, checkout Phonlab’s Android App Developer course!

 

Google Pay: Caring Is Sharing

Share if the site was helpful

Google Pay: Sharing Is Caring

Earlier this year Android Pay and Google Wallet combined forces to create Google Pay, a one-step payment process for Android users.  The app has featured online payments with certain websites/apps by initially linking a credit card and then checking out in the future with one click. More technologically impressive it uses NFC (Near Field Communication) to allow users to hold up their phone at a cash register and buy things in person too.

Google Pay seeks to make users lives easier by removing the hassle of reaching into you wallet/entering checkout info every time you buy something.  Yet the adoption rate for it has been…sub-optimal.  So far we’ve seen about 6% of total smartphone users give Google Pay a try.  It’s a growing number, but it’s still not very big.  If it’s because Google Pay doesn’t do enough for users, then it may start growing faster.

So what’s new?

Today Google announced some new features for the app that make it more useful.  The biggest of these is that you can now use Google Pay to send money to friends.  With apps like Venmo, PayPal, and the CashApp this is nothing new, but it’s necessary for the Google Pay to become relevant as it’s one of the primary ways younger generations pay one another.

And if you haven’t used cash sharing apps like these before GET ONE.  They’re essentially the staples easy button for splitting bills at restaurants and paying back friends.   Google Pay has a challenge of gaining traction in this sector since there are already a few established apps and sharing apps are only as useful as their adoption rate.  But then again, it’s Google and they choose what apps comes preloaded on Android phones.  Chances are they’ll be alright.

But wait there’s more!

Another new upgrade for the app is that it will be supporting boarding passes and event tickets.  Companies like Southwest and Ticketmaster will be incorporated into the app to allow users to take one step closer to a one-stop shop.  These tickets will update with real time information if something like a flight delay takes place, and they’ll work alongside any loyalty cards you have.

The updated Google Pay app is rolling out today, but it will be a few weeks until it reaches everyone who uses it.  The long term goal is clearly for Google Pay to become your go to app for any circumstances. I’m certain we’ll see some more new features come up in the news soon, and I’m also sure you’ll be able to read about them here!

What are your thoughts on Google Pay’s changes?  Is it still lacking something essential for success?  Let us know in the comments below.

The Six Degrees Of Activity Lifecycles

Share if the site was helpful

The Six Degrees Of Activity Lifecycles

As an Android developer, one of the most fundamental concepts that you’ll learn about is Activities.  Activities are a Java class that focus on a single thing that users can do.  Many involve user interactions, and in most apps on your phone you can think of each page of the app as an activity.  Open Gmail and see your list of recent messages? Activity.  Click on one of those messages to open it in a new page?  Activity.

Activities are everywhere in Android development, yet many developers that are just starting out don’t fully understand how they function.  You might be able to get by without a full understanding, but this can be lethal to your app as it expands and becomes more complicated.  Lack of understanding opens up Pandora’s box for things to go wrong with memory leaks and debugging errors down the road.

Diving In:

So let’s take a blog post to discuss the Activity Lifecycle in a little detail.  We won’t get stuck in the weeds, but cover the basics enough that you understand what’s going on under the hood and can prep for smooth app development.

Just like humans have a lifecycle from birth to death, apps have a lifecycle they follow from when their first launched to when the user closes them.  There are six methods that can be called to change the state of an activity in Android:  onCreate(), onStart(), onResume(), onPause(), onStop(), and onDestroy().  At first glance these may seem similar if not identical to one another, but understanding the differences is key to a successful user experience.

onCreate():

This is the first of the 6 lifecycle methods called in an activity, and its invoked when (you guessed it) the activity is created.  In this method startup logic that should only happen once during an activity’s life takes place.  Examples of this might be to bind data to a list, or to instantiate class-scope variables.  The bottom line is that this is called once and only once.

onStart():  

Immediately after onCreate() comes onStart(). The start state of an activity occurs when it is made visible to the user.  This is where logic goes to prep the activity to enter the foreground and become interactive.  In other words the User Interface (UI) is taken care of here.

onResume():

Yes I know, it’s three different methods whose names make it sound like they all do the same thing.  Here’s the key difference with onResume() though.  onResume is called when an app has already been created and comes into (or back into) the foreground.  An activity is constantly interactive as long as it’s in the foreground for the user.

But what if your app includes a pop up message over the activity?  Well now that pop up has the foreground.  Your activity from before will enter the onPause() state (keep reading!) until that pop up goes away.  Once it does your app will resume, and thus the onResume() method will be called again.   For example, let’s say your playing a game and an alert interrupts it.  Obviously we don’t want the game to keep going when the user can’t see it, because that would be incredibly frustrating when the user returns and finds out they died while they were way.   So we call onPause() when an activity loses focus and certain resources need to either be cleared or put on hold.

onPause():

There’s really not too much more to this one other than what I said before.  It tags in and out with onResume() to create/delete resources when needed depending on if a user has focus.  It’s where the magic happens if you do things right, and where things go noticeably wrong if you don’t.

onStop():

When your activity is no longer visible, it has stopped.  This is different from onPause() in that your activity is entirely shrouded.  Instead of a pop-up that might cover half of the screen, a new activity may have taken place and covered your current one completely.  This is essentially where the app has can completely remove unused resources that the user won’t need when returning to the activity again.

onDestroy():

And finally comes our 6th method that wraps everything up.  This is called right before an Activity is destroyed, and as such you want nothing left hanging around.  If you forget to close up a loose end in onDestroy(), your app may begin to suffer from memory leaks and eventually bog things down.  Bottom line is that all resources should be released here if they weren’t in onStop().

These 6 methods essentially bounce the user between the two states of in the user’s foreground and in their background, but there are intricacies that go a lot deeper between them.  As such properly knowing when to implement each of them can be a life saver for your apps, and a huge time saver for you when you’re building things out and want to know what’s going wrong.

If you felt lost at all along the way of this blog, then you should check out Phonlab’s Android App Developer Course!  It’s a great way to go from writing your very first line of code up to publishing our own apps on the Play Store.

en English
X