Sunday, June 26, 2016

What is Activity

Hi, today we will talk about one of the basal things in Android application an Activity.

How to understand an Activity

Activity is the basis of your application and entry point as well.

From the user side, it's a single focused thing that user can do while interacting with your application. Most of the Activities interact with the user and take care of creating a window for your UI. 

Also, using multiple Activities to represent various tasks helps a programmer to make app's code less complex and easier to maintain. 

Activities can be used as fullscreen or floating windows and as a part of another activity (in an ActivityGroup, note that it's deprecated since API 13).

Activity insights

Firs of all to start an activity you should define it in your manifest using <activity> tag inside <application>. Like this:

<manifest>
  <application>
      <activity android:name=".MyActivity" />

  </application>
</manifest >

Every class that extends Activity should implement these two methods
  1. onCreate(Bundle) - which is an entry point of your Activity, where you should initialize it (or recreate it we will talk about it later). You can think about it as a kind of constructor for your class. Usually, here we set an activity layout using setContentView(int) and set all the necessary fields including ones that relate to our layout using findViewById(int).
  2. onPause() - this one is called when the user leaves your Activity. At this point, you can save all data that can be necessary for future Activity launches (usually using ContentProvider which I will talk about in future posts).
There are many more events in Activity lifecycle, let's look at these.

Activity lifecycle

A set of activities is managed as a stack it means that when a new activity is started it is placed in the top of the stack and remains there until it destroyed or another activity is started. On the other hand, previous activities are below the new one in the stack and remains there while all the upper activities exist.

While in the stack, an activity can be in one of the four states.
  1. Activity is running (at the top). While in this state activity performs all the actions.
  2. Activity is not in focus but visible, or paused. It means that there's another activity that is semi-transparent or doesn't take all window's space so OS still should maintain UI of background activity. In this state, activity is still alive and can perform actions, but it's not recommended because it can be killed in the case of extremely low memory, while in this state. This is why we save all the data in onPause().
  3. Activity is not visible, or stopped. In this case, activity is still alive and still holds the state and member information, but there is more probability that it will be killed to free memory for something else.
  4. Activity is dropped, as I said OS can drop activity if it needs to free memory for something that has more priority. It does it by asking activity to finish, or simply killing its process (it's one of the reasons why you should save data before paused state). When the user decides to go back to this activity it's completely recreated, the developer should consider it and restore it to the previous state.
Here's a diagram from Activity documentation that shows most important parts (colored) of an activity lifecycle and all the methods that are called during this lifecycle. 
As you may see, activity exist even if app process killed it's just remaining in the activity stack and waits until the user navigates to it again, in this case, it should be recreated, using saved data. When activity is finished or system should completely destroy it, onDestroy() method is called and OS shutting it down.

In the onDestroy() method activity app should release all the remaining resources (close all the connections, shut down all the threads related to it etc.)  

Why lifecycle is so important

As I said, the system can decide to kill your activity if there's some higher priority process that requires memory. In this case, you should save your activity state in order to recreate it, when user will navigate to it again.

But this is not the only case when you should recreate an activity. Another reason to recreate it is configuration change.

Such things as orientation change, language change, or input devices plugging (like a keyboard) will cause your activity to go through its' lifecycle straight up to onDestroy() and after that system creates a new instance of your activity and calls onStart(Bundle) on it with savedInstanceBundle that contains the state of previous activity.

The reason to do so is quite simple. The fact is that in different configurations you app can use different resources, for example, you may want your app to look different in portrait and landscape orientations because in landscape you have more horizontal space.

However, you may want your app to not be recreated after some configuration changes. For example, if you don't care about whether a keyboard is plugged in or not (or you want to handle it yourself). 

In this case, you can tell the system to just warn your activity about a configuration change instead of killing it.

To do so you should use android:configChanges  attribute in activity's manifest to specify those changes. After that whenever specified configuration is changed onConfigurationChange(Configuration) will be called on your activity, and you can handle it yourself.

Also, activity's lifecycle in many ways controls lifecycles of all it's fragments (I will write about these in future posts).

Ways to save the state of an activity

I hope that when you have read the above, you have that one question. How to save the state of my activity? So if you do, read on.

There are two ways to do so. And these two ways should be used in different cases.

Case #1: You need to save some underlying information. Consider your user made some changes in his profile in this situation when the user leaves edit activity you should save all the applied changes to the database. Doing so you kill two birds with one stone. You update your database with new information and save the current state of your activity and when the user comes back to it the app will read it from the database.

As was said it's preferable to do in onPause(). It looks something like this.

@Override
protected void onPause() {
  super.onPause();
  //Always call the superclass method first, it performs operations required by system
  
  //Save applied changes to the database
  
}

@Override
public void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  // Read from database and populate the views
}

Case #2: You need to save the state of your UI. Let's refer to our example with edit activity. The user can start typing something in EditText and leave you application because of an important message or something, and when he returns he wants everything in text fields to be as he left it. To achieve this effect you should use onSaveInstanceState(Bundle) and populate the bundle with the data you need to save. 

Actually, SDK already takes care of it but if it didn't you would write something like this

@Override
public void onSaveInstanceState(Bundle outState) {
  outState.putString(EDIT_TEXT_STATE, mEdit.getText().toString());
  
  super.onSaveInstanceState(outState);
  //Call superclass method as well. As I said, it handles states of some elements for you.
}

@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState); // Always call the superclass first
   
  // Check if there is a state Bundle
  if (savedInstanceState != null) {
    mEdit.setText(savedInstanceState.getString(EDIT_TEXT_STATE));
  }
}

Summary

It's pretty much all the basics of activities. With it, you can build activities that don't care if system kills them, they will stay in the state that they were left. For complete reference about activities visit the documentation page and the guide. Here you can learn about intent-handling and result activities.

See you next week, peace!

Tuesday, June 21, 2016

Google starting Android Developer Certification

Certifications for developers is not a new thing. For example, Microsoft offers a wide range of certifications not only for developers but for almost anyone who works with their products (Office, Skype, Microsoft Server etc.). Oracle, Cloudera, and a plethora of other IT companies make certification programs for their products as well. 

These (in theory) help employers to connect with those who search for work in their field. It's (should be) kind of a confirmation that you have these skills that you're talking about.

But in practice, it doesn't work that well, many certified programmers don't know much about real software development process and don't have the necessary experience to start working in a team of qualified developers. So, employers did understand that and ceased to pay attention to certificates.

The most important criterion in employment is what applicant really did and can do, his portfolio and capability of learning from mistakes and failures. 

Meaningful certification

To be at least a little bit significant, certification should lead a developer through a development of a real software product that developer can put in his portfolio. 

It should be not just a piece of paper that endorses that you did pass a one-time exam but a process during which you use those skills that should be certified to build something really valuable.

Maybe something that you can really sell or publish in an app store (probably with some modifications).

Associate Android Developer Certification

And with that being said, I want to talk about Google's certification program.

Google didn't certify developers before. It's their first certification program despite they have really wide range of product for developers: Angular, Go, Dart, great amount APIs, Google Play Services etc.

And I think the reason why they didn't do so is that they are hiring many developers every month and face the problem of certificates. But seems like they come up with an idea of how to make certification better.

First of all, there is a performance-based exam that should show the candidate's ability to perform real-world tasks in a real-world project. Also, the grading system is fully transparent and that will allow employers to understand for what this certificate was given.

With these two improvements, a certificate should become more valuable for employers, it becomes not just a piece of paper but something that shows applicant's performance during development not just during the exam. That's what both employers and employees want from a certificate. 

What is in the future

The first certification program is for Entry-level Android developers and this, I think, is for the testing. Google want to know how it will work out and maybe they will have to change the way of certification in future. But if it works out well, I think, there will be other programs for high-level developers.

Also, the reason why they choose android for the first program is that it's highly popular now among new programmers and this will allow them to get more feedback. So it becomes clear that they're just testing their system for something bigger.

As for me, I'm already signed up for this certification program and waiting for July to pass an exam and get my first software development certificate. :)

And if you are just starting out like me, go ahead and sign up, even if it's not that good, it definitely will not hurt.

It's all for today, go ahead, sign up and good luck!

See you next week!

Sunday, June 12, 2016

Google Code Labs


The best (and the easiest as well) way of learning is by doing. But to get the idea of what you need to do you need someone to tell you (this is the main purpose of this blog).

Google Code Labs are doing exactly that. In codelab, you go through the lesson and build a small app that contains some feature like Google Sign in, Android Pay, Face Detection etc.

There are also codelabs that teach you to use new tools of SDK and Android Studio like ConstraintLayout.

At the moment, I've tried one codelab called "Build a Material Design App with Android Design Support Library" and have learned about ViewPager and NavigationDrawer also you can learn how to implement flexible space with image during this code lab.

One flaw that me and my friend noticed is the lack of comments in the code. Most of the codelab you will be asked to copy/paste/rewrite some code to make things work the desired way.

But for me, it was an encouragement to learn about used thing trough reading docs and blog posts.

There are a plethora of codelabs for any kind of developer. Whether you want to learn about Android, The Web or Firebase integration there is a codelab for you. Also, there are codelabs about Google APIs, Unity game engine, Virtual Reality and even one about Google Codelabs.

There is the list of codelabs that I want to complete during this week and I think that you will be interested in them too.

Building Apps that Sign In with Google


The reason why I want to complete this is that I always signing in every app with Google account if there is a possibility to do so. All these registration steps exasperate me and if I can start using an app without them I will and I want my users to be able to do so.

Echo with Android Howie Library

This I want to pass because one of my friends asked me to build an app for introverts :). The idea is that you will record something like in Whats App but you instead of sending it to someone you will save it on your phone and will be able to listen to it later. And this codelab will help me with this app.

Using ConstraintLayout to design your views


When I saw ConstraintLayout at Google I/O Keynote I reacted skeptically. I still think that ability edit source code gives you more flexibility and control over layout that any drag-and-drop layout builder. 

But I want to give it a try. At the end of the day, developers (me as well) will send feedback about it and it'll become better with time.

Automated Performance Testing and Android Testing codelabs


Proper tests will never hurt your app. Actually, developers dislike testing because the main goal of it is to break your app. But in the perspective testing will help you to provide your users with high-quality product and updates. I think that it worth breaking your app if it will lead your app to success.

Face Detection with the Mobile Vision API

Do I even need to explain why I want to complete this codelab? 

IT'S FREAKING COOL!

Face detection is awesome! You can not only detect faces, with Mobile Vision you can also catch facial expressions, and all of it on MOBILE PHONE. We didn't even think about it 5-7 years ago and now it's just a deal of passing a codelab.

All these I want to complete in a week. Likely, I will update this post after completing every codelab and will tell you what I think about it. So be tuned in follow me on TwitterG+ and Facebook to not miss future updates.

It's pretty all for today. See you in the next one!

Sunday, June 5, 2016

Benefits of Awareness

Today apps are more and more bound to the users context and developers seek for the way to provide a unique experience for each and every user.

One of the first apps that were designed to do so was Google Now a Google's smart mobile assistant that was meant to provide the user with information like weather, traffic, flight delays even before the user needs it.

To make this kind of apps, you need to be aware of user context. What is around him? Is it raining? What is he doing?

To answer these questions, you need to use sensors, a bunch of APIs and do it all in the background. It means that your app will drain the battery and affect the system health even if it's not accessed at the moment.

Bad influence on the battery life can be the cause of your app deletion from user's smartphone.

But these battery and performance optimizations can be a cause of pain for the developer. You need to develop the main idea of your app to make it clear and straight.

And here comes Awareness API.

As was said in my previous post I will tell you about what it is and how you can use it.

It didn't come out yet, but you can sign up for early access today and try it for your app.

What it is

As I said Awareness API was made to provide your app with information about the user's context.

It can give 7 different types of context like location, place, activity, time, weather, beacons nearby, and headphones status.

The nicest thing about the API that it manages its' impact on battery life automatically. So you only need to request the data about context and you can almost forget about managing system health when doing so.

The API itself consist of two distinct APIs that your app can use depending on how you want to use context information.

The first one is the Fence API



Fence API is like a watcher that will tell you when the event that you need to react to is happening. 

Generally, it looks like this, your app telling the API "hey, I need to know whenever my user is walking near a Whole Foods store", in this case, you use two types of context: activity and place. When the user's context match this conditions your app will be notified about it even if it's not running at the moment.

Using this information you can send a notification, for example, about a planned shopping trip.



And the Snapshot API

This API lets your app get information about the context that surrounds user at the moment.

In this case, your app is already performing some operations and then request the API, "Hey, I need to know what user is doing now and where he is". It can be useful for apps that store some kind of data produced by the user such as photos, videos, audio records etc. 

For example, you can request weather conditions and location for your photo app to make your gallery more convenient, classify photos by location or weather or kind of places (work, home, coffee shops etc.) they made at.

It also can be useful for analytics. You may want to know if what conditions your users use your app more often to make it better for this certain situations.

Types of context

Here are 7 types of context and what information they can provide
  • Time - this will provide you with current local time.
  • Location - this is the pure location on the map. Latitude and longitude.
  • Place - place and the kind of place (if can be identified).
  • Activity - accurately detected user activity like running, walking, riding a bicycle etc.
  • Weather - current weather conditions at the user's location.
  • Headphones - are headphones plugged in?
  • Beacons - namespace, type, and content of nearby beacons.

Using these you can build extraordinary apps and provide your users with content based on their current context and all this with minimalized impact on battery life and system health.

Share your use-cases in the comment section below.

This is all for today, see you next week, peace!