Quick Summary

Almost everyone recognizes the value of REST architecture implementations on the Internet nowadays. But if you use it on a daily basis, you know that it lacks that “extra mile” that would make your projects work even better.

This post brings a quick (non-exhaustive) glance of two approaches (Falcor & GraphQL) that can leverage your game acessing your data exposed through an API. Dependening on your use case, any one of them can be a perfect fit for your next project.

Introduction

There are two new kids on the block. Well… they’re not really new, but they’ve only become “hype” lately. I’m talking about Falcor and GraphQL.

If you have the luck of not being stuck in a SOAP-like world, you’re probably familiar working with REST. And, in that case, this post might interest you!

Quick Summary

This post is a personal opinion on how Golang is an awesome language. It seems to address several common issues / criticisms of top programming languages and, to me, it seems to have integrated the best features of each of them.

Introduction

One of the features that I like the most in Golang its how it was designed considering the concurrency world that we live in. CPUs now have lots of cores, with lots of threads, but few are the languages that really take advantage of these features (Most of them were created before these kind of CPUs reached the mass market).

With this post, I’m trying to show the simplicity of out-of-the-box Goroutines logic versus the not so friendly JavaScript Event Loop system that is prone to block if you aren’t careful…

Every Android developer knows that you should not mess with the “finish” system of the activity lifecycle. You should just call finish() and let the OS take care of the rest for itself. However, every once in a while you get a request like “I don’t want to know how, but I want everything to just stop”. So, you drink a coup of courage, ignore all those guidelines that you learned and just look at the old java methods to shutdown an application – System.exit(0) (More info on http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#exit(int)).

The app actually shutdown BUT as I strangely discovered, it didn’t stay dead (lol). The app started again… After question all those java years in college, I found that the activity that was calling the method was NOT the only activity on the stack. It was on top, but it was not the only one.. I went from Activity A to Activity B without finishing it, so both were on the stack.

I’ve created a sample application that demonstrates this situation. There are two activities – ActivityOne and ActivityTwo. The first one calls the second and the second shows a dialog. When the user presses the button, the app closes and relaunches.

Consideration Notes:

Check for the “Logging…” tag on Logcat to see the activity creation. If you just call the exit method without the dialog, the app will enter an infinite loop. If you want to test the correct use case, remove the // from the finish() method on ActivityOne So, boys and girls, this is an example of why you should not mess with the activity lifecycle. It exists, may not be perfect, but it works. Call the methods and let the OS take care of the rest.

The sample application can be downloaded from: https://github.com/ivocosme/forcefinish

I’ve been using Volley – Google’s HTTP library – for a while now . Working on a daily basis with JSON, I was missing a fantastic feature that – another great library – Retrofit has. The capability of parsing the JSON response directly to a java object. HTTP request goes in, Java parsed object comes out. As simples as it sounds.

So, I made two custom requests that try to achieve the retrofit feature using Volley and Gson “A Java library to convert JSON to Java objects and vice–versa”. For simplicity’s sake of the example application, both gson lib and volley lib were already included in the libs folder. One can get them on https://github.com/google/gson and https://android.googlesource.com/platform/frameworks/volley.

The application is pretty simple. One activity with two fragments in split screen. One of the fragments calls for a JSONObject, and the other one calls for a JSONArray. When the request is correctly parsed, a toString() puts the content of the parsed class inside a TextView.

The sample application can be found in https://github.com/ivocosme/gsonenhancingvolley

Leaving AsyncTasks and other “lower level thread like” approaches was one of the best decisions that I could have taken as a developer. Code got cleaner, reduced complexity, no more “if != null”, among other things.

So, this blog is called the “The Strange Wonders of this developer’s Cosmos”. A little bit lame you say?! Maybe.. But truly, the Programming World is filled with strange(some times even insane!!) behaviors that begin outstanding quests just to figure out what the problem is.

This blog won’t be filled with “everyday tutorials”, those you can find with just a couple of clicks on Google from other developers that did a great job.

This blog will try to show those strange situations that, as a Mobile Developer, I’ve found in my daily work. Situations that took me a while to figure out the solutions and that sometimes left me WTF (Well, That’s Fantastic :P). Although the solution may not the best sometimes, it was the one that I used, and that I expect that will help other developers.

See you soon!