Develop Reference

Array in Between Condition

How do I implement this condition as shown in this image.

That's just in 2..4, i.e. in the integer range from 2 to 4, including the 4.
The ≤ is just some hint text provided by the IDE, similar to how you can see argument names in function calls - it's not part of the code, it's not really there. They added it to make it clearer what the .. operator does (vs until)
This might be because they're introducing a new operator, ..< which seems intended to replace until, or maybe they've been there a while! You can turn them on and off here in the settings:

Proguard shrinking behavior - 2nd level methods

Sorry if this is too basic - I'm struggling to find Proguard documentation I can understand.
My understanding of how Proguard shrinks Android applications is by looking for unused (uncalled?) methods and eliminating them from the build. So if I have a method buynewCoke() that is never called anywhere else in the code, it will be removed.
However, what if there exists a method, say visitStoreAfterMidnight() that calls buyNewCoke(). And visitStoreAfterMidnight itself is never called. Does Proguard still remove both of these methods? Or does it keep buyNewCoke() because it is refrenced by something?
That is, if A calls B and nothing calls A, how does Proguard behave?

Both visitStoreAfterMidnight() and buyNewCoke() would be removed.
Actually it works similar to Garbage Collection, it starts from things that it needs to keep and check what they used and keep only these.
Edit:
official reference:
http://proguard.sourceforge.net/manual/introduction.html
Entry points
In order to determine which code has to be preserved and which code
can be discarded or obfuscated, you have to specify one or more entry
points to your code. These entry points are typically classes with
main methods, applets, midlets, activities, etc.
In the shrinking step, ProGuard starts from these seeds and
recursively determines which classes and class members are used. All
other classes and class members are discarded.

Debugging in Android Studio... off by a line?

Something has been bothering me for awhile, and I'm wondering if I'm misremembering how things work or if something is wrong with my IDE setup.
Say I have a method
public void normalDebuggerBehavior(String x) {
(BP) int y = 12;
int z = 10;
}
If I set a breakpoint on the first line of the method (BP), and the debugger stops on that breakpoint, shouldn't I be able to see the value of the passed parameter x without needing to step to the next line (int z = 10) either by right-clicking -> evaluate expression or by adding it to the watchlist? I would think this would be in scope at this point.
If I'm not able to do this, and I'm supposed to be able, what would cause this?
Screenshot:
Stepping to the next line brings vendor into scope. Yes, this is a "fresh" compile.

Debuggers run on bytecode and not on Java source code. The mapping between Java source and bytecode is not always one-to-one.
When you place a breakpoint on the first line of a method, it is placed on the method entry point in the bytecode. The bytecode that actually reads in the method parameters has not been executed yet. You can observe this by looking at the bytecode disassembly and noticing the aload instructions at the beginning of a method with parameters.

I would assume that, since you are not using the argument x (in your example) the compiler gets rid of it, thus the debugger cant "see" it.
I think its a similar thing in your picture. It might be that the compiler optimises some stuff and thus the debugger cant see some variables...

Try turning off your jacoco test coverage off for the debug build in your build.gradle file:
debug {
...
testCoverageEnabled false
}
This completely fixed the issue for me.

Keep sections are being removed on generation

I am using GreenDAO v1.2.0 to generate entity classes for an Android app.
I have set enableKeepSectionsByDefault() on my schema, and am getting these comment lines in my generated classes:
// KEEP METHODS - put your custom methods here
// KEEP METHODS END
I have put some custom methods between the comments, but the custom methods are removed every time I regenerate.
Is there something else I need to do to get this to work?

There is a parsing bug in greenDAO that will cause some or all of your KEEP METHODS to get wiped out by running the DaoGenerator.generateAll() method (even with schema.enableKeepSectionsByDefault() enabled)
The bug is that your Entity class (the one you have added custom imports, fields or methods to) REQUIRES a blank line at the end of the file.
for example
...
//KEEP_METHODS_END
}
... end of file
will fail, while
...
//KEEP_METHODS_END
}
... end of file
will work. Nasty little bug. Until it's fixed (if ever), ensure that your entity classes have a blank line at the end.
Hope this saves someone the torment I have experienced.
Ensure that the last line of the generated entity class is blank.

You need to call the schema.enableKeepSectionsByDefault();.

better way to do Debug only assert code

I am writing my first Android application and I am liberally using asserts() from junit.framework.Assert
I would like to find a way to ensure that the asserts are only compiled into the debug build, not in the release build.
I know how to query the android:debuggable attribute from the manifest so I could create a variable and accomplish this in the following fashon:
static final boolean mDebug = ...
if (mDebug)
Assert.assertNotNull(view);
Is there a better way to do this? i.e. I would prefer not to use an if() with each assert.
thanks

I think the Java language's assert keyword is likely what you want. Under the covers, the assert keyword essentially compiles into Dalvik byte code that does two things:
Checks whether the static variable assertionsDisabled (set in the class' static constructor via a call to java.lang.Class.desiredAssertionStatus()) is != 0 and if so, does nothing
If it is 0, then it checks the assertion expression and throws a java.lang.AssertionError if the expression resolves to false, effectively terminating your application.
The Dalvik runtime by default has assertions turned off, and therefore desiredAssertionStatus always returns 1 (or more precisely, some non-zero value). This is akin to running in "retail" mode. In order to turn on "debug" mode, you can run the following command against the emulator or the device:
adb shell setprop debug.assert 1
and this should do the trick (should work on the emulator or any rooted debugging-ready device).
Note however that the aforementioned Dalvik code that checks the value of assertionsDisabled and throws an AssertionError if the expression is false is always included in your byte code and liberal sprinkling of asserts in your code may lead to byte code bloat.
Please see this for a bit more detail: Can I use assert on Android devices?

If you're concerned about shipping code with the JUnit asserts in (or any other class path), you can use the ProGuard config option 'assumenosideeffects', which will strip out a class path on the assumption that removing it does nothing to the code.
Eg.
-assumenosideeffects class junit.framework.Assert {
*;
}
I have a common debug library I put all my testing methods in, and then use this option to strip it from my released apps.
This also removes the hard to spot problem of strings being manipulated that are never used in release code. For example if you write a debug log method, and in that method you check for debug mode before logging the string, you are still constructing the string, allocating memory, calling the method, but then opting to do nothing. Stripping the class out then removes the calls entirely, meaning as long as your string is constructed inside the method call, it goes away as well.
Make sure it is genuinely safe to just strip the lines out however, as it is done with no checking on ProGuard's part. Removing any void returning method will be fine, however if you are taking any return values from whatever you are removing, make sure you aren't using them for actual operational logic.

I mean if you were using a language feature, like assert(), the compiler should be able to strip that out. But this is an actual class and if a class is referenced by executable code it will be included or assumed included in the final product by the compiler.
However there is nothing stopping you from creating a script that removes all the references to the Assert class in all of your code base before compilation.
Another approach would be to make a test project that targets your application and within JUnit tests actually calls the Assert on the areas which you want to make sure work. I personally like this approach because it is a nice and clean separation of test and application.
If you are just worried about the having an if-statement everywhere, then just wrap Assert with your own class, DebuggableAssert which does that check before each call to Assert.X. It will be sort of less performant because of the method entry/exit and the conditionals but if you can maintain your code better then it might be worth it.