Will Fuchsia be Android’s Usurper?

Share if the site was helpful

Will Fuchsia be Android’s Usurper?

Android is the world’s most popular mobile operating system, and for good reason.  It’s created both high end and affordable options for users worldwide to experience what it has to offer.  And what is has to offer has been time and time again improved upon.  That being said, improvements are always happening in the tech world, and 5 years from now Android might not hold it’s place as #1.  Here’s a curve ball for you: I’m not talking about Apple.  Android’s upcoming replacement may be Fuchsia.

Wait…what the heck is Fuchsia?

For a few years now a stealthy group on engineers at Google have been working on Fuchsia.  The project came into existence as a potential solution to Android’s limitations.  It’s being designed with voice interactions and security updates in mind where the current Android platform falls short.  And while this has been quiet, it hasn’t been locked down.  Some of the code has been open source since 2016 and outside app developers have been allowed to experiment with it.

The Fuchsia team has a higher goal than just more efficient software though.  They’re attempting to design something that will make interaction with all in-house gadgets a fluid experience.  Imagine a single operating system that controls all your speakers, tv, and other residential tech.  Now imagine also being able to interact with all of these devices by speaking to them.  Your house becomes a sentient being, somewhat like this post we wrote a few months back.

So Android will be gone in 5 years?

No, I definitely exaggerated in that first paragraph.  5 years would be an insanely quick turnaround for Android to completely fall off the map.  Android currently dominates as king with roughly 75% market share compared to Apple’s 15%.  Still, it’s far from perfect.  There are performance, privacy, and security concerns with out of date Android phones that need to be addressed, and a new software like Fuchsia could help jump that transition forward.  All the same we’ll be seeing Android phones for quite some time still, and P hasn’t even reached the market!

Fuschia is being developed with audio interactions at its core.  There haven’t been any apps built on it at a serious commercial level yet, but rumors are flying that we’ll be seeing a YouTube app with voice command soon.  My prediction is that over the next year or two Fuchsia is going to grow in the open source community until its eventual official launch, at which point we’re going to see a boom (hopefully a quicker boom than new Android version adoption rates!).  I’ll be keeping a close eye on it, so stay tuned for more updates.  And if you have any thoughts about Fuchsia or it’s potential let us know here!

 

Android P Releases Its Final Beta

Share if the site was helpful

Android P Releases Its Final Beta

While Android Oreo is just starting to hit its stride, Android P is making news too.  This week Google released the final beta preview of Android P before it’s official launch.  We’ve seen a few beta previews so far this year, and this one should be even closer to what P will look like when it launches.

According to Android VP Dave Burke this beta includes “final system behaviors” meaning Google’s new gesture-based navigation will be locked in and shipping with Android 9.0.  Of course there’s always room for improvement, and that’s a large reason betas exist, but this should be stable for installation on your main phone.  Google hasn’t mentioned any known bugs, so if you have a phone that can handle it out get the beta and let us know what you think!

What’s new in P?

We’ve talked before about Android P and what features it has to offer.  Spoiler: they’re awesome.  P offers a series of features that revolve around the idea of predictive analytics.

There’s an adaptive battery that takes into account what time of day you typically are running your apps, and if it doesn’t think you’ll be using them any time soon it shuts them off to save energy.  Couple this with the screen brightness which auto adjusts based on what you typically set it to throughout the day, and you’re looking at a much longer lasting battery life.

Apart from performance improvements, we also have completely new features that enable us to experience things differently.  One I’ve talked about before at length is Wi-Fi RTT.  Round Trip Time is a method of really getting to know your exact current location.  It’s accurate within about a meter, and does so by triangulating between multiple Wi-Fi access points nearby.  This improved location methodology offers some cool opportunities that just depend on how creative developers want to get.

Privacy Improvements:

There are also security improvements that come with P, and in an everchanging world of privacy that’s a key improvement.  Have you ever gotten a notification saying an app was running in the background when you didn’t think you’d been using it?  How about having an app crash in the background even though you haven’t opened it in ages?  That’s never a good thing to see.  P will prevent idle apps from performing actions such as accessing your camera (yes this is a thing!!).  P offers a series of security upgrades that limit what apps can do in the background in an effort to help protect user privacy.

How to get P?

First off, I’m so ready to stop calling it P and use it’s actual name. Unfortunately we’ll have to wait a little longer for that.  But if you want to get the beta on your phone today you can check it out on Android’s developer website here.  Give it a try and let us know your thoughts on it!  We’ll be sure to continue writing about developments in the software, so stay tuned for more.

 

 

 

Oreo: Coming Soon To A Phone Near You?

Share if the site was helpful

Oreo: Coming Soon To A Phone Near You?

It’s been just over 10 months since Android’s newest version (Oreo) began rolling out to devices. Almost a year, so let’s take a second to see how it’s doing. Well…it may be performing really well in terms of quality, but quantity is lacking.

How bad are we talking?

Every month Google releases Android’s distribution numbers showing how many devices are running each version of their operation system, and according to July’s numbers this year Oreo is active on 12.1% of active devices. As a point of reference, that puts Oreo at the 4th place position behind Nougat, Marshmallow, and Lollipop. There’s no denying this is a pretty sluggish speed for rolling things out (but to be fair it’s 0.4% ahead of where Nougat was during it’s growth phase).

So the trends show that new Android versions typically take more than a year to become the most used release, but this begs the question of why? Oreo offers some pretty cool new features such as picture in picture app usage and notification channels. Apart from battery life there aren’t too many reasons user’s would want to avoid upgrading to the newly offered software. But the issue is that it’s not actually offered to all users. There have been rollout calendars following which phones have adopted Oreo since it’s release, and the list of devices has grown slowly up until this month.

It’s Not The User’s Fault

A large part of why device updates are so slow is how fragmented the Android market currently is. Manufacturers often won’t bother with updating older pieces of hardware because it takes time and energy on their part that isn’t being put towards everything new. The end result is user’s being left high and dry. Even some new devices are hesitant to adopt the new software until it’s tried and true. User’s are able to flash their devices and test out other softwares if they so desire, but it’s not exactly mainstream to do so (as cool as it is!)

The bright side is that if you look at things over time they’re starting to ramp up exponentially. 5 months ago Oreo’s adoption rate was hovering around 1% (5 months after it’s release). Things were looking abysmal then even compared to other version’s growth rates, but thanks to a wave of updates this past month things are starting to look back on track.

Statistics Aren’t Perfect

It’s also important to note that the Android Developer dashboard I linked above relies heavily on Google’s Play Store to collect its data. This means that not every device running a version of Android is actually being accounted for in these numbers. The Play Store currently isn’t available in China (A $35 billion/year app market to be missing), and there are a few other factors at play attributing to uncounted devices. All the same it’s clear that Oreo is at about the same speed of rolling out as Nougat was, and we’ll likely see it enter the top 3 within the next few months. I for one am already looking forward to Android P though 🙂

Have you gotten Oreo on your device yet? What are your thoughts on either it’s performance or it’s rollout speed? Let us know in the comments below!

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!

 

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.

Making Material Design Work For You

Share if the site was helpful

Making Material Design Work For You

So you’ve built an app.  You’ve come up with a million dollar idea and you’re ready to build it and market it to the masses.  The concept is there and you know enough to develop it.  But does it look…good?

There’s a lot more to that one simple question than we initially see.  No matter what your app has to offer the world, people aren’t going to keep coming back to it unless it has a well designed interface.  This means that things should be both pleasing on the eyes and easy to use.  Users should find themselves knowing exactly where to look when they want something to happen.

So how can we design such an app?  There’s full courses for this one concept that you could enroll in, but here are some key highlights to making your app pop:

ConstraintLayout:

If you’ve taken intro to Android programming courses before then chances are you’ve done a little design with LinearLayout and RelativeLayout.  These are simple ViewGroups that you can use to organize the images and text on a user’s screen.  While these are useful at times, if used improperly they can start to bog down your app (learn why here!).

ConstraintLayout offers a more efficient way to group your apps exactly how you want them on your screen.  You can group your images in relation to one another on the screen or choose to position them a percentage away from your edges.  Really if you can think of a way you want to organize things, chances are there’s a way to do it with ConstraintLayout.  And without hurting your performance too!

Surfaces:

A simple way to think about the surfaces in your app is in terms of pieces of paper being stacked upon one another.  You can have views side by side or on top of one another, but however you organize things you want the user to know what’s important and what’s just extra.  Changing the elevation of your surfaces can bring what your want to the forefront and control where the user is looking.  It’s sneaky, but it makes a world of difference. 

By raising the elevation of a view a bit it begins to cast a shadow onto the views below it.  This way the end user gains a 3D perspective of what objects are closer to them and thus deserve attention.  Things like Floating Action Buttons (FABs) have this built into them already.  Use them wisely thought, as overcrowding your screen with elevated views can make it just look crowded and sloppy.

Custom fonts:

Style runs deep.  Deeper than just picking a font that you think looks neat.  Fonts with a very static and bold tone can give off the impression that your app is serious.  This can be great if you’re making something like a banking app that wants users to take it seriously and see it as secure.  But if you use one of those fonts with an art app it will be very unrelatable.  Likewise if you have a security based app that has fancy cursive writing users will naturally assume that the creators cares more about looks than performance and may lose faith in it.  Obviously I can’t pick for you, but I can tell you the decision matters!

Transitions With Motion:

As I said earlier your user should know what to do without even thinking about it.  This is where transitions and motion can come in handy.  Take for example a list of songs that a user can scroll through.  Well, if your user doesn’t know much about the app and their screen just so happens to load evenly (aka there are no songs cut off at the bottom), they might think they’re already looking at the whole list.  This would be tragic as they wouldn’t know to scroll down and might assume you just don’t have many songs available.

To fix this you could design your app so that when the list appears it slides in from the bottom of the screen.  This way the user sees it scroll a little upon launch, and their pattern recognizing brain will naturally assume it can keep scrolling.  It’s small, but given the right situation the impact can be huge.

What do you look for in an app when you download it?  Or more importantly what have apps lacked in that made you think twice about keeping them?  Let us know in the comments below!

Keeping Your Keys Safe

Share if the site was helpful

Keeping Your Keys Safe

At some point in your app development career, you’ll create an app that has secrets.  By this I mean there will be keys inside that you want to keep secure from prying eyes.  If someone else gets a hold of your private info, the results could be disastrous (or expensive).

Let’s say your app uses Amazon Web Services and your monthly bill runs about $350 a month. That’s fine because you’re making the money back through app usage.  That is, until a 3rd party gets a hold of your secret key and decides to use it for their own purposes.  Then when your next bill comes due you find that you’re being charged for $50,000.

Not an exaggeration.  This exact scenario actually happened.  So the lesson is painful but memorable: secrets should be kept secret!  Let’s use this blog to talk about a couple ways people tend to store their keys and what you should avoid.

Avoid pushing keys to github:

I’ll start with what may sound obvious.  That sight that you put all of your code onto so that people can publicly view it?  Yeah, don’t put your secret keys up there.  This sounds obvious, but recent studies have shown thousands upon thousands of keys are available on public git repositories.  It’s possible your using a free service and don’t care, but if you’re being charge even a dollar for the service you’re using, keep it close to your heart.

Storing keys as basic Strings:

DON’T DO THIS!  Storing a key as a simple string is just asking for trouble.  There a couple issues behind this, but first and foremost is that it’s incredibly easy to access.  If you read our primer on reverse engineering apps then you know that it’s possible for 3rd parties to decompile your app and look at its code in its (almost) original form.  Storing a key as a string means the hacker just has to glance over your code and look for something that looks like a key.  Then it’s theirs and they can do what they want until you change it. 

Defining keys in build.gradle:

This is better than storing your keys as Strings in any old file, but the end result is unfortunately similar.  A lot of people put their keys in build.gradle in such a way that it’s created in the BuildConfig file of your app.  The bright side is your gradle file isn’t decompiled along with the rest of your app, so secrets are safe in there.  The downside?  Well, that BuildConfig class they were just created in isn’t as secure.  Again, our Strings are exposed in a very simple to access way.

Securing keys with Android NDK:

Let me take a second here to say something important: There is no such thing as absolute security.  If you’re going to have a secret in your app, all you can truly do is make it incredibly difficult to find.  Take the proper precautions to keep things safe, and a hacker will have to decide if it’s worth the time/energy to get to whatever is hidden.

With that said, the Android NDK (Native Development Kit) can help us use C and C++ code with Android.  Why would we want to do this?  Well for starters NDK libraries can’t be decompiled, so the information inside is a lot harder to find.  There are ways to access this code all the same, but we won’t go into them here.  It’s not perfect, but this will throw quite a few entry level hackers off your tail.

Make your code complicated:

This one again goes to what I said earlier about complete security.  It won’t happen, but you can make a hacker’s life hell by making your keys as hard to read as possible.  Let’s take a very basic example:  If your key was 123456, instead of storing that, you could make it the sum of the strings “12”, “34”, and “56”.  How you can break this up depends on how creative you can get, but there really isn’t a limit.  It just means more work for you both upfront and down the road to ensure you understand everything your code is doing.

Keeping keys safe is crucial for a large apps success, so you need to take precautions to avoid disaster.  If you have any suggestions for great ways to hide Strings inside your app let us know in the comments below!

Google I/O, Until Next Year

Share if the site was helpful

Google I/O, Until Next Year

Well Google I/O is a wrap everyone, and if you tuned in then hopefully you left with some cool takeaways.  If not then don’t worry, that’s what we’re here for.  When the conference first kicked off we wrote about day 1 and its highlights, but obviously the fun didn’t stop there.  The following is a crash course selection of (in my opinion) the most important and amazing takeaways for and android junky.

Flutter:

If you’re an android developer, then your undoubtedly familiar with Java and segueing in to Kotlin.  You might not have heard about Flutter before though.  It’s Google’s mobile app SDK for easily creating high quality apps on both Android and iOS devices.  Written in Dart (a language developed by Google as well), Flutter works with existing code and is used to develop at ridiculously high speeds.  Here’s a great video from Google I/O that goes more in depth on how to use Flutter to enhance your material design.

Duplex:

Now this one blows my mind, and I know I’m not alone here.  When you think of a sci-fi future it’s reasonable if computers playing our personal secretaries pops into your mind.  This seems to be the present now. 

I’m very interested to see how Duplex functions successfully in real world applications, but the Google 2018 keynote showed a quick performance of the Google Assistant booking a haircut appointment for Google’s CEO, Sundar Pichai.  From an outsider’s view the conversation was impossible to distinguish from an everyday conversation between two people, and when it was done the Google Assistant confirmed to Sundar that the appointment had been booked and added to his calendar.  It’s only a matter of time before this is both client and server side so that duplex will be having conversations with itself to schedule our days, and that’s pretty wild.

Android P Beta:

Yes, I know we discussed android P in the last blog on Google I/O.  But you’ll have to bear with me because it’s happening again! As of this week the Android P beta is available on Pixel devices as well as 7 other flagship devices.  Android P brings all kinds of cool new features to the table.  A lot of these revolve around predicting what you the user are about to do.  There’s an adaptive battery that adjusts your screen’s brightness and what apps are running in an effort to both improve your experience and conserve precious battery power.

My personal favorite feature of P is Wi-Fi RTT.  Round Trip Time takes our current location services capabilities and amplifies them.  Essentially by triangulating between multiple Wi-fi access points nearby, a user’s position can be calculated within about a meter.  Just use your imagination for what applications this could come in handy for!  For more on Android P you can read our past posts or watch some Google I/O talks.

There’s lots more to take away from Google I/O, and honestly I’m cutting myself off here because otherwise I’d end up writing a paragraph or two about every session that I watched from the entire conference.  It’s a great year to be an android developer or even just own an android device.

What interested you the most from the conference?  Let us know in the comments below!

 

Google I/O Is In!

Share if the site was helpful

Google I/O Is In!

We’ve talked about Google I/O being on the horizon here before, but we can do that no longer.  It’s here! (Actually once it’s over we’ll probably immediately start writing about 2019’s event).

Yes, today marks the kickoff of Google’s 11th annual conference.  And as such the entire Android population has a lot of stuff to talk about.  Google I/O started off strong with its keynote mapping out some of the things to be discussed this year.  Here are some of the highlights of day one:

Artificial Intelligence:

As with most other places these days, AI was one of the most used buzzwords at day one.  It’s somewhat become an all encompassing term for any technological advancement that helps us.  Despite this, Google separates itself from the pack by bringing some pretty cool new features to the table.  Whether it’s self-writing emails or auto adjusting screen brightness to your preference, Google is working on slipping AI into every part of our days.

Actually it’s so much cooler than that.  In the video above at 3:10 you can watch the Google Assistant play as your personal secretary.  It makes a call to a local hair salon and books an appointment without the person on the other end ever realizing they’re talking to AI.  Scary cool.

Android P:

There’s been lots of hype about Android P in the past few months, and we got to see more today.  With it’s 3 key themes of Intelligence, Simplicity, and Digital wellbeing, Android P seeks to one up everything else already in your hand and provide a predictive, pleasant experience.  We’ve talked before about some of the new features coming with Android P, and today that list only gets longer.

Adaptive Battery is a feature aimed to conserving battery life by using (you guessed it) AI.  It studies your app usage patterns and then can dedicate more battery power to conserving the things that you will likely be using in the near future.  Along with this comes the Adaptive Brightness feature I mentioned above where your screen will auto-adjust given your preferences.

Not only does P look to alleviate your battery strain under the hood, but it uses its predictive analytics to bring apps you’re about to use to the forefront.  P is currently available on a select few devices (9 total), and if you’re interested in downloading it click here.  If you’re unsure what you’re doing and want support with flashing your phone, then check out our Smartphone Tech Course over at Phonlab.  Otherwise stay tuned and we’ll post a guide in the near future.

Augmented Reality:

As for the other big buzzword topic, Augmented Reality had some cool new features to display.  Maps have been souped up with the newest computer vision features to recognize where you’re looking in the real world and flash both directional arrows for guidance as well as information about local places.  If you’re walking down the street and a restaurant catches your eye, say goodbye to opening up yelp and searching for its reviews.

The camera has also become greatly enhanced with its new capability to recognize where things are in the real world in terms of depth perceptions.  Moving your phone around your room, office, or down the street you’re able to get live estimates of how far away things are.  This is sure to be crucial in a lot of coming apps.

There’s a lot more to come in this year’s Google I/O, and we’ll keep you updated here.  Is there anything in particular you want us to go more in depth on?  Comment below and we’ll give you all the info you could dream of!

 

 

 

 

Android’s Developer Website Just Got A BIG Makeover

Share if the site was helpful

Android’s Developer Website Just Got A BIG Makeover

If you’ve ever thought about developing for Android then chances are you’ve at least stumbled upon developer.android.com.  And chances are you left with a bitter taste in your mouth.  Fear not, things are looking up.

I remember my first time looking at Android’s developer docs.  I was a novice developer and as such the website was chock-full of useful information, but it seemed borderline impossible to navigate.  Countless topics linked into one another describing the different components of an app.  Couple this with all the attributes listed for each subject, and your brain quickly starts to spin.

What’s New?

I’ve discussed this navigation difficulty with others before, and that’s why I was so happy to hear the website just got a makeover.  First off, it looks much better.  Whitespace is used to give the new layout a sleeker more aesthetic look while the landing page emphasizes a preview for Android P.  Scrolling down from there the home page is neatly divided.  Sections for featured topics, material design, and where to begin your development journey pave the path.

But, of course, there’s much much more to this website than how it looks.  The most important thing is that someone who finds themselves here actually learns about what they’re looking for.  The new website does a much better job of guiding users who are in uncharted territory.  Selecting “Docs” in the top banner takes users to this page.

In here the core developer topics that every android programmer NEEDS to know about are listed.  Clicking on each of these links will take the user to a simple explanation accompanied with an intro video.  Then immediately below these are trees of related/more in-depth topics.  The result is an easy cursory explanation of each topic and then more complicated explanations for those that want to learn more.

Material Design and More

The website has tons of sections and features, but one other one I’d like to highlight is the “Design & Quality” tab.  It’s important to remember that there’s more to developing that just creating sound logic.  Users of your apps also have come to expect high quality layouts and design patterns.  This section of the website helps explain to developers how to wow users with apps that know what they want before even they do.

In summary, the old developer website was certainly useful, you just needed to know what you were looking for.  The new model offers a much easier guide for new entrants. It takes them by the hand and shows them both what topics are easy to comprehend and what fundamentals should be learned first.  Overall I think the new website is a vast improvement to its somewhat clunky counterpart, and I look forward to using it as my development journey continues.

Have you check out the new site and feel that it’s still missing anything?  Let us know in the comments below!