Having recently revived an android project I haven’t opened in close to 6 months, I was left scratching my head as to why I couldn’t run any of my integration tests.
Thinking back, I remembered having problems getting robotium to instrument the clicking of a button, as simple as it sounds, theres a few little gotchas involved. Firstly, I needed to modify the test code to click on text, rather than a button, as it has been suggested by various users on StackOverflow that there does tend to be odd side effects when clicking buttons:
After procrastinating for many years (4 to be precise), I finally sat and passed the SCJP exam. The exam itself wasn’t particularly difficult, but theres a lot of things you can get tested on that you’ll rarely use in everyday development. Having been developing in Java for around 4 years now, I’ve never needed to do any serialisation or do any fancy concurrency work other than starting a thread for an asynchrnous task.
So to iterate, theres a lot in there that you may not use, but the test expects you to know it well, so be sure to practice and write a lot of code.
Looping constructs are very useful in any programming language, however they can be come particularly complex when you have a variety of nested loops and you need to drop out from particular iterations, or exit the loops entirely under a set of given circumstances. Fortunately for us, Java provides us with 2 keywords that we can use to help in these situations:
- break - breaks out of the entire loop, and no more iterations will occur. The thread of execution will then move onto the next line of code after the loop.
Another bite-size SCJP blog post, this time we’ll tackle interfaces.
Interfaces are, in the simplest terms, just a contract. It specifies things that a class must do if that class signs up to its contract, but it doesn’t provide any details of how those things must be done.
For example, you may wish to create an interface called Driveable. This interface defines the behaviour of anything that wants to become driveable, whether it be a Car class, a Motorcycle class, or even a Boat class.
Polymorphism basically means that one thing can take many forms, and this is particularly useful for programmers, as it allows us to treat similar types of object in a single manner, yet the objects may actually be slightly different at runtime.
One application of this might be where we have an animal class, we know that the animal class has methods like makeNoise(), move() and eat(), and we can happily develop our application against this. However, we may then like to extend the animal class, and create subclasses like Dog, Fish, and Cat, each which would inherit those methods, and optionally override the implementation to do things that are a little more Dog specific.
Inheritance is a practice of one thing extending another. So you can more specific subclasses of a class. Inheritance is available in most programming languages, and in Java it is implied using the extends keyword.
For example, you may have several objects like Car, Boat, Truck, these may all have common behaviour and state between them. You could duplicate the shared members between them, but that can lead to a maintenance nightmare for some poor man in the future. The best option would be too look at inheritance, and try to move common, generic code to a superclass, such as Vehicle.
Encapsulation is a fantastic OOP concept of being able to shield class state via the use of accessor methods.
Imagine that you have a class, perhaps called Person. This class will have some form of state, such as name, age, date of birth. These would most likely be stored against reference variables. If you left these publicly available, then anyone who develops against your class can freely access them and assign them to whatever they feel necessary.
There are times when developing, when you need to do similar behaviour but with differing input arguments, for example you may have a method that prints something to the console. You may need to print Strings, Integers, and all sorts of other objects. You could (if you really wanted), create a method for each one with some kind off suffix, such as printString(), printInteger(), printMyObject(), however there is a much neater way of doing this, called overloading.
If statements are great, but sometimes they are just not very practical when you have to test for more than a handful of conditions, have a look at this very poor example of how you build up a long set of if-else statements, its fine for a few checks, but if you’re doing multiple equality checks on a value, its best to use a switch statement for flexibility and readability:
I’ve recently put together a few proof of concept applications, and since they’re “rough and ready” applications, a lot of the functionality is actually mocked, or given a stubbed implementation.
For example, I’ve got various buttons for things like “sign in with LinkedIn” or “Connect with Facebook”. Since its just a proof of concept, and those features aren’t really must haves, I stub them with a Toast message saying something along the lines of “feature not yet implemented”.
This gives the user the opinion that the buttons are there, functional, however the actions they take are not yet implemented.