Mobile or Web (or both)?

Many beginning developers are questioning themselves about the area of the software development they want to build their career in and I was one of them (I'm still beginning, but I did choose already).

Today there are several major areas you can focus on.

1. Operation Systems (Windows, Android, iOS etc.) - here you would write pretty low-level code that would handle interaction with the hardware.
2. Game Developing - could be broken down into many subcategories, such as game engines, UI in games, gameplay etc. 
3. Mobile - building apps for mobile devices running Android, iOS, Windows Phone etc. This area is growing really fast nowadays because of new mobile devices. Android is embedded in TVs, cars, VR and IoT (I personally think, that someday Android development would be one of these major areas of software development itself).
4. The Web is growing just as fast as mobile, and the reason for it is online clouds. Almost everything is going to the web, it's convenient, you can access it almost everywhere, and in developed countries, it's fast and cheap. 
5. Data science - this one is about big data analysis, machine learning and sometimes artificial intelligence. Note that it's actual science. You would be learning much theory before doing something actually working, unlike the other categories.
6. Embedded software - this is low-level software that is built for one particular product, for example, for a digital camera. This category got a second breath with the emergence of the Internet of Things.

There are more, but it could take a whole post to list them all. If you think there is a category that definitely should be on this list, please drop a comment I will include it.

Today I want to talk about the two most popular (for now) categories: mobile and web development.

Mobile VS Web

Some people think that there is some kind of competition between these two. And they are right, in some way.

Mobile and web developers always try to make the experience on their platform feel better that on the other. 

Which is better, create a mobile app or just make an ada``ptive design of web version for mobile devices?

What is great about this competition is that it's healthy, it makes both platforms create new ways of interacting with the users, enchant them, simplify their life, and make them amazing.

I even heard the opinion that you should both web and mobile. Which, as I think, is wrong because if you want to build the career it's better to focus on something instead of picking all into sight.

So if you want to be a developer what should you pick? Unfortunately, it's not that straightforward but let's look at advantages and disadvantages of every category and I hope it will help you to decide on your own.

Web Development

Advantages	Disadwantages
Cross-platform. You can run your app on every device that has a web browser.	Runs only with browser so if you want to build offline app using web technologies (e.g. Atom) you need to ship a browser with it
A huge developers community	You can only use JavaScript and it's kinda slow so you limited in optimization.
Fast development cycles (write->build->test->repeat)	You do not have the computer resources control unless you're using some framework for building offline apps

Mobile Development

Advantages	Disadwantages
Over a billion of people have a mobile phone	There are two major platforms and you should choose only one (while it's better to have your app on both)
A huge developers community as well (for Android and iOS).	Slow development cycles.
Full control over resources.	You should care about optimal resources usage.
You can use native low-level processing (for example NDK) to optimize your app

For me, mobile is more convenient. And I don't mean that Web is worse, it should be your choice.

If you want to build something more interactive it's better to learn mobile, if you want your apps to be accessible from anywhere and anything that has a browser it's better to get to Web development.

I hope I helped you to choose the direction to go.

See you in the next one!

The Boy Scout Rule in Coding

The Boy Scout Rule is the simple rule that can solve a huge problem of software development within a team.

It states: "Always leave the campground cleaner than you found it". Sounds pretty simple, right?

But, despite its' simplicity, not every developer follows this rule (me neither sometimes).

Sometimes, it's just kinda hard to take responsibility for someone else's code. I tell myself: "If someone else made that mess, why I should even work with it?".

But undoubtedly, it's way better for everyone to take care of the code you working on with a team. All the same, we are programming in the high-level languages and those were made for people who work with machines, not the machines themselves.

What is clean code?

To keep the code clean you obviously should know what clean code is and what it takes to write one.

Let's formulate some qualities of the clean code.

1. Clean code is focused.

You don't want your methods to consist of various blocks of unrelated code. You want one particular method to do one particular thing.

First of all, it's easier to remember what the method does and if it has a good name (which is a quality of clean code too) then the user of this method don't even need to know what it does behind the scenes, he can use it out of the box.

But you can say, what if my method should do many things behind the scenes? The key to handling this problem is an abstraction. 

For example, take the Glide library which I discussed in one of my posts Image Loading With Glide. To load an image you should handle HTTP connection, media decoding, memory and disk caching etc. But Glide makes it look like one thing, loading an image.

2. Clean code is expressive

I already talked about it when mentioned that method should have a good name.

Good naming can make your code self-documenting and make documentation less important and in some cases even redundant.

Let's think of a simple example.

  int method(int[] array) {
    if (array == null || array.length < 0)
      return 0;

    int integer = array[0];
    for (int number : array)
      if (number < integer)
        integer = number;
    return integer;
  }

It's pretty easy to determine what this code does, but it would be even easier if we choose better names for the method and variables.

  int min(int[] numbers) {
    if (numbers == null || numbers.length < 0)
      return 0;

    int currentMin = numbers[0];
    for (int candidate : numbers)
      if (candidate < currentMin)
        currentMin = candidate;
    return currentMin;
  }

I just changed the names, nothing else, it does the same thing (and now even the name implies that it searching the minimum in the array). But now it looks much much better.

To be honest, when I was writing the example of bad naming, I made a mistake. I wrote `number > integer instead of `number < integer` and noticed it only when I changed the names. In such a simple procedure, such a huge mistake just because of bad naming. Imagine what can happen when you work on a huge system!

3. Clean Code is minimalistic

Some studies say that it's better to keep your classes and procedures small. 

For classes, there is a magical number that states how many public methods it should have this number is 7. 7 public methods per class makes it easy to remember all the responsibilities of the class. But it doesn't mean, of course, that every class should have only 7 methods, just keep this number close to it.

For methods, there is no concrete number. Robert "Uncle Bob" Martin in his book "Clean Code" says

The first rule of fucntions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Funcions should hardly ever be 20 lines long. 

While Steve McConnell in "Code Complete" says the following

The routine should be allowed to grow organically up to 100-200 lines, decades of evidence say that routines of such length no bore error prone than shorter routines.

Some people (including Steve McConnel) say that a method should fit the screen without scrolling which is, in my opinion, is the good estimate, despite the fact that everyone has different screens.

I personally think that you should break down the method as soon as you find yourself trying to remember what does some part of the method do. Probably, when someone will look at this part he won't understand it, so it's better to replace it with well-named procedure.

These are in my opinion are top 3 qualities of clean code. There are more of course and you can find all of them in already mentioned books: Code Complete by Steve McConnell and Clean Code by Robert C. Martin.

Now when you know what clean code is you can start following The Boy Scout Rule of coding and make your and your co-workers' live easier. Sometimes it would be easy as renaming some variables. Sometimes it would require changes in the architecture of the software but it always worth it because you are the one who will work with this code.

Now let's make our code a better place! Maybe there is a badge for it ;)

Image loading with Glide

Image loading seems like an easy task at the first glance but as every task, it has its' own caveats.

First of all, you probably want to do this asynchronously because you don't want to flood your main thread with that kind of tasks.

Then, you want to cache images so you don't load them every time your activity of fragment resumes.

You need to handle error cases when the network is not available or server is sending you garbage or doesn't send anything at all. If you don't do this it will definitely harm the user-experience.

After all, you probably need to do some pre-processing steps before showing the image to the user such as cropping, resizing, reversing etc. Also, it would be convenient to have an easy way to set an image in an ImageView.

You may ask: "Why do you think that you know what I need and want?". The answer is that you're not alone. Android developers already made tons of apps that use pictures from the network.

And what happens when many developers are facing the same problem? Right, they make (most likely an open source) library.

The libraries

There are many libraries that solve the problem and, on the high level, they do it pretty much similar. For example, if you just want to load the image in the image view you will write something like this

String imageUrl 
    = "http://i1.kym-cdn.com/photos/images/facebook/000/002/109/orly_owl.jpg";
LibraryClass.with(context).load(imageUrl)
    .into(imageView);

No matter what concrete library you use (except it's something really exotic).

The most popular ones are Picasso, ImageLoader, Glide, and Fresco (made by Facebook). It's hard to say which one is the best one and developers say that picking one is the matter of taste. But I think that it's worth to mention that Gilde and Fresco support gif loading and Glide is recommended by Google.

Facebook engineers also say that Fresco is more optimized in terms of memory usage but when considering this note that Fresco is not as well tested as Picasso, Glide, and ImageLoader (which is the oldest one).

To show examples I will use Glide because I have been working with it.

Image Loading

First of all, to use Glide you need to add a Gradle dependency.

compile 'com.github.bumptech.glide:glide:3.7.0'

There are several ways you can use an image in your app. You can load it directly in an image view or save its' bitmap to use it anywhere else, for example, in a notification.

Let's consider first use-case. To simply load an image in an image view you must write exactly the code above except you must change LibraryClass to Glide that is it will look like this 

Glide.with(requester).load(imageUrl)
    .into(imageView);

I intentionally changed context to requester to emphasize that it could be not context. with() methods accepts Activity, Context, or Fragment as an argument which in my opinion is very handy.

There are many small features that will make UX of your app much better. For example placeholders, you definitely don't want your user to watch on the empty screen while your images are loading, your app should indicate that it's loading something to show to the user. Placeholders are the great way to do that. It can be a message that says that image is loading, loading animation or simple gray pane that shows that something should be there.

And placeholders are really well implemented in Glide (as well as other libraries) and it's easy to use. That's how it's done.

Glide
    .with(requester)
    .load(imageUrl)
    .placeholder(R.drawable.image_placeholder)
    .into(imageView);

You can show error image (the image that should be shown if something went wrong) using the same way

Glide
    .with(requester)
    .load(imageUrl)
    .error(R.drawable.image_error)
    .into(imageView);

In both of these methods, you can pass a Drawable object as the argument instead of resource id.

The second feature that can enhance UX of your app is animations. When your image appears out of nowhere in a blink of an eye it's kinda little disturbing and doesn't look like things act in the real world, which is a violation of Material Design guidelines.

In Glide as well as many other libraries there is a built-in way to animate the appearance of your images. In Glide you can do this using crossFade() method.

Glide
    .with(requester)
    .load(imageUrl)
    .placeholder(R.drawable.image_placeholder)
    .error(R.drawable.image_error)
    .crossFade()
    .into(imageView);

Also, you can pass an int as an argument to set the duration of the fade animation.

Load as Bitmap

To load image as bitmap you just need to use method asBitmap() set the constraints and use get() like this

Glide
    .with(requester)
    .load(imageUrl)
    .asBitmap()
    .placeholder(R.drawable.image_placeholder)
    .error(R.drawable.image_error)
    .into(width, height)
    .get();

Note that get() should be used only in a background thread which, in my opinion, is fair. If you don't use your image in UI why would you download it in UI thread?

Summary

Image loading includes many steps that cannot be removed from the process and these steps sometimes, not hard but dreary to implement. But the code as everything else ever written is (if properly constructed) reusable and programmers make new libraries every day since the beginning of the programming era.

Libraries as Glide make it possible to load images in just one line of code providing you with the instruments that will make your users' experience better. 

P.S. If you want to dive in and learn about Glide in details visit their javadocs and GitHub Wiki.

Introduction to Firebase Database for Android

I've already written a post about Firebase and its' features but features highlighted in the post are additional to the core functionality of Firebase.

What is this core functionality? Well, this is the thing that Firebase started from. It's Realtime Database.

A real-time database is, basically, the database that can effectively store dynamic data. By dynamic, I mean data that is constantly changing for example stocks prices.

Firebase Database

So Firebase has its' own built-in real-time database which you can use as a backend for your app. Let's consider the structure of this database.

First of all, it's worth to mention that this database is not relational and doesn't use tables as you might expect. It uses JavaScript Object Notation (JSON) to store the data so it's kinda "object-oriented" database. 

I think that this it an advantage at least for developers because JSON, in my opinion, is easier to understand than relational tables if you're working within an object-oriented language. Also, using JSON eliminates some pitfalls that are associated with relational tables but, as always, brings some others.

The second important thing that Firebase Database is stored in the cloud and Firebase provides its' own hosting for it so you don't need to care about it. The amount of space you allowed to work with is described in your subscription plan.

And the most important feature in terms of development is that you can set data change listeners that will fire every time data in the database is changed and moreover give you a snapshot of changed node in the object tree.

Now when we have a big picture let's dive in and look how it works.

Closer Look

From this point, I assume that you have an account for Firebase.

First of all, we need to create our application.

App creation window

You can choose any name you like whereas app URL should be unique for every app registered in firebase. 

When you successfully created your app you can enter your dashboard and see an empty database.

Now you can go ahead and add some data directly from the dashboard or use the SDK to do so from your Android, iOS or Web app. Let's try do add something manually.

Manually added nodes

The important thing to notice that every node in the tree has its' own URL, we will use it later to refer to the concrete piece of data and attach a change listener to it.

Android SDK

For instructions on how to add Firebase to your Android app visit this page.

To use the database in our app we should add this gradle dependency in our app 

com.google.firebase-database:9.2.1. 

Now let's write some data to our database using Android app. One of the greatest things about this SDK is that you can write into the database using Plain Old Java Objects (POJO). This feature gives you an opportunity to keep your code clean and on the consistent level of abstraction.

Let's create POJO for our messages

public class Message {
    private String author;
    private String message;

    public Message (String auth, String msg) {
        this.author = auth;
        this.message = msg;
    }
    
    public String getAuthor() {
        return author;
    }

    public String getMessage() {
        return message;
    }
}

Note that for every field in Message class there is a public getter. It's a rule of SDK. If you don't have a public getter for some of the field you may get an exception so be sure to check that.

And the actual write method will look like this.

private void addMessage(String author, String message) {
    Firebase ref = new Firebase("https://tomasteryexmpl.firebaseio.com/chat/messages");
    Firebase messageRef = ref.push();

    messageRef.setValue(new Message());
}

It should be a method of the class that handles your database workflow. You can also pass composed Message object instead of author and message separately.

Let's do some clarifications. The ref variable stores a reference to the list of messages that we made earlier.

Method push() creates the unique key for the new entry in this list and returns its' reference in the database so messageRef stores reference to the new message.

When you have your reference you can easily write data to it using setValue(Object) method. And now you're done this method will successfully write your messages to the database and each message will have its' own unique key. Kinda easy, huh?

Let's look what happened to our data.

Added a message with unique code

Read the Database

In Firebase data reading differs from standard databases. To read from a database you should attach an asynchronous listener to the node you want to read. This listener will be triggered first time for initial state and every time data in this node is changed.

There are 2 types of listeners: ValueEventListener and ChildEventListener. The difference, basically, is that ValueEventListener will send you a snapshot of the whole object when it's changed while ChildEventListener will only send a snapshot of the changed child.

To listen for the messages it will be better to set a ChildEventListener to messages node so that we don't get the full list of messages every time a new message is sent.

private void setMessageListener() {
    Firebase ref = new Firebase("https://tomasteryexmpl.firebaseio.com/chat/messages");

    ref.addChildEventListener(new ChildEventListener() {
        @Override
        public void onChildAdded(DataSnapshot snapshot, String previousChildKey) {
            Message newMsg = snapshot.getValue(Message.class);
            addMessageToUI(newMsg);
        }
        //... ChildEventListener also defines onChildChanged, onChildRemoved,
        //    onChildMoved and onCanceled, covered in later sections.
    });
}

And that's pretty all that you need to do to set a child listener to a node. Now every time a message is added to the database addMessageToUI will be called and you will see your message in your app. There are libraries that can do that for you (like Firebase UI) but these are out of the scope of the post.

To get more information about reading the database visit this page in Firebase Docs.

This is pretty all that you need to know to build a basic Android messaging app. For me, it looks extremely easy in comparison to all the backend mess that you would set up without Firebase.

What is Content Provider

Today I will continue my "What is *Android component*" series and tell you about one of the essentials parts of an Android application a content provider.

Previous posts from this series:
What is Activity
What is Fragment

The problem

First of all, let's consider the problem that this component is meant to solve.

It's often useful for applications to retrieve data from other apps on the smartphone. Many pre-installed Android apps have the data that can improve the user experience of other apps. 

For example, phone book has information about the people that are probably your friends and it can be used by social networking app like LinkedIn to connect with someone you know in this social network.

User dictionary has information that can help users type faster by providing them with the most used words when they use a custom keyboard.

So, it would be convenient to have some tool that can share those kinds of data.

Something that would provide a consistent interface across all the apps on an Android device.

The solution

The solution came from the pair Content Provider and Content Resolver. These 2 Android components not only solve the problem but give much more benefits for an Android developer, but first things first.

Content Provider

What is great in Android SDK is that most of the components' names speak for itself.

Basically, all the Content Provider does is provide access to the content of some app.

There is a database in the core of a Content Provider and Content Provider adheres concepts of encapsulation and hides the structure of the underlying database and provides its' own methods to work with it.

To request data from a Content Provider you should know a Uri so that it knows what kind of data you want. Usually, in the implementation, a content provider uses UriMatcher to distinguish different types of queries.

For example, you can request all weather for particular location using something like this content:/com.weatherpp.app/mounain_view but when you need weather for particular date you may need to use another Uri, probably something like this content:/com.weatherpp.app/mounain_view/06/17/16 and Content Provider is meant to understand what you want using this Uri and give you this data. (By the way, com.weatherapp.app part is called content authority)

Content provider should implement an interface that allows to insert, update and delete data from the database. To be precise, all content providers extend the ContentProvider class but I don't want to go into implementation details to keep things abstract and easy to understand.

Content Resolver

Content Resolver is a thing that determines which content provider to query using the Uri you give to it.

How does resolver do this? It's pretty easy, to be fair. Remember the content authority? This com.weatherpp.app thing. Before using a content provider you should register it in the system through your app's manifest and provide its' authority. And using this authority Content Resolver can understand which provider you want to use, somewhat similar to how a content provider decides what piece of data you want to query.

It's worth to mention that unlike content provider you don't need to implement content resolver. It's already implemented and built-in in the system. You can get it using context.getContentResolver() in your application.  

When to use Content Provider

So in which situations you should use content provider?

As I said, content provider gives many benefits to developers besides sharing data between apps. So in my opinion answer is: anytime you're working with a database.

To explain my answer, let me tell you about the benefits.

Abstraction

The first, and I think the most important, benefit is an additional level of abstraction between the database and an object using data.

Abstraction, as I see it, is always a good thing because it allows you to think in terms of the problem domain and not think about small, tricky details of implementation.

Encapsulation

This thing kinda supports abstraction, without encapsulation abstract things are not abstract.

Encapsulation also saves you from thinking about structure and implementation of your database operations.

Scalability

This is an outcome of abstraction. First of all, you can be sure that if you have different layers of abstraction changes in low-level implementation won't affect high level. 

So when you add a table to a database or new column to a table you don't need to change all the code that uses this database/table you simply change you provider's code or don't change anything at all.

Flexibility

Actually, you're not required to expose all your data to other apps if you're using content providers.

So you can use it for your convenience and if you want to expose it you can do it by changing only one line in the manifest. You change it and voila you have your very own API.

Consistency

If you use content provider you have a consistent interface for all your data operations such as insert, delete, and query. And it's consistent not only inside your application but inside the whole platform.

And as Reto Meier said once

If you chose to not use content providers, well you chose poorly.

Top 6 learning resources for Android Developers

In my opinion, learning is a lifelong process, and that's a popular point of view today mainly because it's information age. Knowledge now is the most powerful tool, not the only one that is needed for success, though. Furthermore, without it, no other tool can help you achieve it.

I think that you already know the importance of learning if you read this blog. So today I'll give you my top 10 learning resources for Android Developers.

1. Udacity

Udacity is my favorite online-learning platform. And I think it'll always be. The enthusiasm and passion with which its' CEO and co-founder Sebastian Thrun develops and maintains the platform are encouraging.

First of all, it worth to mention that Udacity is not an Android tutorials platform. There are a plethora of courses and nanodegrees for different professions and specialties, such as iOS, web development, tech entrepreneurship, machine learning, cloud computing and so on and so forth.

With his platform, Sebastian Thrun wants to repair today's broken education system. Provide learners with an affordable source of knowledge and give them an opportunity to enter the business area of their dreams and moreover, perform great in this area.

For Android developer, there are 2 great nanodegrees. One is for beginners and the second one is for intermediate. Both are made by in partnership with Google that makes this information a first-hand. In my opinion, this is a great opportunity to learn for those who participated in the platform development.

The one for beginners was introduced not long ago, at Google I/O 2016 I believe. It contains Android Development for Beginners wich was the first course I've completed on Udacity, and many other courses that will help a starting out developer to build a portfolio full of basic Android apps. 

And the second one and the one that I'm in the process of passing Android Developer Nanodegree. This one is great so far and as I think is most complete Android course out there. It'll teach you how to build advanced applications that require careful design and implementation.

These nanodegrees are $199/month and $299/month for Nanodegree Plus (you'll get a job offer or 100% refund) and if you graduate in 12 months you'll get 50% tuition refund. Also, you can complete all the courses for free but you'll not get benefits of nanodegree such as code reviews, personal instructions etc.

2. Android Weekly

This is not an educational platform like Udacity. It's not even a blog or something. It's a newsletter, but the effort that its' editors put in every newsletter is priceless and make it such a great source of new information about Android. 

I mean, this is just a mediator, but such a great mediator. Android Weekly is not only for those who wants to learn about Android but also for those who just want to be up to date with everything that happens in Android community.

It provides you with information about latest blog posts from all around the web, new podcast releases, new youtube videos and even conference and job offerings. Without it, I would probably bash my head against a wall searching all this.

I really encourage you to visit Android Weekly and subscribe to their newsletter.

3. Android Hive

Yet another great way to learn about Android. The author of this blog is Ravi Tamada and he is as said a Hardcore Android Developer.

There are so many great, valuable, and detailed tutorials about Android and  technologies related to it.

Almost anything you can think of in Android Development is already written as a tutorial on this blog. Really recommend it!

4. Android Developers Blog

Who can get you in the insights of Android better that people who made this? I think no one.

And this is what all about this blog is. The people from Google's Android team sharing tips, tricks, insights and new features of Android.

If there's something that should be discussed in Android community, be sure that there is already a blog post about it on Android Developers Blog.

5. Google Code Labs

I've already written a blog post about these the other day, but it never hurts to mention them another time.

Great tutorials with on the go instructions about special features that you may want to implement in your Android app.

6. Android Development Training

And of course last but not least the Android Development Training. 

Here you can find most up to date information about crucial parts of Android Development provided with code samples from real Android apps and detailed explanations of all what is going on in the code.

If you stuck during development and don't know how to implement a common feature this is the first place where you should go for help.

Also, in the Udacity courses this training often acts as a reference for students.

So here's my Top 6 of learning resources for Android Devs. If you know something great and this is not in this list please share in the comment section below, I'm learning too so extra supply of knowledge can not hurt.

It's all for today, see you in the next one! (or in the comment section :) )

P.S. It would be douchy to include myself in this list but I'm writing about Android Dev too!

What is Fragment

The concept of a fragment is tied very tight with the concept of an activity. And if you don't understand clearly what activity is I encourage you to read last week's post first and then return to fragments.

Also, here's the post that will help you to get a nice overview of basic Android classes such as Context, Activity, Fragment, Thread etc.

What is the problem

With the growth of popularity of Android system more and more developers started to pay attention to it. More and more apps were developed for Android and it entailed more and more complexity in these apps. In particular, this complexity was growing in activities and layouts.

Possible solutions

First of all, developers wanted something that would be reusable in several activities. And this, as I think, gave a birth to ActivityGroup. 

As the documentation says it's

A screen that contains and runs multiple embedded activities

which seems like a bit overhead. In this implementation, every activity has its' own context, while developers wanted something that would be a part of one single activity context.

And with the arrival of tablets, this problem became more obvious. And at that moment of time Google introduced the fragment concept. Intentionally, fragments were designed to meet exactly the needs of tablet layouts, but now there are a plethora of use-cases for fragments. 

So what is Fragment

Fragment represents a behavior or part of the user interface in an activity. Multiple fragments can be used in one activity to represent different parts of the activity. Also, one fragment can be used in different activities.

A fragment itself doesn't know about other fragments in the activity part of which it appears to be.

By definition, it's independent part of an activity and can do its' job even without other fragments. So if you fall into a situation when one of your fragments depends on another fragment you should think about the design of your application.

A fragment always should be embedded in an activity and the activity's lifecycle actually defines the fragment's lifecycle. If an activity is on pause then all of its' fragments are on pause. If an activity is destroyed then all of its' fragments are destroyed. If an activity is running not all (if at all) of its' fragments are running, though.

While activity is running, a developer can manually and independently control the fragment's lifecycle. For example, he/she can add new fragment, or delete old one or pause it. 

Also, while doing these transactions it's possible to add them in the backstack so the user can revert a transaction by pressing "back" button.

And it worth to mention that fragments operate on the same level of abstraction as activities.

There are two types of fragments: static and dynamic.

Static fragments

Generally, static fragments are fragments that will not be replaced by other fragments during the lifecycle of an activity. To add an instance of this fragment to your activity you can use the <fragment> tag in the XML file that represents your activity's layout. And that's it your fragment will work as if it would be an activity. Also, using this approach you will be able to find this fragment using its' android:id.

Dynamic fragments

I think that the name is self-explanatory. Yeah, right, dynamic fragments are the ones that could be added, deleted and replaced while corresponding activity is running. These fragments are added in ViewGroup programmatically using FragmentManager. To refer to this type of fragments during runtime you would use a special tag that should be unique for every fragment in the activity.

A couple of use cases

The most popular and easiest use-case for fragments is the implementation of master-detail flow on tablets.

Master-detail flow is the technique that used in many mobile apps. Generally, it's when you have a list of items that describe something briefly and the screen that shows details of this something. For example, in an email app, you don't see a full email right away you see the title, maybe some text but you should tap on it to see details.

Usually, on smartphones, there is no place for both, master and detail layouts and these are separate activities. But tablets are much much bigger than smartphones so it's more convenient to have everything on one screen. Like in this picture.

So in this case, fragments perform like both: part of an activity and reusable parts. You can use detail fragment in smartphone and tablet layouts, but in smartphone layout, it will have

Also, fragments can be used without layout as a separate thread of your activity, but when do so remember that the fragment's lifecycle depends on the activity's lifecycle.

Wrap up

Fragments are powerful, as said with great power comes great responsibility and, in software development, complexity. But you don't need to understand all this complex underlying basements of fragment to take advantage of them.

For me, fragments were something that only sophisticates the structure of an application. But it was because the lack of understanding. Now I understand what is fragment and think that it's elegant solution to the problem that arose with the growth of Android system. 

And I hope that I tackled this lack of understanding for you. If I didn't and you still have questions fell free to ask in comment section below!

That's all for today, see you in the next one!

P.S. If you want to bee up to date about posts on this blog follow me on Twitter.