Archives for : April2011

Cloud Sync and Backup

The other day I learnt, for the second time, the important lesson of backups. My second, and this time primary, hard drive failed. It’s the second Seagate one that I have had fail (funnily enough, it was 28th of April 2009 that I filled out the paper work to return the last one that failed, so exactly 2 years later I fill out the paper work for this one,) which is actually a bit of a shock since I was under the impression from reviews I had read online that Seagate were probably one of the best. Though, they do have their 5 year warranty, so you can’t fault them with that.

This time I was prepared. I actually happened to have a second hard drive inside the computer with Windows already installed, I just left it unplugged. Plug it in, and away I go straight away. When I get the replacement HDD from Seagate, I’ll image my current Windows installation (which is fairly new) onto it, and keep it as a backup.

As for data, I have learnt to keep everything that I need in Dropbox, or some other online storage place. This is the second time Dropbox has saved me. Whilst it’s inconvenient having to re-install all the programs I normally use, and setup all my preferences, and possibly lose replaceable files, all my important data was in Dropbox, and it has now synced back with my desktop (via LAN Sync from my Desktop: no need to wait or waste Internet bandwidth.)

So, I’m seriously considering purchasing a yearly Dropbox plan (even though I just increased my free limit to 5GB,) but I’m looking at some alternatives to Dropbox first, partly to get better storage, or better priced plans. Sugarsync I have heard is almost on par with Dropbox (without using it, the only reason I can think of that Dropbox may be better is that I’ve used Dropbox for 2 years, and you grow some form of attachment after that long,) and whilst it’s $99/year plan only has 10GB more than the $99/year plan from Dropbox, they have a $49/year plan for 30GB, which is $50 cheaper than Dropbox’s cheapest (the cheapest from Dropbox is $99, and I don’t think I’m likely to need 50GB, 30GB seems as though it’d be enough for me for now.)

So, the main differences that would affect me are: Dropbox has LAN Sync, but that I only really need when I do a full restore, and it isn’t essential, and Sugarsync has file revision for the last 5 revisions included, whereas Dropbox has unlimited revisions for an extra $40 a month.

Has anyone had any experience with both Sugarsync and Dropbox? Is it worth ditching Dropbox just for a cheaper plan? Unfortunately these days it isn’t just raw numbers that count, it’s the unique service that each company provides, and Dropbox is really good.

… but that doesn’t mean it’s a bad choice to use Java

This post is in response to It *never* made sense to learn Java.

When I was reading the blog post about how learning Java generally isn’t a good idea, I tried to think back to when I actually did learn Java. What did I come out with? I don’t think I really ever did learn Java. When I was 14 I think I may have tried to read though a Java book, but I didn’t really learn anything from it. What have I actually learnt? Probably, C++ the most, as it’s what my university primarily teaches (and for Computer Science students, I think it’s one of the best choices, provided C get’s mixed in there as well, which for me it does.) That said, I still program in Java, and here I’m going to explain why.

The main thing that really caused me program in Java is Android development. There really isn’t any good alternative for the majority of app’s (You can use C++, but you loose all the API’s, and for most app’s it’s not required, then there’s MonoDroid, but that’s still in beta, and C# and Java are quite similar.) So I never really learnt per say, I just hacked together small code snippets that I found online using the concepts that I learnt at school, university and personal study. So I did learn it, just after I started to use it, as I already know all the OO concepts from learning C++. Secondly, I already knew C#, and as I mentioned before, the syntax is very similar.

Better Library Support
So, why did I choose Java for my most recent, non-Android software project? The biggest factor was library support. In genera, I find that Java libraries are less fragmented and better supported than C++ libraries that I found. For the project I was working on, I needed a Microsoft Office API and a email API. For Java, there’s Apache POI and JavaMail. The first one is supported by Apache, meaning that it has quite a lot of support, the second one’s developed by Sun/Oracle, so it also has a lot of support. I quickly did a search for C++ libraries, and was disappointed with the results for Office APIs (Visual C++ doesn’t count, sorry,) and the email library looked decent, but wasn’t backed by a big company.

Better Cross-Platform Reliability
C++ can be compiled cross-platform in most cases, but it’s definitely not as easy to deploy cross-platform programs with C++ than it is with Java. Java, unless using specific OS APIs, will work cross platform. C++ should work cross platform, but I’d put more trust in Java to work straight out cross-platform than I would with C++.

As already mentioned when it comes to library support, C++ to me does seem a little fragmented. Java seems more centralized and organised, as well as having larger backing (Oracle, which is probably why it (and C# backed by Microsoft) appeals to enterprise users a lot. Knowing that there is a big central company backing a language is quite important for many application developers.

Also, along side backing is jobs: a quick search in Australia on Seek pulls up 4350 jobs for the keyword “Java,” and only 651 for “C++.”

Speed isn’t everything
Computers these day’s are fast. Java is slow, that I am not disputing. But computer’s are fast, definitely fast enough such that there wouldn’t be any noticeable difference to the average user that of a Java application and a C++ application. That means that it’s more or less up to the points above if speed isn’t an important factor. That of course isn’t to say that speed is never an important factor, it most definitely is for certain types of programs, in which case I would compromise and choose C++ over Java.

Where Java doesn’t cut it
The original blog post linked to above mentions systems programming, and how Java most definitely isn’t suited to systems programming. The first thing I thought was, who would have ever thought that it was? I would never use Java for systems programming, and I’d even have reservations for using C++ (C is the best language for systems programming.) Java isn’t designed to be used for systems programming, so I don’t even see how that would ever be an issue. Just because a language can’t be used for systems programming doesn’t mean it shouldn’t be used for application programming.

I’d definitely suggest for people learning Computer Science to learn C++: from the concepts you learn in C++, you’ll be able to pickup on Java with minimal effort, whilst having a greater understanding of lower level concepts such as pointers, and knowing how to program well (I suspect C++ isn’t as tolerant as Java, so you’re more likely to learn to program “better” in C++, but this will flow over to other languages). Learning C++ as a first language doesn’t mean you shouldn’t ever use Java. Java and C++ both have their place, there’s a reason we have different languages, as different languages suite different needs (though we probably do have too many.)

Android: Using startActivityForResult()

Sometimes in Android, we want to be able to start an activity, but then return back to the activity that called it, and send a message (in the form of an integer in this case) along with it. This is what startActivityForResult() allows us to do.

Before I explain how to use it, let me explain the situation that I was trying to achieve. I’ll start with the diagram below.
Now, the idea behind this is: an Activity Main starts as soon as the program starts. It doesn’t have any layout associated with it. Then, based on a few conditions, it launches one of two Activities with layouts (in this case “Login” or “Details” Activity, but the names are completely irrelevant.) Of course, you want to be able to get to from one screen to the other (e.g. you login, or logout.)

Of course, I could have started with the login screen straight away, and if a condition states that I’m already logged in, launch the details screen straight away without doing anything, but personally I think this way is more versatile. At the moment the other way would work, but this I think gives more control over how your application behaves (though that could indeed be a bad thing.)
So, what did I have in my Let’s have a look:
private void launchUserInterface()
SharedPreferences settings = getSharedPreferences(PREFERENCE_FILENAME, MODE_PRIVATE);
Intent i;
if (settings.getBoolean(“LOGGEDIN”, false) == false)
       i = new Intent(this,Login.class);      
       i = new Intent(this, Display.class);      
startActivityForResult(i, 0);
If you’re not sure what’s going on with the preferences, Google around for a tutorial on preferences. Basically, PREFERENCE_FILENAME is a constant I have defined, and MODE_PRIVATE is a constant that was defined for use with SharedPreferences.
This is pretty straight forward: if the user is logged in, it will proceed to launch Display.class, if not, it will display Login.class to prompt them to login. The above class is called in the onCreate function of Main.
Now, you are hopefully familiar with the way Intents work (if not, you probably should be reading this tutorial,) the interesting thing comes with startActivityForResult(). It’s not really that much different to the standard startActivity(), but it allows for the activity thats being launched to set an integer result. So, first you pass your intent, and an integer that identifies the call (not covered in this tutorial, so set to 0).
In your activity (either Login or Display,) you will at some stage want to go back to the main activity. To do this, just do the following:
public void onClick(View arg0) {
Or something to that effect. You can set your integer result, and then call finish(). finish(), if called within an activity, should automatically kill that activity and return back to the previous one.
In your Main.class, you want something like this to catch the result:
    protected void onActivityResult(int pRequestCode, int resultCode, Intent data)
if (resultCode == -1)
So, as soon as an activity that was called from Main.class with startActivityForResult() is finished(), this function will be called and you can do whatever you please. For example, every time that an activity finishes, I called launchUserInterface() again, which will re-launch the user interface based on whether you’re logged in or not. The idea being, when someone logs in, the activity stores it in the preferences and closes the activity. Main then runs launchUserInterface() which will launch the Display activity instead, since you’re now logged in.
Now, there is a downside to using this method: the more control over it you have, the more you need to take into consideration. The problem here is, when you press the “Back” button, you’re finishing the Activity. So, if you’re in the Login or Display screen and press the back button, you’re pretty much doing the same thing as calling finish(). This is bad, because when it get’s back to main, it will run the onActivityResult() and re-launch the activity. So pressing back will close and re-launch the activity.
In the above code, you will notice that there’s a condition that if resultCode == -1, then it will finish() the current activity rather than launch the user interface again. This is the one place I used the resultCode.
In both Login and Display, I did something like the following:
public void onBackPressed()
// Return to main and close activity.
return ;
This takes control of what happens when the back button is pressed. If you override onBackPressed() and didn’t put anything in it, then pressing the back button when that activity is present will do nothing. So, what I have done here is fairly straight forward: setResult to -1, so when it gets back to onActivityResult(), it will then proceed to finish() the main activity, instead of re-launching the interface. This is the expected result in this scenario, as it will take you back to the home screen (in most cases.)
So, there’s a quick introduction to using onActivityForResult(). There is so much more that can be done with it, for example, using the contact picker. Read more in the Android Developer site to further your understanding of onActivityForResult().

Update: Using this method can create problems later on. I came across it, but did manage to fix it. Check out this Stack Overflow question (and the accepted solution) for what you should do in addition to this.