Develop Reference

Get the amount of steps taken without a trigger / onSensorChanged

Using Androids sensor libs it is possible to extract the steps taken in a trigger function called "onSensorChanged".
#Override
public void onSensorChanged(SensorEvent event) {
String steps = String.valueOf(event.values[0]);
...
}
The array "event.values[0]" will hold the current steps taken since last phone reboot as the Android Dev Docs says. Beginning to walk will call "onSensorChanged", and the steps can be collected.
Is there a way to collect the last known step count without calling "onSensorChanged" or even walking from inside any onCreate method or alike?
Example imaginary code:
SensorEventValues sev = new SensorEventValues();
Toast.(This,sev.values[0],Toast.LENGTH_LONG).show();

Is it possible to see which functions are called in Logcat?

I know, there is a way to see which functions are called in log-cat is to write a log message on top for every function like this
#Override
protected void onDestroy() {
super.onDestroy();
Log.d("myTag","onDestroy function is called!");
// some logic
}
But it becomes irritating when you have more function.
So, I wonder if there is a way to see which functions are called in adb-logcat without writing log messages for every function.
I hope they can be fetched from somewhere in the stack but I couldn't find it.

You can try Hugo. In that case you have to annotate your methods with #DebugLog only. Then Hugo will generate logs for you (and will print out arguments and return value!). Example from GitHub:
#DebugLog
public String getName(String first, String last) {
SystemClock.sleep(15); // Don't ever really do this!
return first + " " + last;
}
And log output:
V/Example: ⇢ getName(first="Jake", last="Wharton")
V/Example: ⇠ getName [16ms] = "Jake Wharton"

Instead of printing log in every function. I (or most of the people) would suggest you to put debug.
To use debug first create breakpoints inside every function you want to check. To apply breakpoints simply left click in the area to the left of your code (refer image the pink circle represents a break-point).
Then to use Debug you have to press this button after successfully running your application.
As soon as the first method is called your application will pause at the break-point, then you can use F8 (or F6 if you are using eclipse settings) to move to next line, to move to next break-point you can press F9(or F8 if you are using eclipse settings). this way to can check all the functions being called.
This break-point method is really helpful if you just want to make sure that a particular function is being called.
Other than this if you still insist to know the details of all the functions you can store the stacktrace.
final StackTraceElement[] trace = new Throwable().getStackTrace())
StackTraceElement STrace = trace[1];
String className = STrace.getMethodName();

Turn Base Match , how to update all devicesafter every turn

I was so excited to hear about the turn-based match in the new google game services but at the same time a bit disappointed to not see the "flow" of turn based game especially cards games will have hard time to fit the design into the "expected flow" by google turn base. One of the issues I found and I really hope that I missunderstood it in the documentation is updating the game state
According to the documentation, if a user takes a turn (lets say throw a an Ace of Heart) then this will information will be rendered only on the device of the next player. Is there no way to update this information on all the participants devices at the same time? Otherwise the 6th player will have to wait for 5 turns before seeing a movement on his screen!
Any idea?

From the Saving Game State guide:
Call takeTurn() and pass in your game state data as the matchData parameter.
If the call is successful, Play Games services notifies other participants in the match about the update and makes the match data available on all participant devices.
Your game can then call getData() to retrieve the updated game state.
So it appears all participants get the updated state.

I know this thread is old but anyway I'll put my two cents.
If you want be notified whenever any participant in the match takes a turn, attach a OnTurnBasedMatchUpdateReceivedListener to your activity. Whenever the match is updated following a player's turn, your listener is notified via the onTurnBasedMatchedReceived() callback.
You can attach a OnTurnBasedMatchUpdateReceivedListener like this.
public class TurnBasedActivity extends BaseGameActivity implements OnTurnBasedMatchUpdateReceivedListener{
#Override
public void onSignInSucceeded() {
Games.TurnBasedMultiplayer.registerMatchUpdateListener(getApiClient(), this);
}
#Override
public void onTurnBasedMatchReceived(TurnBasedMatch match) {
Toast.makeText(this, "A match was updated.", TOAST_DELAY).show();
}
#Override
public void onTurnBasedMatchRemoved(String matchId) {
Toast.makeText(this, "A match was removed.", TOAST_DELAY).show();
}
}
}
I took the information from here https://developers.google.com/games/services/android/turnbasedMultiplayer#taking_the_first_turn
Hope it helps somebody else.

Understanding return value of cacheInBackground() in EndlessAdapter

I am trying to follow what is going on with the boolean variable, hasMoreData with EndlessAdapter and why is seems to be prematurely turning false.
Let me start from beginning to run through what happens. Note: I am using a task and setRunInBackground(false);
I start off setting my list and setting the adapter:
profileList = new ArrayList<ProfileReview>();
endlessAdapter = new EndlessProfileAdapter(getActivity(), profileList);
endlessAdapter.setRunInBackground(false);
listView.setAdapter(endlessAdapter);
Sidenote: Not sure if this is correct, but it seems I am setting the list with an empty adapter.
The first thing that appears to happen after adapter is set is the method cacheInBackground(), where my profileList size is zero, so it sets 0 as int startPoint when calling my AsyncTask where hasMoreData is set to true. Meanwhile, in this (cache) method, hasMoreData returns true. Not sure why? Because the list is zero in size? Or because its still associated with the default value of true?
In the task, it grabs first 10 items.
Then as user scrolls, the thobber starts spinning. And next 10 are displayed. Log.d tells me that profileList.size() is now 10 and hasMoreData is therefore false.
public void onItemsReady(ArrayList<ProfileReview> data) {
profileList.addAll(data);
endlessAdapter.onDataReady();
hasMoreData = profileList.isEmpty(); \\ Log.'d this out
}
My questions: My list starts with 10 items, users scrolls, it grabs 10 more. Then stops after a total of 20 items (or when hasMoreData == false.) But I have many more items to pull from. How do I keep hasMoreData == true? What is the trigger for this? Obviously the trigger is list size (I think?), and why would the list size ever be 0 once it starts to grab data? (until the end of course)

Not sure if this is correct, but it seems I am setting the list with an empty adapter.
EndlessAdapter is definitely designed to start with a non-empty adapter. In fact, it is designed assuming that the user must scroll to get it to load more data. Behavior in your current approach is unspecified, and I do not recommend that approach. Please load some data, then populate the list once your first batch of data is ready.
Meanwhile, in this (cache) method, hasMoreData returns true. Not sure why? Because the list is zero in size? Or because its still associated with the default value of true?
Since EndlessAdapter does not have a hasMoreData method. A search of the source code to EndlessAdapter turns up nothing named hasMoreData. Heck, the only places the word "more" appears is in comments.
A sample app has a hasMoreData value. Since you are not using this sample app, I cannot help you with random data members of random classes in your own code.
In the sample app, in EndlessAdapterCustomTaskFragment, I use a data member named hasMoreData. This is a boolean value, designed to be returned from cacheInBackground(). The responsibility of cacheInBackground() is to return true if we should continue to load data (after the current batch just loaded), false otherwise. In the case of this sample app, hasMoreData is populated by the call to onItemsReady(), itself triggered by onPostExecute() of the AsyncTask simulating loading some data. hasMoreData is set to true or false depending upon whether the items collection is empty, so it basically does a single load of additional data, then calls it quits.
But that is the behavior of a sample app. I didn't even write most of this class -- it came as a patch adding in support for your own data-fetching task. Do not consider sample code to be anything more than a sample.
Hence, you need to set your hasMoreData value to whatever makes sense for your application logic to serve whatever role you decided to use hasMoreData for. If hasMoreData has the same role in your code as it does in the sample, leave it true until you have determined that you are out of data, then set it false.

"realtime" search using AsyncTask?

I am writing an application that searches a database in "realtime".
i.e. as the user presses letters it updates a search results list.
Since the search can take a while, I need to do the search in background and allow new key presses to re-start a search. So that is a user presses 'a' (and the code starts searching for "a"), then presses 'b' - the code will NOT wait for "a" search to end, then start searching for "ab", but rather STOP the "a" search, and start a new "ab" search.
To do that I decided to do the search in an AsyncTask. Is this a wise decision ?
Now - whenever a keypress is detected, I test to see if I have an AsyncTask running. If I do - I signal it (using a boolean within the AsyncTask) it should stop. Then set a timer to re-test the AsyncTask within 10 mSec, to see if it terminated, and start the new search.
Is this a smart method ? Or is there another approach you would take ?
TIA

First yes, AsyncTask is a good way to do this. The problem I see with your approach is the timer waiting to watch something die. When you invoke the asyncTask hold onto a reference of it. Let it keep state for you so you know if it's out searching or it's has returned. When the user clicks another letter you can tell that asyncTask to cancel. Something like this:
public void onClick() {
if( searchTask != null ) {
searchTask.cancel();
}
searchTask = new SearchTask( MyActivity.this ).execute( textInput.getText() );
}
public class SearchTask extends AsyncTask<String,Integer,List<SearchResult>> {
private boolean canceled = false;
protected onPostExecute( List<SearchResult> results ) {
if( !canceled ) {
activity.handleResults( results );
}
}
public void cancel() {
canceled = true;
}
}
This is safe because onPostExecute() is on the UI thread. And cancel() is only called from the UI thread so there is no thread safety issues, and no need to synchronize. You don't have to watch a thread die. Just let the GC handle cleaning up. Once you drop the reference to the AsyncTask it will just get cleaned up. If your AsyncTask blocks that's ok because it only hangs up the background thread, and when the timeout hits it will resume by calling onPostExecute(). This also keeps your resources to a minimum without using a Timer.
Things to consider about this approach. Sending a new request everytime a new letter is typed can overload your servers because the first few letters are going to produce the largest search results. Either limit the number of results you'll return from the server (say 10-50 results max), or wait until they've entered enough characters to keep results down (say 3). The cons of making the user type more characters is the feedback doesn't kick in until 3 chars. However, the pro is it will dramatically reduce the hits on your server.