DEV Community: Akash Eldo

How I Transitioned From an Intern to a Full-Time Software Developer

Akash Eldo — Mon, 02 Aug 2021 13:40:47 +0000

At this time last year, I was sitting in the corner of my bedroom with the lights off, trying not to wake up my little brother during my dev team’s standup. I was the lone intern in a (virtual) room of three senior software developers. Now, I’m a full-time software developer standing in a room (an actual room this time!) of senior developers, and my brother’s sleeping peacefully back home.

Getting that full-time offer didn’t just happen. It required me to step outside my comfort zone and really challenge myself as a developer. Now that I’ve been working as a full-time software developer for a few months, I thought I’d share what I learned in the transition and what I did that got me promoted from intern to full-fledged developer.

Ask Questions, No Matter How Stupid

Starting an internship can be pretty daunting. You’re dropped into a group of very talented people and expected to contribute to a code base you know next to nothing about. You might feel intimidated and even a little dumb. I remember feeling so overwhelmed during the first week of my internship that I was sure they had made a mistake in hiring me.

In a situation like this, you might hold back on asking a question for fear of feeling stupid. However, that’s the last thing you want to do. Asking questions is how you learn. It’s how all those talented people on your team became so talented, and by not asking a question, all you’re doing is delaying your knowledge gain.

You’re a Code Owner, Not a Contributor

I should probably explain the difference between a code owner and a code contributor first. Simply put, a contributor is someone who adds value to the code base. This usually takes the form of pull requests that add a new feature or fix a bug. An owner, on the other hand, is tasked with keeping the code base healthy by preventing code smells and bugs from being introduced. A good code owner should also help others contribute to the code base and follow best practices. Of course, an owner also contributes new code in addition to these responsibilities.

As an intern, it was easy for me to fall into the contributor mindset — especially in the beginning when it felt like I was drowning in a sea of code without a life jacket. While the contributor mindset might be OK at first, it’s important to start thinking like an owner if you want to grow as a software developer. Read and re-read your team’s contributing guide or suggest they make one if it doesn’t exist. Take a look at the comments that senior developers leave on other people’s pull requests. Remember, you’re not just contributing code to a repo. You own the repo. It’s your responsibility to maintain code quality, prevent bugs, and keep the code base healthy. Don’t be afraid to make suggestions on PRs if you see some area for improvement or block them if you feel merging the PR will negatively impact the code base.

Make a Lasting Contribution

Think about ways you can improve the current situation. This could be improving the developer workflow, introducing new technologies, or anything else that will benefit your team even after your internship is over.

For example, a few months into my internship, I found that our team’s deploy process was lacking. There were too many steps and there was too much room for human error. I figured a lot of the manual steps could be automated, so I created a Slack bot to handle the more tedious parts of our deploys. My fellow developers were all pretty excited when I demoed it to the team, and I was excited too because it gave me the opportunity to showcase my abilities. It’s been months since I built that bot, but it continues to provide value, as we still use it for our deploys.

If you’re looking for a way to make a lasting contribution, a great option is to improve your team’s onboarding docs because they could always be better. Document what your onboarding process was like and any difficulties you had, and then share this information with your team. The next intern or new hire will almost certainly thank you for it.

Make Yourself Heard

You might be an intern, but that doesn’t mean you don’t have a voice. Use it.

Your main motivation behind doing an internship might be to learn new skills (or make that sweet 💸), but it’s equally important to share your thoughts and opinions with the rest of the team. For me, it was pretty intimidating to do this at first. I thought my feedback wouldn’t be helpful to a group of senior developers with more experience than me. Over time, however, I learned that they valued my input and I now frequently weigh in during discussions.

Everyone has something valuable to contribute to the team, including you. One of the reasons companies hire interns in the first place is to cultivate new ideas. If you have some ideas that you think could be of benefit to others, don’t hesitate to voice them.

Don’t Forget To Spend Time on You

Just because your team uses Scrum doesn’t mean you can only do what’s on the board. A lot of the work senior developers do never shows up in the sprint. Take some time to learn a new technology, improve your understanding of the code base, or whatever you think will improve your effectiveness as a software developer.

Perhaps an example would be helpful. I was fortunate that my team already had a process for this called 10% time, where we could spend 10% of our time doing whatever we wanted. For me, this meant spending my Fridays learning new tools and frameworks. I might be a React developer, but on Fridays, I was learning mobile frameworks, building Slack bots, and messing around with new languages. Hell, I even spent one day learning how to code on the blockchain. While none of these things were directly related to my work, they helped build cross-field connections. This kind of cross-training can help you come up with innovative solutions that you wouldn’t have thought of otherwise. I can honestly say that the time I spent hacking away on Fridays has made me a better developer.

Closing Thoughts

Like the best internships, mine was filled with opportunities to learn new things and grow as a developer. I accomplished a lot, made plenty of mistakes, and most importantly, learned more than I could’ve ever anticipated thanks to an awesome team, manager, and group of coworkers. It’s because of their invaluable lessons that I’m the software developer I am today, and hopefully I was able to communicate at least a few of those lessons to you.

Thanks for reading. Now go out there and make the most of your internship!

How to Handle Advanced Requests on Android with GraphQL &RxJava

Akash Eldo — Mon, 02 Aug 2021 13:40:27 +0000

Introduction

Welcome to part two of my series on GraphQL, Android, and RxJava! If you haven’t already, be sure to check out my part one article where I go over the basics of using RxJava with GraphQL on Android. In this article, we’ll go over some more advanced topics, such as handling parallel and dependent requests. Let’s get to it!

Setup

We’re going to continue using the Android app we setup in my last article for the examples here. We’ll continue using the SpaceX GraphQL API for this article as well. Particularly, the rocket and launchpads queries. Let’s start off by writing GraphQL queries for these endpoints.

First, the rocket query:

query RocketQuery($id: ID!) {
    rocket(id: $id) {
        id
        name
        description
        first_flight
        cost_per_launch
    }
}

This should be pretty familiar if you’ve read my previous article, the only difference is the $id parameter we added. That’s used to specify which rocket we want to fetch, and we’ll use it later in our Java code.

Now the launchpads query:

query LaunchPadsQuery {
    launchpads {
        vehicles_launched {
            id
        }
        name
    }
}

Nothing special here, just some good ole' GraphQL.

With our GraphQL queries written, all that’s left is to make methods for them in our Server class.

First, rocket:

public static Observable<Response<RocketQuery.Data>> fetchRocket(String id) {
    ApolloQueryCall<RocketQuery.Data> call = getApolloClient()
            .query(new RocketQuery(id));

    return Rx3Apollo.from(call)
            .subscribeOn(Schedulers.io())
            .observeOn(AndroidSchedulers.mainThread())
            .filter((dataResponse -> dataResponse.getData() != null));
}

Again, this is pretty similar to our previous setup. However, notice the id argument in the method definition. We use that to set the $id argument we defined earlier in our GraphQL query file.

Next, launchpads:

public static Observable<Response<LaunchPadsQuery.Data>> fetchLaunchPads() {
    ApolloQueryCall<LaunchPadsQuery.Data> call = getApolloClient()
            .query(new LaunchPadsQuery());

    return Rx3Apollo.from(call)
            .subscribeOn(Schedulers.io())
            .observeOn(AndroidSchedulers.mainThread())
            .filter((dataResponse -> dataResponse.getData() != null));
}

This one’s just like our other server methods. We create an ApolloQueryCall, use that to create a query object, and then convert it into an Observable so we can work our Rx magic.

That’s it for our Server class. You can reference the repo version to make sure yours is setup correctly. With that done, we should be all set to dive into some advanced request scenarios.

Scenario 1: Parallel Requests

Our first scenario is a very common one, parallel requests. Often times, we need to make multiple requests to get the data we need. In our case, we’re going to make a page that lists information about a rocket along with a list of launchpads it’s used. Since these requests are independent of each other, we should do them in parallel. The best way to handle this scenario is to do both requests in the beginning, show a loading indicator while we wait for a response, and then show the page once both requests are done. Using a combination of GraphQL and RxJava, doing this on Android becomes really easy.

First, let’s create an Observable of our rocket query:

// Fetch Rockets
ObservableSource<Response<RocketQuery.Data>> observable = Server.fetchRocket(id);

Notice that we save this observable instead of immediately acting on it. That’s because we’re going to combine it with the our second request so we can act on the combined result. Don’t worry though, the request is made as soon as we call our fetchRocket method.

We then do our launchpads query and combine the two requests with zipWith:


Server.fetchLaunchPads()
  .zipWith(observable, (BiFunction<Response<LaunchPadsQuery.Data>, Response<RocketQuery.Data> , Pair<RocketQuery.Rocket, List<String>>>)
    (launchPadsResponse, rocketResponse) - > {
      List<LaunchPadsQuery.Launchpad> launchpads = launchPadsResponse.getData().launchpads();
      RocketQuery.Rocket rocket = rocketResponse.getData().rocket();

      String rocketId = rocket.id();
      ArrayList<String> filteredPads = new ArrayList<>();

      for (LaunchPadsQuery.Launchpad launchpad: launchpads) {
        for (LaunchPadsQuery.Vehicles_launched vehicle: launchpad.vehicles_launched()) {
          if (vehicle.id().equals(rocketId)) {
            filteredPads.add(launchpad.name());
          }
        }
      }

      return new Pair<>(rocket, filteredPads);
    })

Here, we do our launchpads query and zip it with the observable from our previous query. The second argument is a function that describes how to combine the two request responses. In our case, we’ll first sort through the launchpads and only save the ones that were used by the rocket we wanna show. Then, we combine the data from the two requests into a Pair.

In this step of our pipeline, we’ve combined the responses from our requests into a new object. Our zipWith function won’t get called until both responses resolve, so all we have to worry about now is handling the combined result. At this point, it’s just like handling a regular request. We can just use subscribeWith:

 // Once both requests have completed, handle the combined result
.subscribeWith(new DisposableObserver<Pair<RocketQuery.Rocket, List<String>>>() {
  @Override
  public void onNext(@NonNull Pair<RocketQuery.Rocket, List<String>> pair) {
    RocketQuery.Rocket rocket = pair.first;
    List<String> launchpads = pair.second;

    nameView.setText(rocket.name());
    flightView.setText(String.format("First flight was on %s", rocket.first_flight()));
    costView.setText(String.format("Cost per launch: $%s", rocket.cost_per_launch()));
    descView.setText(rocket.description());

    LaunchPadsAdapter adapter = new LaunchPadsAdapter(launchpads);
    recyclerView.setAdapter(adapter);
  }

  @Override
  public void onError(@NonNull Throwable e) {

  }

  @Override
  public void onComplete() {
    // Both requests have finished, so hide loading bar
    progressBar.setVisibility(View.GONE);
  }
});

Notice that the class definition uses Pair<RocketQuery.Rocket,List<String>> , this is the return type from our zipWith function and the types need to match for our pipeline to work. In onNext we use the Pair we created in zipWith to fill in our views with the response data. We then turn off the loading state in onComplete . For simplicity sake, I didn’t handle error state, but this can be easily done in the onError event handler. With this step our pipeline should be complete, you can double check your pipeline by checking out this code file.

Using Apollo Android and RxJava, we were able to handle parallel requests with ease. This could easily be scaled up to handle more parallel requests, just add another zipWith for each new request and update your subscribeWith accordingly.

Scenario 2: Dependent Requests

In our last scenario, the two requests were independent of each other, but what if they weren’t? Sometimes we need to make multiple requests, but the second request requires data from the first request. In this scenario, we can’t run the requests in parallel, instead we have to run them sequentially.

This time we’re still going to display information about a rocket, but we only have the rocket’s name, not its id. That means that we first have to do a request to the rockets endpoint(see my last article), get the id from the response, and then call rocket using that id. Handling this scenario on Android is a breeze with GraphQL and RxJava.

First, we’re going to query the rockets endpoint, and then use concatMap to handle the result:

// Fetch rockets and use the response to fetch the rocket we want
Server.fetchRockets()
  .concatMap(dataResponse -> {
    assert dataResponse.getData() != null;

    List<RocketsQuery.Rocket> rocketList = dataResponse.getData().rockets();
    for (RocketsQuery.Rocket rocket : rocketList) {
      if (rocket.name().equals(ROCKET_NAME)) {
        return Server.fetchRocket(rocket.id());
      }
    }

    return null;
  })

Here, we use the fetchRockets method we created in my previous article, but handle it with concatMap. With concatMap, we can handle the response and then pass information down to the next step in our RxJava pipeline. First, we sort through the list to find the rocket we’re looking for. Once we find the right rocket, we use its id to make a request to our rocket endpoint.

Notice that we’re returning the Observable created by fetchRocket, that’s because we’ll use it in our next pipeline step, shown below:

// Once response is received, handle result
.subscribeWith(new DisposableObserver<Response<RocketQuery.Data>>() {
  @Override
  public void onNext(@NonNull Response<RocketQuery.Data> dataResponse) {
    assert dataResponse.getData() != null;

    RocketQuery.Rocket rocket = dataResponse.getData().rocket();

    nameView.setText(rocket.name());
    flightView.setText(String.format("First flight was on %s", rocket.first_flight()));
    costView.setText(String.format("Cost per launch: $%s", rocket.cost_per_launch()));
    descView.setText(rocket.description());
  }

  @Override
  public void onError(@NonNull Throwable e) {

}

  @Override
  public void onComplete() {
    // Requests have finished, so hide loading bar
    progressBar.setVisibility(View.GONE);
  }
});

This code snippet should be all too familiar by now. Just like our other examples, we use subscribeWith to handle the response. You can check the completed pipeline here. With RxJava, we can handle complex GraphQL requests on Android with ease.

Conclusion

By taking advantage of the Apollo Android and RxJava libraries, we can handle some pretty complex request scenarios without difficulty. Be sure to check out this article’s companion repo for a more in depth look at the code. In my next article, I’ll talk about how to write Android instrumented tests for the GraphQL requests we’ve made.

As always, thanks for reading and give me a ❤️ if you enjoyed this article! I love seeing how my readers use what they’ve learned, so please share how you’re using these strategies in your own Android apps in the comments below.

Apollo and RxJava: Android GraphQL the Right Way

Akash Eldo — Sun, 25 Jul 2021 16:01:57 +0000

Introduction

Since its inception, GraphQL has grown to become a very popular framework for building backend APIs. However, I still don’t see it used that often on Android. I think the reason is that there aren’t many resources on using GraphQL on Android, and what does exist is outdated or doesn’t take advantage of new technologies. In this article, I want to present a “best practices” approach to setting up a GraphQL client on Android. We’ll make a simple Android app that uses the SpaceX GraphQL API to display a list of rockets. By taking advantage of Apollo Android and RxJava, we’ll do GraphQL on Android the right way.

Setup

Before we get started, we have to get all our dependencies ready. First, paste the following into your project level build.gradle:

buildscript {
    repositories {
      ...
    }
    dependencies {
        classpath "com.apollographql.apollo:apollo-gradle-plugin:2.4.1"
        ...
   }
}

allprojects {
    repositories {
        ...
        // RxJava repo
        maven { url "https://oss.jfrog.org/libs-snapshot" }
    }
}

This will add the apollo plugin and a maven repo we need tor RxJava. Next, add these dependencies and plugin to your app level build.gradle:

dependencies {
    ...
    // Apollo
    implementation "com.apollographql.apollo:apollo-runtime:2.4.1"
    implementation "com.apollographql.apollo:apollo-rx3-support:2.4.1"

    // RxJava
    implementation 'io.reactivex.rxjava3:rxandroid:3.0.0'
    implementation 'io.reactivex.rxjava3:rxjava:3.0.0'
}

apply plugin: "com.apollographql.apollo"

Here we add two Apollo related dependencies, one for the library itself and another for Rx support. We also add RxAndroid, an Android port of RxJava, and RxJava itself. We add RxJava explicitly because RxAndroid isn’t updated as often, so defining it manually lets us stay up to date with bug fixes. Don’t forget to add apply plugin: “com.apollographql.apollo” at the end of your gradle file, otherwise you’ll run into compiler issues later.

Writing GraphQL Queries

Create the directory src/main/graphql/com/example, but replace example with your own package name. After that, run the following command to fetch a GraphQL schema:

./gradlew downloadApolloSchema 
--endpoint="https://api.spacex.land/graphql/" 
--schema="src/main/graphql/com/example/schema.json"

Replace ./gradlew with gradlew.bat if you're on Windows.

This command will run an introspection on the SpaceX API and create a schema.json for us. Next we'll write our GraphQL query, which we’ll use to fetch a list of rockets. Create a file called rockets.graphql in the same directory as schema.json and paste the following:

query RocketsQuery {
    rockets {
        id
        name
        description
    }
}

This is a very basic GraphQL query that targets the rockets endpoint and fetches a list of rockets, with each entry containing the rocket's id, name, and description. The API actually provides a lot more information than this, but we only need these three data points. Since GraphQL lets us fetch only what we need, we don't have to slow down our requests with unnecessary information.‌ If you want to learn more about GraphQL in particular, this article is great place to start.

Now that we wrote our query, build the project. Apollo will read the graphql files we created and automatically generate classes that we’ll use to make queries against the server. If you set your project view to Android, you should see the following:

Making a GraphQL Request

Now that we have all our GraphQL stuff setup, we can start writing some Java code. It’s good practice to keep all our server related code in one class, which we’ll call Server. Here's the shell of that class:

class Server {
    private static ApolloClient apolloClient;

    private static ApolloClient getApolloClient() {
        if (apolloClient == null) {
            //Build the Apollo Client
            String serverUrl = "https://api.spacex.land/graphql/";
            OkHttpClient okHttpClient = new OkHttpClient.Builder().build();
            apolloClient = ApolloClient.builder()
                    .serverUrl(serverUrl)
                    .okHttpClient(okHttpClient)
                    .build();
        }
        return apolloClient;
    }
}

This class uses the singleton pattern to create an ApolloClient instance. We'll use this helper method in our queries so we don't have to create a client with every query.

Next let’s make a method for our rockets query:

public static Observable<Response<RocketsQuery.Data>> fetchRockets() {
    ApolloQueryCall<RocketsQuery.Data> call = getApolloClient()
            .query(new RocketsQuery());

    return Rx3Apollo.from(call)
            .subscribeOn(Schedulers.io())
            .observeOn(AndroidSchedulers.mainThread())
            .filter((dataResponse -> dataResponse.getData() != null));
}

This code is pretty dense, so let’s go through it slowly. First we create an ApolloQueryCall object with RocketsQuery, the class that was generated from the GraphQL file we wrote earlier. This object defines the GraphQL query we want to make against the SpaceX API.‌

We then use the helper class Rx3Apollo to convert the call into an RxJava object, which lets us do all our Rx magic on it. subscribeOn specifies that we want this request to be run on a background thread. With observeOn, we say that we want to handle the response on the main thread because we'll update the UI using the response. Finally, we add a filter to toss out null responses to prevent any null pointer exceptions.

This method returns an Observable that we can then use in our Activity code to handle loading and error states and update the UI when we get a response.

Now we’ll use the fetchRockets method we created to populate a list:

 // Show loading
ProgressBar progressBar = findViewById(R.id.main_progressBar);
progressBar.setVisibility(View.VISIBLE);

Server.fetchRockets().subscribeWith(new DisposableObserver<Response<RocketsQuery.Data>>() {
    @Override
    public void onNext(@NonNull Response<RocketsQuery.Data> dataResponse) {
        if (dataResponse.getData() != null) {
            RocketsAdapter adapter = new RocketsAdapter(dataResponse.getData().rockets(),MainActivity.this);
            recyclerView.setAdapter(adapter);
        }
    }

    @Override
    public void onError(@NonNull Throwable e) {

    }

    @Override
    public void onComplete() {
         // Query's done, so hide loading
         progressBar.setVisibility(View.GONE);
    }
});

In this code snippet, we first show the loading indicator, because we’re about to fetch our data. We then use our Server class to do a rockets query and create a DisposableObserver to handle the result. This is one of the benefits of using RxJava with Apollo Android. DisposableObserver has three methods we can use to handle the result: onNext, onError, and onComplete. onNext is called when a valid response is received, and onError is called if an error occurs. Regardless of the outcome, onComplete is called once the request is completed. This lets us define our loading, error, and data states separately, which greatly simplifies our code. In this snippet, we attach the rockets to a custom adapter(code here) and then hide the loading indicator. Notice that the loading part is handled in onComplete, because we want to hide it even if an error occurs.

Conclusion

In this article we went through the right way to use GraphQL on Android by taking advantage of the Apollo Android and RxJava libraries. However, the example we went through is one the simplest request scenarios. For more advanced scenarios like parallel and dependent requests, check out this article’s companion repo. You can also read my next article, where we’ll take a closer look at some of the advanced examples in this repo.

As always, thanks for reading and let me know in the comments if this helped you out!