Is GIT Really better than Subversion?

In short, for new projects, yes, otherwise no. Here’s why

Lately the tech world, a good amount of buzz has been on the new versioning software called GIT and how its much so better than SVN and (CVS) that you should switch as fast as you can or you will be left in the dust. I'm not so sure that's the case. It would certainly be hard to argue that GIT isn't a better design then SVN, but is it really so much better than you should spend tons of time moving all of your SVN Repositories over to GIT immediately? I'm not so sure. With that in mind, I spent some time to write down what I think are the major benefits of GIT over SVN cam be simplified into two main points.

Benefits of GIT

1. Distributed System – Strength in Numbers

Every single person that is working on your project has a full copy of the version tree. So in order to completely lose the project repository, every developer’s machine has to lose their GIT files.

2. Faster Commit times

Since you have the entire repository on your own machine, “committing” back to it is much much quicker. GIT is also more efficient in terms of storage than SVN, allowing a smaller amount of data required to be transferred back and fourth.

So really, if when using SVN and your having problems with the time required to push and pull your projects, or your SVN server may not be properly backed up, it may be a good idea to switch. If SVN doesn’t cause you a ton of grief now and does what you want it to do, maybe now isn’t the time to switch over. For future projects, using GIT may certainly be the right move.

What do you think? Is GIT truly worth the move?

Android versus iOS Part 2

 

Note: This post is in the perspective of an Android developer first learning iOS. Check out Part 1 for more info.

Everything on iOS isn’t necessarily the best. Android has several big things going for it from a developer’s perspective. Even though I can certainly see the power behind iOS, I still find myself enjoying developing for Android more.

iOS gets harder once you get past the basics

Properly handling memory within your application can be pretty tricky. It’s very easy to overlook a release call here and there, only to have it come back to haunt you later (I know this has been updated with iOS 5, but it still isn’t bullet proof).

UI Design is more restricted

Part of the reason why UI Design is easier on iOS is because Apple takes away most of your options. While developing for Android, I don’t have to worry if Google likes how I implement my buttons, or how I expect the user to navigate around my application. However, on iOS, it’s very common to worry about Apple’s restrictions and UI Guidelines while designing your application.

iOS is less forgiving; It’s easier to shoot yourself in the foot

It’s much easier to fall into an unworkable architecture in iOS than it is in Android. For example (which I’m sure is a newbie mistake, but bare with me), there is a good amount of pitfalls when attempting to put a Tab Controller inside a Navigation Controller. If your pieces are set up just right, it can be very difficult to assure all of your controllers are receiving the callbacks that you are expecting them to receive.

Android documentation > iOS documentation

One of the most difficult parts of picking up iOS from an Android perspective is that the documentation isn’t quite as good as Android’s. A quick search in Google with something like “Android Intent Service Example” will leave you plenty of information about the Intent Service and a few examples of how it could be used. This kind of information isn’t as easy to locate for iOS.

With that being said, I still plan on continuing development for iOS. I plan to release my first application within the next month or so (RB Recorder). And once my first app is out, I’m certainly going to continue down the iOS road. Maybe my opinions will change with more experience with the platform. But for now…

Android > iOS

What do you think the pros and cons are for developing on iOS versus Android?

Cleaning up your Android Apps

After months of adding new code and resources to a project, its very likely that some of the added resources aren’t being used right now and are taking up space in your project. Going through your project file by file looking for unused drawables or unused entries in Strings.xml.

Like most things in the software world, there’s an easier way (or several actually). You can run your project through this jar. Android-unused-resources is a project that analyzes your Android project folder, and spits out a list of files and XML resources that aren’t currently being used. It makes it very easy to go through and delete what’s not necessary in your project.

After I ran across this nice project. An Android Eclipse plugin update included Lint, which does much of what Android-unused-resources project does, in addition to checking for more interesting performance optimizations like changing values in your layout XML files.

If you have some time and are wanting to clean up your projects a bit, you should check Lint, and the Android-unused-resources project out.