ADT 18 Build issues

First of all, I want to agree with them, the ADT 17 was a step in the right direction, I just don't understand some of the logic working in the background of the ADT development, working on new features, and not rethinking the build problem, over and over there are changes... I think the most complex build imagined, should be expected, and these tweak-fixing, is TOO DAMN ANNOYING, at work I've updated to ADT 17, and I didn't dare to do that at my personal projects, these projects has many dependencies, and few apklibs, and although I understand the ADT 17 build issues, I just don't know if I'm ready to waste my time on working around the issues I didn't experience yet, when they would have the golden solution, I would update my personal Eclipse to the latest ADT.

Meanwhile I'll probably install the SDK 19 & ADT 18 at work, and see how it goes...

30-04-2012
HA.... I spoke too soon.... :(

Wow guys, there is something to share about this... I've been working with multiple Eclipses (I had a flaw organizing my workspaces), and then BAM, one of the Eclipses Crashed, and the others followed...  

And then, the second crashed Eclipse, Android supported (Obviously), stopped working, I cannot start Eclipse, not Google, and no clean workspace made it start, and now I was forced to install ADT 18 which I did (my private projects were still build with 16, I feared the update of 17)  and....  it's back, the FRIGGING Dalvik error... WTF??? are you guys playing around there? generalize... not everyone uses your setup... not everyone develop FLAT, some of us need to be able to maximize the potential of project architecture, and you are fucking mine up every time...

Nothing builds this Android in a proper way, how the hell can that happened, Maven does gives some of what I need, but using it is costly, annoying sometimes, not always suitable, and not always clear what is wrong, especially with the tricky bugs... and don't get me wrong, when I use Maven with different frameworks, it works fine, and saved me darn lot of time, and for that I love it.

I think you should consider professional consultant, to define your targets... and what is important and what is not... how the hell do you implement so many new features when the core is rotten? Don't get me wrong again, I think the new features are great add-on, and very useful, but it worth nothing if I cannot build the darn thing, just because I have a complex project architecture.

I'm working now to split up my main project into multiple small project, and then if the top most project would not compile and deploy, IN A CLICK AND ... DONE! kinda way, I would write my own Android project builder.

The Journey to Android Automation

Guys,

This was ANNOYING... I spent 4 hours trying to configure this damn Robotium project to work with my Cyborg framework... damn this was tough, and I'm not done yet.

Some conclusions...

1. You cannot add same apklib as a dependency to both the tester project and target project!
2. If you have a dependency you would like in both the tester project, and the  target project, be sure, that the tester project depends on the  target project/jar (Not apklib!!!), and while at it, make sure the dependency is been imported by the  target project.
3. Sometimes while trying to debug the tester project, I placed some breakpoints, at the test case constructor, and the running halt, but without any stacktrace, as if the debugger failed to connect to the UI, although the program halt at the break point, Solution: restart Eclipse.
4. The tests are not been mapped for execution, Solution: These guys are not serious, in order to define a test, the name of the method must start with the word 'test' explicitly, oh yeah, and an annotation to define some properties for the test... you see because an annotation cannot be extended, and because there are different implementation for a 'Test' then the commonality they have came up with is to start the name of the frigging method with the word 'test', here is an alternative Another annotation called @Test, it would be a revolution.
5. The class loading process is different. In any Android app developed, the classes of the project itself, and the classes of its dependencies, are loaded lazily, while the Robotium app, loads all the project, and its dependencies classes at launch.

After long 10 hours of work I finally managed to debug the automation project, and hit a break point... from now on the process should be as simple as developing anything else.

Update:


My Cyborg framework, now fully supports scenario recording, and scenario automation executor, together giving me an invaluable power to turn my app users, together with a crash report server, to be my private QA, lets say that this should cover 80% of the cases...

Android and Singleton pattern

In the past year or so, I've been assigned to work on multiple pretty complex Android projects. Also in the past year, I have developed my own Android projects, while learning how to avoid Android development issues, here are some of the conclusions.

Due to fact that Android does not allow direct communication between activities/broadcast receivers/services, which I would refer, as Model Access Limitation (MAL), causes most development teams, to develop their application, based mainly on the Singleton pattern. There is no discussion as for how to declare these Singletons or if one declaration way is better then another, I just think this design pattern is used widely, in the most ignorant way possible and I'll elaborate.

What is a Singleton? 

• Some developer say that a Singleton is a class type, that would have a single instance of that class type existing in the entire JVM. (This is somewhat reasonable)
  To achieve this developers have too many ways and theories on how to instantiate a Singleton: Enum, LazyLoader, double sync, and other.
• Some developer ask it to be impenetrable, that anything anyone would do, would not, by any chance create two instances of the same Singleton type. 
• In the case of Android, developers (without saying it out laud) turn to the Singleton to overcome the Android MAL, because a Singleton provides access to data from everywhere in the code  (NOT necessarily a good thing!) , and gives the impression that it is encapsulated. (It is!) 

Let me picture it for you: 

If someone would like to abuse the Singleton he can, and the fact that something can be accessed from everywhere in the code, together with Android MAL, can turn into something really really ugly, and believe me I've seen more then one, very UGLY "Singleton"s!

Which now brings us to the actual fact, it is not that we would want to have a single instance in the JVM, but more of a:

"Single instance that would be shared and used by other objects and threads in the JVM"

After assimilating this(hopefully you have), and taking the previous facts about Singletons into consideration, I've concluded:

(mean while it is my own conclusion which serves me so very well for the past years)

 "ONLY Real* Singletons will be used as Singletons in an Android projects!!"

I say Real, because there are developers, that don't understand when something is really a Singleton, and when another pattern is available and even preferable, they turn to the quickest, dirtiest, most comfortable way they find first, to overcome a Android MAL, and what can you do, Singleton just pops first to mind.

I've developed an entire framework 'Cyborg', based on this, it is not that I don't use Singletons, I have very few REAL Singletons, but I have many Single(Instance)ton, which are managed by a single-instance manager, that can only be instantiated once as well. (unless of course you would like to abuse it)

Once I've develop the infrastructure to manage Single-Instances, I've learned and adopted a very nice rule while developing, and using 3rd party libraries:

Don't abuse it... Use it!

To conclude, I think the Singleton pattern is an amazing one, but you don't eat with a shovel, nor dig with a spoon...

Stupid Bluetooth behavior of Android phones

It seem that every post I type I feel the need to start it with Google, Google, Google... what am I going to do with you... It is just because I think you are doing good, but not good enough...

I've developed a Bluetooth packet protocol, any application that wants to be used on a wide enough variety of devices, and use Bluetooth on an Android platform, should take the following under consideration:

• First, my stack overflow question... about an IllegalMonitorStateException, This one was a bugger, I've added a toast to the user to restart the phone.

• Second, to my surprise there are different buffering implementations, for example, on the same LG phone, in the first few packets arriving, the first ~150 bytes are ZEROs, no data... probably due to the fact that a connection has just been established.
  This problem happens when calling one of the read(...) methods which does NOT block, surprisingly calling repeatably to read(), which DOES block, would result in the correct buffer. 

• Here is yet another problem I'm facing, hopefully this will be solvable...
• 08/06/2012, I've encountered another issue with the Bluetooth socket on an other Android device, once the Bluetooth connection is terminated.
  On some devices the next byte read() from the stream returns -1, instead of throwing a IOException.

Will keep it coming as I go...

Sites with good invaluable information:
android-bluetooth-api-connect-to-multiple-devices
connecting-to-a-already-paired-bluetooth-device
this
this
this