Develop Reference

Get instance initialized with the new App Startup API

I saw this new API in the Android dev guide,and I wanted to try it out since it looked like a really nice way to initialize components. But looking over the articles and the examples, it makes no sense to me how am I suppose to use this API. I get the first example, in order to use the WorkManager you would first need to call its initialize method, so this new API can handle that for you. But the create method of the Initializer returns an instance of whatever you are trying to initialize. This means that that instance is somewhere available for you to grab. But there is no explanation on how to retrieve that instance later in your code to use it.
So my question is if there was anyone who got around to test this new API, if you could give me an example of how you use the instance that the App Startup API initialized for you. Thanks in advance!

As of now, the library leaves this up to the developer. The point is mainly to add a unified way for libraries to automatically initialize themselves without boilerplate code.
If you are the author of a library using this approach, you are still obligated to provide a way of obtaining these objects.
Edit
I went with the assumption that AppInitializer.getInstance(context).initializeComponent(...) is only used for creating new instances.
However, after having a look at the source code, it turns out instances are cached and immediately returned here if they have been inititialized earlier.
But on the down side, you will need to pass a Context object.
I would also advice to only call it from the main thread, since there is no singleton-style locking in place

Best way to structure code when using asynchronous methods (e.g. auth retrieval)?

I'm working on an Andriod app. I was examining my work from a high-level perspective, and there seemed to be a very high branching factor of potential [auth-based] crashes that could occur stemming from the fact that authorization is asynchronous using Firebase.
My attempt at solving this (simplistically put) was to put pretty much all my code into the callback of the Firebase auth result (but then I had issues with race conditions related to the Google API Client [I use location] connection callback, along with other small issues).
After doing what I could to make it as watertight as possible, I'm a little dissatisfied with the way my code is laid out in my project. E.g. In my MainActivity's onCreate method, I wish I could just lay everything out linearly to be executed one after the other (but I am aware of the UX drawbacks of not having things being done asynchronously).
Given this, I'm wondering if anyone knows of any better ways to do this or best practices when it comes to this sort of thing. Is the best solution just to put all the code into the callbacks of methods on which it depends? Or is there something I'm missing?
Thanks

yes there is , your structure is asynchronous in nature.To avoid race conditions every condition must trigger accordingly. The glorious concept of promises perfectly does this job for you.Promises return an object…which promises to do some work.This object has separate callbacks…for success and failures.
This let's us work with asynchronous code…in a much more synchronous way.…A really nice feature is that promises…can be combined into dependency chains. Which simply means execute this, if that happens or fail that. Please consider using rxjava or rather rxandroid which embodies the notion of observable.Observables can be used to model events, asynchronous requests, and animations.
Observables can also be transformed, combined, and consumed.
is the best solution just to put all the code into the callbacks of methods on which it depends? well like you said it depends , what you should is to separate tasks into single dependencies not one big monolithic callback.

Is there a quicker way to create a callback than interfaces or handler?

I just want to check if there may be a simpler way to do this.
If I have some generic ASyncTask and it's done I want to pass a success boolean back to the original caller. Normally I create an interface inside the custom AsyncTask class with just one method void onSuccess(boolean success);
The caller would implement that and so on.
I just feel that it clutters the project with mini interfaces.
I could also pass along a handler, but I would have to create a handler for only that purpose which often feels like "just a bit too much code for the purpose".
I could pass a runnable along, but I would have to fire it on a thread and that could cause trouble.
What I want I to execute a method of the calling object when the asynctask has finished. In Objective C I can pass along a "block" of code and maybe there is something similar in Android.
It is a theoretical question and there is no urgency, just curiosity.

You can incorporate event bus into your app, like GreenRobot's EventBus, OTTO or other available but this still requires some work. I personally still do not see problems creating Interfaces and stuff whenever it makes sense for my project.

The first thing I think of is lambdas but since Android doesn't support Java 8 that might be a problem.
If you just need the lambdas and not the other new things in Java 8 you can have a look here:
https://hakanyamanyar.wordpress.com/2014/07/08/using-java-8-lambda-expressions-in-android-developer-tools/
He is basically using a gradle dependency called gradle-retrolambda that allows you to use lambdas in Android. I have not tried this my self though.
Other things that might work for your use case except using Interfaces might be EventBus or Square.io's Otto. They are both based on an publish/subscribe event pattern. I've tried EventBus my self and it's very easy to use and works well.

Android REST API with RetroFit

My question is kinda theorical, hope I can get a clear explanation on this.
I've been looking for a nice rest api consumer for android (or some clear info on how to develop a solid one) and I found the rest api design talk from google IO 2010.
"Developing Android REST Client Applications - Google"
It's been 4 since this talk and I think there might exitst new designs and techniques for this matter, or not ?
The scenario that I think that would work the best for me is this one:
So my first question is, does this architecture is still valid for a new app (Starting from the beginning) ?
I've found Retrofit, which seems a pretty nice and stable Api for the rest service, but I can't quite understand how it works, like if it is a good approach to call my api endpoints from activities (or frags) and the library handles the resume/pause (delivering results when activity is on hold, or not) or I must implement this myself.
Sorry for the long post and thanks for the patience !

You must implement how to handle that yourself, to answer your question.
Yes, that architecture is valid, but RetroFit only forms part of the "Rest Method" block. How would you implement it? That depend on what you want. You could use Retrofit (AKA the REST Method) inside the service, and that would be ok, however you can also skip using services and use it inside of an activity or fragment. However if you do the second option(activities/fragments) you can not think in handling the activity life cycle within retrofit(onStart, onPause, etc..) because since these are network calls, you must perform them on worker threads(AsyncTasks for instance).
So in conclusion, whatever option you decide, being Services or worker threads, you must think in using perhaps observers to control your activity/fragment, and remember that requesting network data is always done out of the ui thread. Implementations of how to handle the situation may be done by you depending on your needs and complexity of the application.

Android Concurrency issue

I have strictly separated the layers between different parts of my Android application.
At some point of execution I am updating my data from xml service on Internet. That updating takes up about 10 seconds and is done completely in the background - meaning the user interface of an application works fine. However further calls to my class (later - DataManager) which is responsible for data updating (after update has been started but not yet finished) makes my application crash. NullPointerException is thrown with objects which NEVER are null.
So I assume that only one Thread can use my DataManager at one time and calls to DataManager from other threads ends up in exceptions.
I tried various combinations of putting 'synchronized' keywords near sensitive methods but it seems that when update is executing - NOTHING can use ANYTHING from my DataManager.
BTW other classes which are related to DataManager during the execution also seem to hold null objects.
I guess I am just missing some kind of design pattern which is used to deal with concurrency problems and maybe anyone can suggest me something?

I had trouble dealing with using the Apache http client because of threading issues and I think your issue could be similar in that respect. What I ended up doing was setting up a callback scheme. This may or may not work for you, of course.
This may seem a bit Rube Goldberg-like to you, but it worked for me.
I would have my UI thread call my data manager object with a method that spawned a thread to go and acquire the data. The method's return value is an object that would EVENTUALLY have the data in it. I would have my activity extend an interface, something like "DataCallbackInterface", with a method that the thread would call after it acquired the data (i.e. the last line in run()). Since that call will inherently be within another thread, you'll need to use a Handler to run anything useful in your implementation of the DataCallbackInterface method. When that method is called, you will know for a fact that the data is there and not rely on any strange synchronization flags to get it right.