Develop Reference

Lisp on Android

I'm interested in getting started with Android development and would like to use a Lisp-style language. However, I want something that won't limit me if I choose to write a complex app, so it also needs to have reasonable performance, executable size and startup times. This limits my choices to languages that compile to JVM bytecode that have Android support.
Clojure (Neko)
This would be my first choice because of Clojure's expressiveness, but I have heard that it has problems with slow startup times and poor performance on Android. However, the threads that I came across are quite old so I'd be interested to know if things have improved since then.
Scheme (Kawa)
I came across this option here. Scheme is a nice language, so this option is appealing but it looks like the Android specific libraries it provides may be somewhat minimal. Of course, one could always call the Java libraries from Scheme.
I'd be interested to hear about any experiences with using the above languages (or other lisps for that matter) on Android. Thanks!

Code Audit for Android/iOS

I have just been given a task at work to help audit a code base for a mobile app. I am not a mobile app programmer, although I've been a software developer for many years now, but know nothing about mobile apps. I was wondering if there's any tips or tools that I can use for this code audit.
I have seen the replies to this older post for a Java EE application, which can't be applied to my case since they're mostly based on having maven to build the app and in my case they use Gradle. Also these replies are from 2011 and perhaps there are more recent ones I'd really be very grateful to hear about.

In itself, the fact of appointing someone with no experience in the target environment seems like a complete nonsense to me, so I'd question the management here.
I do hope for you that you know at very least the languages these apps are written in: probably Java for Android & Objective-C for iOS (your question didn't mention what technologies your past experience concerned). If not, you're bound to just make remarks about comments, file size, and maybe some about naming conventions, which is of little interest compared to a real audit.
Beyond programming languages, iOS and Android are designed in very different ways, with different conventions & patterns. I actually know very few people who are really good in both environments, and there's a reason for this: these are different worlds, each of which you can easily spend your whole time on to learn APIs, common libraries, design philosophy, work-arounds for common issues, and understand a bit of how the internals work.
I don't know how much time you have to perform this task, but I'd suggest you learn how to code a basic app on the target environment, and learn about the key components.
My approach is generally:
gather some context from the team
get the source
build the app & get a taste of what it's doing (I usually hand-draw a screen flow diagram at this stage, it's useful later when you navigate in the code), also take note of bugs, slow features, non-user-friendly stuff (feedback is important to the team)
go to the source code, examine it's macroscopic layout:
. look at the build scripts to see what external libs it's using
. take note of the general package hierarchy, check that the naming is consistent, that packages are not overloaded with junk
. look generally at the class naming: is it consistent? do class names help figure out what's actually inside
. do some basic stats about file sizes: it's something that can quickly indicate some design flaws
now about the code in itself:
. read it until satisfied that you understand the general way it works (drawing a technical flow diagram helps), I like to start by the app entry-point (generally an activity in Android)
. make sure you spot how what you read achieves what you saw while testing the app
. take note of bad coding habits you spot while reading (naming, comments, it can be anything: there's no limit to how bad the code can be ^^)
. take note of unreadable/overly-complex bits of code (but don't spend days just to understand them)
. if you had noticed slow features in the app, it might be worth looking at those bits of code a little more carefully
. have a good night sleep, then re-read all your notes, and try to extract some high-level remarks about the application design
Now, specifically for Android, here the most common list of things to look for, based on my experience:
components life-cycle handling issues (for components like activities, services, fragments and such): symptoms include device rotation and application switches causing issues
thread handling issues (things done on the UI thread, when they should really run in background)
massive activities / services (many people think that creating activities / fragments / services is all that's required in terms of architecture - it is true only for very simple apps)
I won't enter more into the specifics, because people a lot more intelligent than me wrote books about this. And you have to code apps to really get a grasp of those subjects: a lot of them, so that's what you should start with: code apps yourself, otherwise: 1/ your audit will be irrelevant 2/ the team will spot your lack of skills pretty fast - depending on the aim of this audit, you might have a very hard time facing them...

Android Netbeans Blackbox, Whitebox, or both Test Driven Development

I'm working with Android in Netbeans and trying to decide which testing framework to implement for my application (I've never done TDD in Android before). I've been using this thread to look into different resources. I'm mainly familiar with whitebox, so I feel that I would be more comfortable with the built-in Instrumentation Framework. However, this is the first time I've heard of blackbox testing (Robotium), but it looks like it would be really useful as well. Is it common practice to implement both whitebox and blackbox tests? Or is only one really necessary? If both, what things are best to be whitebox tested and which are best to be blackbox tested? Or is this a totally useless question as it's completely application dependent and I should just pick one and start messing with it?
[EDIT]: I also want to add that I don't have any experience with JUnit since a lot of explanations seem to assume a basic understanding of it.

The two options you suggest (Instrumentation and Robotium) are actually pretty much the same thing, the closes to whitebox (or true tdd/unit tests would probably be roboelectric).
Is it common to do both? Yes i think that is usually a good approach normally you want to test things as low down as possible and then have fewer of the big blackbox tests, android doesn't make this the easiest if you ask me though so you may have more luck with the instrumentation/robotium tests cases as these are fairly easy to understand and they match up with what you can see on the screen fairly easily.
With regards to junit, android is bundled with junit3 which has much less features/complexity as jUnit4, and for the most part the only thing you will need to know is to name your testmethods with the word "test" in front of it e.g. public void testXXX().

Can an app be monitored for security?

A coworker and I were talking (after a fashion) about an article I read (HTC permission security risk). Basically, the argument came down to whether or not it was possible to log every action that an application was doing. Then someone (an abstract theroetical person) would go through and see if the app was doing what it was supposed to do and not trying to be all malicious like.
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing. Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
Can I get some input one way or the other? Is it completely impractical to even attempt to log what a foriegn application is doing?

I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing.
Not so much "hack Dalvik" but "hack the android.* class library, and perhaps a few other things (e.g., java.net).
Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
You might be able to do some fancy pattern matching or something on the output -- given that you have determined patterns of inappropriate actions. Of course, there is also the small matter of having to manually test the app (to generate the output).
Is it completely impractical to even attempt to log what a foriegn application is doing?
From an SDK app? I damn well hope so.
From a device running a modded firmware with the aforementioned changes? I'd say it is impractical unless you have a fairly decent-sized development team, at which point it is merely expensive.

This is both possible and practical if you are compiling your own ROM. Android is based on Linux and I know several projects like this for Linux, like Linux Trace Toolkit. I also know of research into visualizing the results and detecting malicious apps from the results as well.
Another thing functionality like this is often used for is performance and reliability monitoring. You can read about the DTRACE functionality in Solaris to learn more about how this sort of stuff is used in business rather than academia.

Better Android Coding

What I am looking for is better coding with parameters such as memory management, faster processing and cleaner coding. Is there any set of Good Coding Guide for Android using which we can make better applications. For example;
Which of the following convention is better among them:
EXAMPLE - 1
TextView tv = (TextView) findViewById(R.id.sampleTextView);
tv.setText("Hello World");
-- OR --
((TextView) findViewById(R.id.sampleTextView)).setText("Hello World");
EXAMPLE - 2
BroadcastReceiver br = new BroadcastReceiver() {
...
...
}
IntentFilter filter = new IntentFilter(...);
registerReceiver(filter, br);
-- OR --
registerReceiver(new IntentFilter(), br);
-- OR --
registerReceiver(new IntentFilter(), new BroadcastReceiver());
Which will result in lesser memory usage and help in quicker garbage collection. I have seen both type of coding in Android Framework (in Gingerbread as well as Froyo).
I have been developing for more than a year on Android now and I think anyone can code but to code clean and proper is what makes the difference. Can someone suggest or help out from their experience and knowledge.

These kinds of micro-optimizations aren't really worth worrying about unless you've seen a significant performance hit in your application. In any case, I would guess that it's even possible that the compiler is able to deduce that Example 1a = Example 1b. The amount of performance difference between them would amount to a few hundred nanoseconds at best as tv is a reference and is cheap to move around.
My recommendation would be to code in such a way as to make it as readable to you and your team as possible. If you need better performance, better algorithms will help way more. If you've already used those better algorithms, then you should experiment with the profiler to figure out which is faster.

For both examples that you give, there is no difference between the various alternatives that you mention.
If you want to dig into this at a deeper level, write up some sample code that you want to examine, compile it into a jar and then use a disassembler on it to see exactly what bytecode is being generated. You should see that the bytecode is essentially the same in each of your cases.

Both your examples just mean nearly nothing in aspects like memory management or processor time. Compiler will inline the variables in both examples. And even if he didn't the overhead is just one object reference. No benchmark could show you such difference.
In such cases prefer to write readable code.
You should be more bothered about preformance in places it really worths - in database working or image/video processing.
AFAIK, there is no any special recommendations for android. All of them are general advices about working with memory, databases, network and so on.
Read Effective Java by Joshua Block, it will be sufficient.

I agree with everyone else that say that this type of optimization will do nothing that you can notice.
The only case in which you should consider optimizing is if you implement a complex draw method by hand or if you parse a big xml file (some changes might improve the running time).
Anyway, before optimizing, always measure.
You can't optimize what you can't measure
To learn how to profile your application, read this
http://www.jpct.net/wiki/index.php/Profiling_Android_Applications

Thank you for the responses. After reading I think I completely agree with all you, especially SapphireSun. Seeing both the kinds of coding, I was wondering whether inline has any pros or cons over the other types of coding.
But as far as I think that it is better to use declarations such as ((TextView) findViewById(R.id.sampleTextView)).setText("Hello World"); instead of allocating it to a temporary variable because that would increase an object reference which will get garbage collected when GC is ticked. But with the declaration as above I guess there is no involvement of such object being left behind for GC.
Please correct me if I am wrong.