Let Firebase Cover the Basics For You

Share if the site was helpful

Let Firebase Cover the Basics For You

When it comes to writing code, the less you have to do the better.  You want control over how your applications behave, but if you can piggy back off of other developer’s work then that’s generally a good thing.  And if you’re hoping to be an app developer, then one of the best tools for piggy backing is Firebase.

Using others to your advantage:

If you think about it even developing the most basic app takes the work of countless others.  Someone else had to develop the programming language you’re writing in, someone else had to build the IDE (probable Android Studio) that you’re developing on, and someone had to…well you get the point.  Any modern-day invention was not created from nothing, it came about thanks to the ground work being done by something that came first.

This doesn’t mean you can’t be innovative.  It means that there’s nothing wrong with using 3rd party libraries and tools to make your development journey easier.  If you don’t have to worry about the basics then you can focus on what makes your app great.  Ok enough justification, let’s talk about how you should use Firebase to make life easier.

Authentication and Data Management:

How many apps do you have that require you to sign in to fully use features?  Of those how many let you create and account through Facebook?  Users hate having to create sign-in info, a decent percentage won’t even go through the process because of the extra 10 seconds it takes.  So including an option for one-click sign in makes it more likely your app will succeed from the start.  Firebase makes this feature easy to leverage allowing you to create a sign in screen with companies like Facebook, Twitter, and Google. 

When users sign up Firebase keeps track of their info and allows user management to be easily configured.  If a user gets a new phone they can log in and Firebase will associate them with the same account.  Firebase also has a database feature allowing you to create and store JSON info, so users can interact with one another and store information easily.  Let’s say you wanted to create that new social media app which lets people post pictures and message one another:  Firebase should be your go to.

Analytics:

When you release an app it’s best to have a game plan for what’s next.  What if users love one part of the app but never use another?  Well if that’s the case then you should aim for a redesign that either brings in new features or directs the users attention to things they are more interested in.  Of course if you release an app and people in other countries start downloading it you can’t exactly track them down and ask them how they’ve been using the app.

This is where analytics come in.  Firebase gives you the capability to monitor user events (anonymously) so you can see which features are getting the most interaction.  If you have a search bar in your app that no one ever clicks on, it’s either time to drop it or move it elsewhere to try again.  Analytics can keep you in know for how your app is behaving and what should change.

Crashlytics:

And on the topic of what should change in app behavior, crashes are about the worst thing a user can experience.  You may be getting 1 star ratings in the app store because your app shuts off randomly for some users and you don’t know why.  Firebase offers Crashlytics to look at the stack trace details for every crashed application.  If there’s one button in your app that is broken and slipped through your checks when publishing, now you’ll be able to see that it’s responsible for the crashes and act accordingly.

Firebase offers a ton of other features that can make development easier and the user experience more fluid.  These are just the tip of the iceberg and features I enjoy using on a daily basis.  If you want to learn how to incorporate Firebase into your apps then checkout Phonlab’s Android Development Course!

 

Android Auto Is on A Roll!

Share if the site was helpful

Android Auto Is on A Roll!

We all love our smartphones.  Unfortunately, some of us love them a little too much.  As fascinating as they are there are certain times in life when our attention should be elsewhere.  One of these is when we’re driving, as evidenced by the number of accidents that happen thanks to texting.  Luckily Android Auto is on the rise to increase the number of hands-free experiences.

Android Auto:

A few major announcements have come this month announcing partnerships between Google and automakers planning to include the Android operating system in their vehicles.  For those that don’t know, Android Auto is a mobile app developed by Google to mirror features from Android devices to a car’s dashboard or a headset.  By doing so users are able to interact with key features such as Google Maps, playing music, and texting without having to ever pick up their phones. 

Android Auto supports touchscreen dashboards as well as button-controlled head-sets.  Along with these is the more encouraged hands-free voice command.  It was first revealed at Google I/O in 2014, and now is available in 28 countries around the globe.

Upcoming rollouts:

The Renault-Nissan-Mitsubishi alliance has signed a multiyear global agreement to embed Android in vehicles.  Toyota will also be allowing Android Auto devices to connect directly to cars for the first time.  And as the most recent development Jaguar has announced plans to add CarPlay and Android Auto to their vehicles.  The story is pretty much the same from car company to car company, but it’s clear that adoption is the trend.  And that’s a good thing both for innovation and safety.

The end goal for Android Auto is to create a seamless experience for users moving from their phone into their car.  If there are no apps that a user can’t experience hands free, then there’s no motivation to use your phone while driving.  And if there’s no motivation to use your phones while driving, car accidents are going to be much less frequent.  You could say it’s a noble cause, or you could say it’s just a business decision to get user’s more engrossed in the product.  Either way it has a positive externality.

What are your thoughts on what the future holds for Android Auto?  Do you think Apple’s software in vehicles is giving it a run for it’s money?  Let us know in the comments below!

 

Flutter Is About To Take Flight

Share if the site was helpful

Flutter Is About To Take Flight

As android developer’s we’re always looking towards the next thing.  Whether it’s a new feature or a new way to do things more efficiently, innovation is good.  Take for example the multi-part Kotlin post showing how to write more efficient and easily read code.  Google has fully adopted Kotlin as the next language for Android, but there’s another innovation on the rise: Flutter.  Earlier this week Google launched the final preview of Flutter 1.0, and it looks like it has a bright future.

What is Flutter?

You may have heard of flutter (we’ve written about it here at RootJunky before).  It’s Google’s personal mobile app SDK designed to make app making incredibly simple.  It’s written in Dart, also developed by Google, and works with existing code to develop at incredibly high speeds.  What’s more is that it’s not Android specific.  We all know Android is where it’s at, but we also should acknowledge that there’s another audience out there to market to.

Flutter allows you to create Android and iOS apps, as well as for FuschiaSo no matter what market you’re trying to hit it’s a good skill to have under your belt.  As a freelancer you’ll find clients few and far between that want an app developed for just one side or the other.  If you’re hired to a company as an android or iOS developer specifically then you’ll get by easier, but I’d still recommend working to get both down as it simply increases your marketability.

Material Design updates:

So far Flutter has been a cross platform development tool, but it’s given Android the majority of it’s attention.  It’s considered a “first-class tookit” for Material Design, but the frameworks compatibility with Apple’s UI guidelines has only been acceptable.  This newest release preview is revamping the Cupertino widget set with dozens of updates to help fit iOS design guidelines.  The important thing is that developers are able to build layouts that both Apple and Android users will be comfortable with.  Here are a few sample designs built with flutter on their home page:

While this allows us to create apps that fit the design guidelines of both operating systems, it’s also important to note that Flutter doesn’t use native platform widgets directly.  This means that there’s nothing stopping a developer from using Cupertino widgets in and Android app or Material Design with iOS.  Not necessarily a good idea, but hey the more freedom the better right?

App size reduction:

Another big perk of using Flutter to develop your app is that it’s size will drastically be reduced.  So far we’ve seen a 30% reduction in app size.  Quite simply this means that your apps won’t bog down users as much and they’re be less prone to remove them when space becomes an issue on their phones.  The Flutter team is committed to bringing that number even lower, but as is that’s already a huge step in the right direction.

If you’re interested in getting started with Flutter or learning more then go to flutter.io.  We’re sure to see plenty of it down the road.  Let us know your thoughts in the comments below!

 

That Missing Guide To Kotlin Part 2

Share if the site was helpful

That Missing Guide To Kotlin Part 2

In part one of our Kotlin series we began exploring the newly adopted language.  We saw a few examples of how it can make our code more concise and user friendly than Java including type inference and inline constructors.  In part two we’ll continue to show how Kotlin can make your code easier to work with while focusing on one dreaded Java roadblock: The NullPointerException.

If you’ve written anything in Java before then you’re familiar with NPE’s.  It occurs when you attempt to interact with a variable’s value, but it turns out there is no value to interact with.  Your compiler can’t see that there’s no value available, but at run-time your system checks for it and then crashes when it can’t be found.

Kotlin to the rescue

While Kotlin is 100% interoperable with Java (99% really as we’ll see soon) it’s fundamentally different in a few aspects.  One of these is nullability.  In Java every variable has a default value.  This is the value it can fall back on if you never explicity say what value it contained.  For example when you declare a boolean variable, unless you specify its value, it will be false.  For any variable that isn’t a primitive type, the default value will be null.  This can be really useful at times, but it allows us to accidentally try to grab a value when there isn’t one.

In Kotlin its possible to completely avoid this situation. Every variable that is declared is either a nullable type or a non-null type.  What this means is that along with declaring what type of value (Int, Boolean, custom class) your variable holds, you declare whether it is ever allowed to be null or not.  Here are two varaibles declared in Kotlin.  The first can never be null, while the second is nullable.

As you can see, the question mark is used to show a variable has the possibility of being null.  If there’s no question mark in the variables declaration, then you are safe to use it in every situation without risking it throwing an NPE.  This means that you’ll never have to write if statements checking if a variable is null to play things safe. Goodbye useless lines of code

Nullablility In Action

When using non-null type variables, we don’t have to check if there is a value present.  But for other situations we still must take precautions.  One way that Kotlin allows us to do this concisely is through safe calls.  A safe call looks similar to the traditional method of retrieving a value, except we include a question mark at the end of the variable.  So

Becomes

By doing this we can almost read the code as if it’s English.  We’re asking “does the pet exist?”, and if the answer to that question is yes then we move on to the name characteristic of our pet.  If there is no pet that has been created at this point in our code, instead of the app crashing our variable will be given a value of null.

This becomes incredibly powerful when we start chaining safe calls.  Let’s say we want to check if a company has an HR department with an employee name Toby who at tuna for lunch.  Instead of writing a null check for each of these before interacting with them we can write

If along the way any of these things doesn’t exist, then the code will finish the statement returning null and not interacting with any of the variables past the break.  Without an HR department the code won’t crash, but instead our employee variable will be set equal to null.

Control Is A Good Thing

This is probably the most common feature of Kotlin that you see people talk about, and it’s because of how powerful it is.  Not having to deal with null values is amazing, but even when we have to our code can be concise and clean.

The language can also smart cast nullable variables into non-null given the proper verification at first.  So if you had a nullable variable and then explicitly check if it wasn’t null, then you wouldn’t need to use any ?’s moving forward when accessing that variable.

Kotlin isn’t perfect, but when it comes to dealing with null values it has everything that Java has to offer with some additional perks and changes.  We’ll continue exploring some of Kotlin’s advantages in part 3.  In the mean time if you have any questions about how nullability works let us know in the comments below!

Rumors About Rumors About the Pixel 3

Share if the site was helpful

Rumors About Rumors About the Pixel 3

Over the past few months rumors have been floating around left and right about the upcoming Pixel 3 and Pixel 3 XL.  We’ve written about leaks here before as a serious of photos have surfaced revelaing potential designs.  Of particular interest are the XL leaks with the notch taking phone manufacturers by storm these days.  These are so interesting not because of what they show, but what they may be hiding.

The newest rumor going around is that the Pixel 3 XL we’ve seen thus far is a fake.  And not simply fake that someone decided to make up, but rather a fake that was released by Google to throw people off.  It’s a bold claim, but not entirely impossible.  Here’s why:

Hating The Notch:

When the XL leaks first surfaced a lot of people got excited.  And likewise a lot of people were upset to see that the notch was involved.  The 3 is set to bring back other exciting features like wireless charging, yet the notch seems to be what gained so much attention.  Some well known YouTubers have critiqued the design on their channels.  Google has taken note.

According to Jon Prosser, one of the YouTubers who spoke out against the leak, Google reached out to him and asked for a very specific clip of him speaking badly about the design.  He found out from other YouTubers that the same request was made to quite a few of them.  Google didn’t say why it wanted the footage, but simply asked for it.

What’s Google’s Game?

So why would Google want to use footage from well known reviewers bashing its product?  Well, the natural conclusion is that it’s not really their product.  If people hate the design that’s been leaked and it turns out that’s not actually the desing Google is unveiling in October, then no harm no foul.  Actually if anything it could help Google as they market that they’ve listened to people’s feedback and are moving in a direction that consumers want.

It’s possible (but not confirmed) that Google has artificially leaked things in an attempt to generate a buzz about the new phones.  If that’s the case then it’s definitely worked.  As to the probability of this actually ocurring…well that’s another story.  Only time will tell, but you could argue it’s pretty farfetched.  It would be incredibly hard to keep this kind of fake leak in house up until now.

Pie and The Notch

The Pixel 3 will also be the first phone to come with Android Pie which includes notch support.  The two don’t have to come in a package deal, but it would be a little strange to see that as a feature in Pie and not have it avaiable to users who buy the first phone with it.

What do you think of these rumors about rumors?  Whether you think its plausible or ridiculous let us know in the comments below!

 

 

That Missing Guide To Kotlin

Share if the site was helpful

That Missing Guide To Kotlin

 

In 2017 Kotlin began taking the Android community by storm.  Google adopted it as a first class language, and shortly afterwards developers everywhere renounced Java in favor of the newer, sleeker language.  That change isn’t going away.

I won’t lie, when I first was exposed I didn’t see what all the fuss was about. There were tons of articles that talked about how revolutionary Kotlin was compared to Java, but other than avoiding NullPointerExceptions they didn’t seem to go in depth at all. Because of this all I saw was slightly different syntax.  Boy was I wrong.

Kotlin is not perfect, but it does have a lot to offer that you don’t really notice until you start writing code with it.  This is part 1 of a 3-part piece will dive deeper into some of the things Kotlin has to offer.  Ideally after reading these posts you’ll have a better idea of how Kotlin can make your codebase shorter, more efficient, and easier to read.

Let’s start with the basics

Before we get into anything fancy, let’s explore a very basic concept that Kotlin offers: type inference.  In Java when you’re declaring a variable you have to do two things.  First you have to say what type your value is going to be (String, int, byte, etc.).  Second you have to name your variable.  Additionally you can set the variable to a value, or if it’s a member variable you can let it default to null, 0, or false depending on its type.

Kotlin tries to alleviate this (even if it’s not that painful) with type inference.  The compiler is smart enough to know what kind of value you’re working with based on what you set it to. Instead of writing

You can write

var is the generic term for variable in Kotlin, and the compiler knows that we’re dealing with a String because the value “hello” is a string.  Ok, that’s really not very cool. But compare these three lines in Java and Kotlin:

A small difference, but once you start writing with it you’ll be surprised how nice it is to not have to give that split second to declaring the right type.  The var keyword will work for any type that we attempt to put in it, even customized classes.  The keyword val functions the same way except its value is final.  In fact, everything in Kotlin is declared final by default unless otherwise specified (more on that later).

Saving Space

Ok, so we can replace a type declaration with the words var or val.  That doesn’t really save us a ton of time or space in our code.  Let’s look at something a little more impressive: Constructors.

Let’s say the app your building has a database that you need to get into to provide users with information.  To manage this data you’ve built the class DataManager.  Here it is in Java:

And here it is in Kotlin.

What’s happening here?  Well we’re declaring the class the same way with the words “class DataManager”, but Kotlin allows for an inline constructor.  This means we can create our constructor inside of the class declaration by adding our parameters “variable1” and “varaible2”.  Notice that we had to declare the types of each of these two variables along with the word val.

But…Type Inference

This seems to go against what we just learned about type inference, but don’t worry its not.  Along with the type inference we’ve seen so far you can declare the type.  There are some situations where both are necessary/appropriate (such as an inline constructor).  What this code is doing is saying that our class will have two var’s that are Strings, but since we haven’t actually created an instance of the class yet there’s no way our compiler would be able to know the values are Strings unless we explicitly declare them to be.

By including val before each parameter we ask Kotlin to both use it as a constructor argument as well as declare it as a member variable for the class.  And Kotlin classes also take care of getters/setters for us automatically, so we don’t need to write those.

From 20 to 2

So by declaring my two member variables inline I’ve knocked my code down from 20 lines to 2.  Yes, 10 times less code.  Obviously not everything changes this drastically, but this is a great example of how Kotlin can both speed up your coding as well as make it neater.  And really by no means does the readability suffer here.  Reading this Kotlin code we can see clearly that DataManager takes 2 parameters in its constructor, and unless we specify otherwise, Kotlin will always take care of our getters and setters.

Again, this is just one instance where Kotlin saves code, but we could take this example even farther by overloading our constructor with default values.  That’s an example for another Kotlin post down the road, but hopefully even this one gives you a taste of how your codebase can shrink when you convert it.

If you want to go DEEP down the Kotlin rabbit hole, then Phonlab offers classes on it in the Android App Development course.  I’d highly recommend you check it out, as well as stay tuned for part #2 of this!

Monetizing Your Apps With Ads

Share if the site was helpful

Monetizing Your Apps With Ads

App making is a beautiful things.  You can literally write down what you want to happen, and watch your creations come to life.  It’s both a science and an art.  Unfortunately sometimes app making alone doesn’t pay the bills.  It does if you work for a company or you freelance your skills to other people, but if you want to make apps on your own, you need to find a way to cover your costs.  Enter ads.

Of course, no one likes ads.  They’re an evil necessity though, allowing goods and services that would otherwise cost money to be enjoyed for free. The user gets a free experience, the company displaying ads gets publicity, and you the developer get money! It’s not a get rich quick scheme, but trust me, you’re going to get downloads a lot quicker if you can make your app free.

Who do I need to call?

Before you pick up the phone and start calling local companies to see if they want a spot in your app you should know its easier than you think. Rather than having to contract with advertisers yourself, Google does the heavy lifting.  AdMob is a mobile advertising company designed to link developer’s creations with companies looking to advertise.  All you the developer have to do is add a spot in your app for ads to appear, and Google takes care of the rest.

It doesn’t matter how they do it or what steps are involved, but Google will gather and distribute the advertisements companies have paid them for.  You may be advertising for Coca-Cola, or Tide.  You don’t really know and you probably don’t care.  Meanwhile every time an ad is displayed to a user and then clicked on you earn a couple pennies.  Not enough? Well get a few thousand downloads and then we’ll see how your bank account is doing.

How to get started?

A lot of job descriptions I’ve seen include “experience with AdMob” as if it’s something that takes a while to master.  This couldn’t be farther from the truth.  There are a few steps to get things set up initially, but the process isn’t complicated.  We walk you through creating an account, adding the necessary code, and publishing your app at on the Play Store.

Here’s AdMob’s website where you can create an account. Once you do that the two things you’ll need to do are update your xml to include a view for your ads, and then create a new AdRequest to load your ads.

One Size Fits All?

There are actually different kinds of ads that you can include in your app.  The instructions above are for Banner ads.  These are small ads that appear either at the top or bottom of the users screen while they are using the app.  User’s may not even notice them if you use them correctly.  Then there are other ads such as Interstitial ads.  These are much more invasive taking up the user’s entire screen for a short time.  User’s really don’t like these, so make sure you use them wisely (maybe in between levels in a game).

The bottom line is that ads can be really beneficial to you as the developer, and if done correctly hardly an inconvenience to users.  It’s a win-win.  We didn’t go into the weeds on anything here, but if there’s something else you want to know about ads or AdMob, just let us know in the comments below!

 

The Man In The Disk

Share if the site was helpful

The Man In The Disk

If you’ve ever taken an introductory class on cyber security (or if you’ve explored the topic on your own), then you’re likely familiar with the term MITM.  Man-In-The-Middle attacks are security breaches where a 3rd party butts their way in-between two parties attempting to communicate.  Obviously, this is not an ideal situation for either party, and a new variation of MITM is taking Android users by storm.

MITD

Man-In-The-Disk (MITD) is the name that’s been flying around the past few days.  But before we get into its details, let’s discuss a little more of what MITM attacks entail.  A MITM attack is when an unknown party inserts itself between the two trying to communicate.  When this is done that malicious party is able to spy on the conversation happening.  Even worse they might altar what is being sent.

As an example let’s picture an everyday conversation between two friends.  Person 1 and 2 are talking to one another about their plans for tonight.  And let’s say person 3 is bitter they didn’t get invited.  Person 1 might send 2 a message online asking “Want to meet up at 8?”, but 3 intercepts it, changes it, and then forwards the newly modified message to 2.  Now when 2 opens the message it instead says “On second thought there are cooler people I’d rather spend my time with”.  (A riveting example, right?)

The idea is simply that a 3rd party can both invade and modify conversations between clients and servers.  And a lot of the time the invasion can be a lot more critical than hurt feelings.  MITM attacks can be avoided by taking proper precautions and such as certificate pinning.  But that deserves a whole post of its own.

So How Does It Happen?

MITD attacks are a specific type of MITM that takes advantage of careless storage on users phones.  MITD attacks can allow 3rd party users to access information that is stored on an android device’s external storage.  This is something that many apps don’t use, but researchers at Check Point recently found that many app developers (including Google itself) are not following the recommended security precautions for avoiding this vulnerability.

There are a couple different methods for storing information in Android apps.  Android’s developer website has a good page laying out the differences between them.  If you want to go deeper into when using each is appropriate PhonLab covers this in its Android Development Course.   For the most part Android security is very sound due to sandboxing.  This is the idea that each app silo’s its information and only makes it available to others if either the user allows it or if both apps are on board for sharing.

External Storage

External storage is essentially a part of the device’s storage card that is shared by all applications. Google suggests that developers should add extra validation if apps utilize this storage functionality.  And unfortunately it seems that a lot of apps currently aren’t doing this.  Due to prioritization of external storage, data coming in to the phone may be subject to MITM attacks before it even reaches the app meant to use it.

Ironically Google was not following this advice either.  Since the report came out they’ve addressed the places where they were falling short, but it seems many other apps have made the same mistake and will be named after they correct their issues.

In conclusion, there is a security scare going around for android apps, but don’t overhype it.  If developers take the proper precautions to prevent MITM attacks (something Google explains easily how to do on their site) then this danger fades away.  Security is an ever-changing field, but this breach is one that can be easily avoided if developers do their due diligence.

 

Fortnite Could Change The App Market As We Know It

Share if the site was helpful

Fortnite Could Change The App Market As We Know It

Fortnite, the first person survival shooter game that has taken the world by storm, has finally made its way to Android.  I’m sure it will be a blast to play, but this isn’t the place to read reviews of videogames.  So why are we bringing it up?  Because Fortnite with its popularity has brought some light to a very deep discussion for what the future of apps looks like.  It’s more than a videogame, it’s the start of a movement.

Some Background

For those who aren’t familiar with the game’s success thus far, Fortnite has become one of the most popular games of all time and is played on PCs, gaming consoles, and iPads/iPhones.  It’s been developed for all of these different systems so that virtually anyone that has an electronic gadget has the opportunity to play, and for months now its been building up to its Android debut. 

This would just be another story of a successful video game, except that Epic Games (Fortnite’s creator) has made a bold decision for its distribution strategy.  They decided to forgo the common pathway of sharing their app on the Google Play Store.  Instead they will be distributing the app in their own digital store and keep the 30% “store tax” that Google would otherwise keep from in-app purchases.

Fortnite Paves Its Own Path

“It’s a high cost in a world where game developers’ 70 per cent must cover all the cost of developing, operating, and supporting their games.”  Epic said about the decision.  “And it’s disproportionate to the cost of the services these stores perform, such as payment processing, download bandwidth, and customer service.”

Epic has shared its opinion that the app market is a highly monopolized one where developers are unfairly being taken advantage of.  Google and Apple have grown to such high user adoption rates that users don’t get apps from anywhere else.  This means that as a developer you either play by their rules or you don’t play at all.  Epic isn’t the first entity to share this sentiment, and the EU has even recently filed a lawsuit against Google for monopoly abuse.

Breaking The Cycle

Fortnite just happens to be such an incredibly popular game that it could potentially survive playing by its own rules.  Sure it won’t get as many downloads as it would on the Google Play Store, but it could still prove a successful venture which would open a serious discussion about other companies following suit.

To give Google a little credit Android phones do have the capability to download apps from 3rd party sources, it’s just not as common or streamlined a process.  Apple on the other hand has completely rejected this philosophy and gives users the choice of their app store, or users jailbreaking their phones to get what they want.

In the age of tech giants its hard to not just accept the fact that these monopolies exist and are becoming solidified.  So when a discussion is brought to the table about a potentially unfair situation arising it’s imperative that we keep an open mind and think about what impact can be made in the long run to ensure a healthy a thriving market economy.  Anti-trust is a sticky, sticky issue, but that doesn’t mean it shouldn’t be discussed.

The Google Play Store is a great tool that tons of developers (myself included) get to use to share their creations with the world, but every system needs checks and balances or else it will eventually experience abuse.  It will be interesting to see how successful a venture Fortnite on Android will be without involving itself in the Play Store.  What do you think about Epic’s decision?  Let us know in the comments below!

 

Android Pie is Fresh Out Of The Oven

Share if the site was helpful

Android Pie is Fresh Out Of The Oven

Today Google officially dubbed the newest version of the Android operating system as Pie!  Along with this naming they’ve also released the first official version of it to Pixel phones.  Android users around the world are debating whether this was the right dessert name or not, but either way we know that Pie has some great things in store for us.

The Build Up:

Over the past few months we’ve seen a few beta version of Pie released on a series of smartphones, but this official release is only available on Pixel phones.  People who signed up for the Android Beta program will receive the update by the end of this fall though.  Google also said it’s working to launch/upgrade other devices sometime this year.

Those details are pretty vague, and if Pie behaves anything like other Android versions, it could be over a year before it’s adoption rate breaks double digit percentages.  All the same it’s officially available to Pixel users and it has a name.  That’s plenty for now, but let’s also not forget that Pie is available in its beta format on a number of different devices.

A review of Pie:

We’ve talked about Pie and its cool new features a few times here at RootJunky.com.  The new software is designed with predictive analytics and AI for battery power as some of the main features.  The idea is to improve things behind the scene for users.  Pie monitors and adjusts screen brightness as well as what apps are in the background during different times of the day.  It gets used to user’s habits, and then preps itself in advance to recreate that behavior.  AI is definitely a buzz-word, but that doesn’t mean it can’t have some perks.

It also features an official dark mode option in settings, something Android user’s have been asking for for years.  Notifications also offer features such as smart replies for texting and a new feel to them, so the changes in this version are both front and back end.

Aaand the Notch:

Of course when we’re talking about new looks we have to mention the notch.  It’s taken a hold of both the iOS and Android markets so much that Google has actually come out and banned phones with more than 3 notches from getting Google support.  Somewhat crazy to even think more than 3 notches could exist on a phone right now, but you never know!

One more feature that I have to mention that I’m very excited for is the change to rotation.  Instead of just locking your rotation or having it rotate every time you accidentally turn your screen, you now have optional re-orientation.  Android Pie will display a small button when it detects a screen rotation, and if you select this then the phone knows to readjust, and if not then you can continue doing things as you were, undisturbed.

The Pixel 3 will be coming out on October 4th just a few months from now, and it will likely be the first phone to be released with Pie as it’s initial operating system, but Pie is now available to those who are willing to take the steps to get it.  I’m excited to see it grow this year, and I’m also very interested to see what Q is going to be named.

What are your thoughts on Pie’s name?  Could Google have done better?  And if so, do you think it’s new features will make up for it? Let us know in the comments below.