Develop Reference

MessagePack : MessageTypeException: Expected raw value, but got boolean [Android]

I am implementing MessagePack in my android application. I am getting following error while deserializing Response data only when app runs in below API 22 devices;
Caused by: org.msgpack.MessageTypeException: Expected raw value, but got boolean
at org.msgpack.unpacker.Accept.acceptBoolean(Accept.java:33)
at org.msgpack.unpacker.MessagePackUnpacker.readOneWithoutStackLarge(MessagePackUnpacker.java:154)
at org.msgpack.unpacker.MessagePackUnpacker.readOneWithoutStack(MessagePackUnpacker.java:139)
at org.msgpack.unpacker.MessagePackUnpacker.readOne(MessagePackUnpacker.java:73)
at org.msgpack.unpacker.MessagePackUnpacker.readString(MessagePackUnpacker.java:472)
at org.msgpack.template.StringTemplate.read(StringTemplate.java:46)
at org.msgpack.template.StringTemplate.read(StringTemplate.java:25)
at org.msgpack.template.builder.ReflectionTemplateBuilder$FieldTemplateImpl.read(ReflectionTemplateBuilder.java:70)
at org.msgpack.template.builder.ReflectionTemplateBuilder$ReflectionClassTemplate.read(ReflectionTemplateBuilder.java:143)
If I run same application in device with API 22 or above everything works fine.
Following code is for deserialize ;
private T readMessagePack(byte[] response, Class<T> responseType) throws Exception
{
MessagePack msgpack = new MessagePack();
TemplateRegistry registry = new TemplateRegistry(null);
ReflectionTemplateBuilder builder = new ReflectionTemplateBuilder(registry);
Template<T> objTemplate = builder.buildTemplate(responseType);
BufferUnpacker unpacker = msgpack.createBufferUnpacker();
unpacker.resetReadByteCount();
unpacker.wrap(response);
return objTemplate.read(unpacker, null);
}
I am using org.msgpack:msgpack:0.6.8 Dependency.

After doing research I solved my issue. May be my answer will helpful to someone.
This issue is caused by the order of declared fields that BufferUnpacker returns. For that we have to use #Index() annotation while Serializing & Deserializing.
For example;
#Index(0)
public boolean state;
#Index(1)
public String error_message;

Search with location returns internal server error

I've problem with building search request on android.
ArrayList<ParseQuery<Entity>> queriesByCriteria = new ArrayList<>();
queriesByCriteria.add(ParseQuery.getQuery(Entity.class).whereContains("userName", criteria));
queriesByCriteria.add(ParseQuery.getQuery(Entity.class).whereContains("locationName", criteria));
queriesByCriteria.add(ParseQuery.getQuery(Entity.class).whereContains("descriptionBefore", criteria));
queriesByCriteria.add(ParseQuery.getQuery(Entity.class).whereContains("descriptionAfter", criteria));
ParseQuery<Entity> combinedQuery = ParseQuery.or(queriesByCriteria)
.orderByDescending("createdAt")
.whereEqualTo("done", true);
float mapRadius;
int mapUnits = preferences.getMapUnits();
if (mapUnits == MapUnitType.MAP_UNIT_KILOMETER) {
mapRadius = (preferences.getMapRadius());
} else {
mapRadius = 1.6f * (preferences.getMapRadius());
}
entities = combinedQuery
.whereWithinKilometers("location", new ParseGeoPoint(latLng.getLatitude(), latLng.getLongitude()), mapRadius)
.find();
So find() throws exception "com.parse.ParseException: internal error".
Version of Parse SDK is 1.7.1
Is it bug of parse.com or I do something wrong?

Yes, internal errors in SDK's refer to errors which are internal and not meant to be exposed to user's of the SDK. In this case, there is an edge case not handled internally by the find() method. My recommendation would be to go to the Parse suppport page and report this as a bug.

android how to check if device supports Sview

How can we determine if given android device supports S-view or not ?
Is there any way programatically or through adb command ? So that we can check if device supports sview and to check its status when it will be shown.
Any guidelines or help would be greatly appreciated.
EDIT :
I added workaround below for this check.
Also if someone has different approach please let me know.

I have got workaround for this,
These are extra features added by samsung for the devices for which no constant values are added in Android api, so we need to add them manually.
private static final String SVIEW_FEATURE = "com.sec.feature.cover.sview";
private static final String HOVER_FEATURE = "com.sec.feature.hovering_ui";
private static final String SENSOR_HUB_FEATURE = "com.sec.feature.sensorhub";
private static final String SPEN_FEATURE = "com.sec.feature.spen_usp";
You can call below function as ,
hasFeature(SPEN_FEATURE );
Function :
private boolean hasFeature(String feature) {
FeatureInfo[] infos = getPackageManager().getSystemAvailableFeatures();
for (FeatureInfo info : infos) {
if (!TextUtils.isEmpty(info.name)) {
Log.d("TAG", info.name);
if (feature.equalsIgnoreCase(info.name)) {
Log.v("TAG", "Feature supported "+ info.name);
return true;
}
}
}
return false;
}

Check the link below, it could be helpful to you. As android doesn't support S view directly.
s-view functionality on any phone

Format exception message to contain the whole stacktrace in Google Analytics for Android?

I would like to have the whole stacktrace in Google Analytic's report's for my mobile application.
I wrote class that print's the stacktrace and put's it into string, but it doesn't work.
My custom ExceptionParser:
#Override
public String getDescription(String threadName, Throwable throwable) {
return threadName + " " + getStackTrace(throwable);
}
private String getStackTrace(Throwable throwable) {
final Writer result = new StringWriter();
final PrintWriter printWriter = new PrintWriter(result);
throwable.printStackTrace(printWriter);
return result.toString();
}
And I set it like this:
EasyTracker.getTracker().setExceptionParser(new StacktraceExceptionParser());

The method below combines the entire stack trace into a single comma separated line, which may help in case Analytics returns just the first line. But there still may be a length limit so it may be prudent to do filtering to eliminate items you do not need (see comment)
public String getCombinedStackTrace(Throwable aThrowable) {
final StringBuilder result = new StringBuilder();
result.append(aThrowable.toString());
result.append(',');
String oneElement;
for (StackTraceElement element : aThrowable.getStackTrace() ) {
// you can do some filtering here, selecting only the elements you need
oneElement = element.toString();
result.append( oneElement );
result.append( ",");
}
return result.toString();
}
I second Nikolay's comment about using an error reporting library. I found it to be tremendously helpful.

I know this thread is old but I am trying to figure out how to get this working, but just for completeness there is a useful method on Log that does what you want
String stackTraceStr = Log.getStackTraceString(exception);
EDIT: In response to the 100 char limit comment
I could never get EasyTracker.getTracker().setExceptionParser(...) working, infact I do not think it works, so I followed the blog post here http://dandar3.blogspot.co.uk/2013/03/google-analytics-easytracker-detailed.html
The important point in the blog post is to make sure you set your ExceptionParser on the GA exception handler:
// Make sure you set the context on EasyTracker first
EasyTracker.getInstance().setContext(this);
// As in in the blog post, we have to get the ExceptionReporter
// in order to set the ExceptionParser
Thread.UncaughtExceptionHandler uncaughtExceptionHandler = Thread.getDefaultUncaughtExceptionHandler();
if (uncaughtExceptionHandler instanceof ExceptionReporter) {
ExceptionReporter exceptionReporter = (ExceptionReporter) uncaughtExceptionHandler;
exceptionReporter.setExceptionParser(new AnalyticsExceptionParser());
}
This worked for me and logs more than 100 chars.

Analytics may be limiting the size of messages you can send. I suggest using a real error reporting library like ACRA or BugSense instead. You will get extra features such as device info, configuration details and better error reporting (combining multiple exceptions if they have the same trace, etc.).

Using java.util.regex in Android apps - are there issues with this?

In an Android app I have a utility class that I use to parse strings for 2 regEx's. I compile the 2 patterns in a static initializer so they only get compiled once, then activities can use the parsing methods statically.
This works fine except that the first time the class is accessed and loaded, and the static initializer compiles the pattern, the UI hangs for close to a MINUTE while it compiles the pattern! After the first time, it flies on all subsequent calls to parseString().
My regEx that I am using is rather large - 847 characters, but in a normal java webapp this is lightning fast. I am testing this so far only in the emulator with a 1.5 AVD.
Could this just be an emulator issue or is there some other reason that this pattern is taking so long to compile?
private static final String exp1 = "(insertratherlong---847character--regexhere)";
private static Pattern regex1 = null;
private static final String newLineAndTagsExp = "[<>\\s]";
private static Pattern regexNewLineAndTags = null;
static {
regex1 = Pattern.compile(exp1, Pattern.CASE_INSENSITIVE);
regexNewLineAndTags = Pattern.compile(newLineAndTagsExp);
}
public static String parseString(CharSequence inputStr) {
String replacementStr = "replaceMentText";
String resultString = "none";
try {
Matcher regexMatcher = regex1.matcher(inputStr);
try {
resultString = regexMatcher.replaceAll(replacementStr);
} catch (IllegalArgumentException ex) {
} catch (IndexOutOfBoundsException ex) {
}
} catch (PatternSyntaxException ex) {
}
return resultString;
}

please file a reproduceable test case at http://code.google.com/p/android/issues/entry and i'll have a look. note that i will need a regular expression that reproduces the problem. (our regular expressions are implemented by ICU4C, so the compilation actually happens in native code and this may end up being an ICU bug, but if you file an Android bug i'll worry about upstream.)

If you launched with debugging you can expect it to be about twice as slow as a regular launch. However a minute does seem extraordinary. Some things to suggest, i. look at the console output to see if warnings are being spat out, ii. when it is doing the compile, in the debugger press 'pause' and just see what it is doing. There are ways to get the source, but even so just looking at the call stack may reveal something.