Why planning is so important?

Over the years Mood Up Labs team worked with many clients so we truly understand that every client is unique. Sometimes they have clear vision of the product, sometimes they don’t. Some are technical, others not. This uniqness might be challenging, but will not be a problem because we believe planning is important and can be very strong ally on our side. Continue reading “Why planning is so important?”

How to code (pt.1): RxJava + Retrofit

RxJava is an implementation of ReactiveX library for observable streams of data or event by using combination of the Observer pattern (read more). You will find more info on Retrofit (here).

I would like to show you how to call RestFull API enpoints using RxJava and Retfrofit 2.0. We are going to show you how to switch Retrofit’s Services method to RxJava Observable as well.

RxJava and Retrofit in practice

Before we get started, let’s add needed dependency to your gradle:

compile ‘io.reactivex:rxandroid:1.2.1’
compile ‘io.reactivex:rxjava:1.1.6’

RxAndroid included classes to RxJava that makes writing reactive components in Android applications easy.

After that add retrfoit dependencies:

compile ‘com.squareup.retrofit2:retrofit:2.1.0’

If you are using GSON please add converter for retrofit. Converter is needed to deserialize HTTP bodies into your custom class model. If you are not using it Retforit deserilizes HTTP bodies into OkHttp’s ResponseBody.

compile ‘com.squareup.retrofit2:converter-gson:2.0.0-beta4’

Here is a list of official converter modules provided by Square:

  • Gson: com.squareup.retrofit:converter-gson
  • Jackson: com.squareup.retrofit:converter-jackson
  • Moshi: com.squareup.retrofit:converter-moshi
  • Protobuf: com.squareup.retrofit:converter-protobuf
  • Wire: com.squareup.retrofit:converter-wire
  • Simple XML: com.squareup.retrofit:converter-simplexml

You can create custom converter yourselft by using Converter.Factory interface.
Next dependecy will help us return Observable object from Services:

compile ‘com.squareup.retrofit2:adapter-rxjava:2.0.0-beta4’

Thanks to that we have defined Service.

public interface APIService {
@POST(“list”)
Call loadCar();
}

In order to switch RxJava observable only one change is needed:

public interface APIService {
@POST(“list”)
Observable<Car> loadCar();
}

 

Now let’s modify your Retrofit Builder and add CallAdapter and ConverterFacvtory:

public Retrofit provideRetrofit(){
return new Retrofit.Builder()
.baseUrl(“http://api.geo.org/”)
.addCallAdapterFactory(RxJavaCallAdapterFactory.create())
.addConverterFactory(GsonConverterFactory.create(new Gson()))
.build();
}

Right, now let’s move to some examples, shall we?

Example 1

We can start and call first Restfull API method with RxJava. Let’s begin with creating simple example that will provide object car.
We are about to do some simple activty where we have included APIService object already and are ready to call loadCar using RxJava.

public class Activity extends AppCompactActivity {
APIService apiService;
@Override
protected void onCreate(Bundle savedInstanceState) {
apiService.loadCar()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe();
}
}

Now we want to call asynchronous task. In order to do that, we have to use subscribeOn(Schedulers.io) to execute the observable on a new thread.

If we want also to get result in main UI thread, we have to use observeOn(AndroidSchedulers.mainThread()) which means that result emits through on the main UI thread.
subscribe() method is kind of trigger. If you don’t call it the request never executes.
If you take a look closer to subscribe method you will notice that there are more overloaded methods. I prefer to use subscribe method and handle errors. I will explain this below.
Let’ modify our request and add to subscribe method parameter Subscriber.
It should look like that:

public class Activity extends AppCompactActivity {
APIService apiService;
@Override
protected void onCreate(Bundle savedInstanceState) {
apiService.loadCar()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Subscriber<Car>() {
@Override
public void onCompleted() {
}
@Override
public void onError(Throwable e) {
}
@Override
public void onNext(Car car) {

}
});
}
}

There are couple of important things. Let’s start from onNext method. That method provides you with response for loadCar request, in our example that is object Car and immediately method onComplited executes.

onNext method calls everytime unless you have kind of error, for example JSONException, IOException etc. In this case method onError called instead of onNext() and onComplited doesn’t execute.
There are couple of cases to execute onComplited and onNext instead of onError when you have error. But that is subject for next tutorial.

Example 2

Let’s see what happens when we use subscribe method without parameters. We are going to resource Observable and find couple of overloaded subscribe methods. Let’s check subscribe() method:

public final Subscription subscribe() {
Action1<T> onNext = Actions.empty();
Action1<Throwable> onError = InternalObservableUtils.ERROR_NOT_IMPLEMENTED;
Action0 onCompleted = Actions.empty();
return subscribe(new ActionSubscriber<T>(onNext, onError, onCompleted));
}

On the surface everything looks pretty nice. Above we have three Action object for each action in our request. But what is weird is static value:

InternalObservableUtils.ERROR_NOT_IMPLEMENTED.

Take a look closer, In InternalObservableUtils class found:

public static final Action1<Throwable> ERROR_NOT_IMPLEMENTED = new ErrorNotImplementedAction();

Implementation class ErrorNotImplementedAction with method call will throw exception:`OnErrorNotImplementedException`;

public void call(Throwable t) {
throw new OnErrorNotImplementedException(t);
}

Final note

So if we subscribe to observable using subsribe() (method without parameter) it will work fine. But as I wrote above, it is possible to get error which is handled by onError method. In this case you will have crash because of throwing exception OnErrorNotImplementedException.
We should handle error in our side either by implementing onError action or providing Subscribe object.

Hope you enjoyed this coding tutorial, you can expect more in the future.

What are the costs of making a mobile app?

When thinking about developing your own application, one question will surely occure: ‘how much will it cost to build a mobile app?’. It’s only natural and we’ve received this question a lot from our prospective clients here at Mood Up Labs, so we’ve decided it’s high time to put some light on costs of making an app.

Costs of making an app

As you propably are aware of, costs can vary. That’s why it is simply impossible and more importantly not wise to just put the price tag on an app. Instead of that here are some factors that have direct influence on costs of an app:

  1. Your priorities
  2. In-house or Offshore
  3. Devices and platforms
  4. Design
  5. Features
  6. Maintenance
  7. Testing
  8. Marketing

Let’s explain all of the above in a few more sentences.

1. Your priorities

First of all you need to be honest with yourself, a golden rule to follow in app development (but not only) lies in the picture below.

mooduplabs-good-fast-cheap-triangle

You can choose only two attributes: high quality – cheap – fast.

If somebody tells you that your app can be made day before yesterday, it will fulfill your needs and you will still have money in your pocket is full of… let’s just say he might be talented seller but definitely not honest one.

When something sounds too good to be true it usually is. That’s why your priorities are crucial. You know best how much time, money you can spend and what results are you expecting.

2. In-house or Offshore development

Another factor to consider is whether you can delegate a team of developers to build an app inside your firm or you want to hire somebody to do it.

Offshoring is well known practice to cut costs and it’s derivative – nearshoring is what we strongly believe here at Mood Up Labs and from our experience is highly effective.

With travel distances within Europe and ways to communicate avaible, nearshoring is almost as effective as in-house development and far more cheaper.

3. Devices and Android or/and iOS platforms

With the amount of devices out there, you need to be specific who you want to reach. And here are some things about choosing the right platform to consider.

4. App design

The goal is to make your app beautiful. User Interface is one of the most expensive parts of your app, if done well. It’s because outstanding UI cannot be just beautiful, it has to be useful. After all you build your app for users, so User Experience plays huge role in it’s success.

5. Features

There is not such an app that can do everything, yet many have tried and failed. More features won’t save your app. The features you want to add to your app should be clear right from the start so that you can focus on them. After a while you will be able to decide which are the most important or which ones should be added.

6. Maintenance

App isn’t just fnished after realease, it’s a process. At first you will be able to make some improvements after user’s feedback. After that you need to remember that each new version of the app or Operating System will require bug fixing and updates so that your app will run smoothly.

7. Testing an app is very important

Whole purpose of testing is for you (your users) to be satisfied with how the app works. Costs will rise with the amount of testing, but testing procedures play major role in app success.

8. Marketing

Finally, your app is ready. Now you need to decide how to monetize it. There are several ways to reach potential users and that should also be considered as cost of building an app.

Conclusion

Remember that estimating costs of building an app is far more complex than simply v1.0 budget. If you are really giving yourself a chance, you need to see beyond that. Take factors described above under consideration and it will help get you started. If you hear from someone about the price without asking detailed questions, be sure you’re talking to newbies and getting into trouble.

Should you have any questions, Mood Up Team of mobile experts will be happy to help.

Why code review is so important?

It’s not in human nature to be able to check your own work unbiased. Editors are catching mistakes for authors and similar help is needed when it comes to authors of software – developers. That’s why code review is so important.

“If debugging is the process of removing software bugs, then programming must be the process of putting them in.” – Edsger Dijkstra (Dutch computer scientist, winner of the 1972 Turing Award)

Although purpose for code reviews varies a lot depending on environment, there are 3 main goals that every code reviews share:

  • Teaching and knowledge sharing
  • Ensuring coding standards
  • Defect-free software

Other very common goals are security, scalability, maintainability and complete unit tests.

How does it work?

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian W. Kernighan (Canadian computer scientist, co-author of “C programming language”)

That’s why code reviews are so important.

Code review is the examination of code performed by developer (or developers) who didn’t write it in order to provide feedback. Feedback could be both negative and positive.

Reviewers are often working outside the project to maximize objectivity, but also to ensure that code written is readable and clear to everyone, not only for those deeply involved in the project. Typically reviewers are following checklists to find common mistakes and validate the code so that it can meet company’s coding standards.

Except for demos or experiments, it is crucial that code reviews take place during all stages of development. It is very important to perform such reviews even in final stages (when everyone is more focused on meeting deadlines), this is company’s and developer’s insurance for keeping company’s coding standards and can greatly reduce number of bugs. This means successful launch and less money spent on QA.

Code reviews help save your money

Finding bugs during development will be cheaper than finding them in QA, the sooner bug is found, the cheaper it is to fix it.

It is very hard for developer to find his own mistake, especially when a lot of features are added to the app (not always good a idea) but it can be detected more easily by someone else (fresh look effect). That’s why reviewers are looking for common mistakes and also focusing on finding those that are typically harder to find such as:

  • thread synchronization
  • error conditions
  • accounting for reference-counting
  • resource leaks
  • security problems

Maintainability

Software is not easy to maintain and it generates costs. It is especially true when one developer finishes the project and another one becomes responsible. It can also be difficult for a developer to know his way around the code he wrote 9 months ago.

Developing software doesn’t end simply with launching, it’s constant process so it’s best to ensure that code is clear for everyone and it can be modified when needed.

Code reviews help keeping code organized and adding adequate comments which can be priceless in the future – a person uninvolved, new to the project, will be able to read portion of code and understand it.

code-review

Learning and sharing

Every project is different and there are some unwritten rules. Tacit knowledge must be offered to people that are new arrivals to the project. It is impossible (or nearly impossible) to write this down, this kind of knowledge is usually acquired by making mistakes. Code reviews are the way of transferring knowledge between experienced developers and rookies.

Conclusion

Code review helps to launch successful product and save money. It is also great way to transfer knowledge. Senior developers can offer advice and their wisdom to juniors, and juniors help them by finding mistakes that seniors couldn’t see on their own, because they were so deep in the project. Code reviewing should be part of every stage of development.