A post at another blog describes three ways to attach click listeners (for elements such as buttons in Android applications). The first, the “Old Java [Object Oriented] Way”, way retrieves the object (ie, Button), and sets the onClickListener by creating an anonymous object which is passed to the button object. As he points out, this can be expensive in terms of memory, and can make for sloppy code.
The second way, The Shared Listener, uses a shared onClickListener object among all the [button] objects. A switch statement is used within the listener to determine which [button] object was hit and act accordingly. This still has the disadvantage of needing to retrieve the Button objects and attach the listener to each.
The third (and preferred way), the Declarative Approach, makes use of a method in the Activity to act as a shared listener and attaching that method in the XML via the “android:onClick” attribute. This relieves the burden of grabbing all your buttons in code and assinging them the listener method.
The added benifit of NOT using the first approach, as mentioned in the linked blog post, is a reduction of package size and a reduction in source bloat. To test how much memory was saved, a skeleton application was created. It consisted of five buttons linking to different activities (the fifth button was actually the quit button). When coded the first way, that is grabbing the button objects and assigning an anonymous object, the package size was about 17.8 Kb. When coded the third way, that is using the shared method and “android:onClick” attribute, the package size was 17.0 Kb.
Thats an overall savings of about 40 lines of code and 0.8 Kb (~4.5%) of package size for the above example.
Many guides exist for setting up a subversion server using WebDAV through HTTPS (on Apache on Ubuntu), such as this one (which also includes other access methods of your subversion repositories):
After installing the plugins, it was time to copy over a repository from an existing machine (such as an old Windows XP computer) to the new location (such as an Ubuntu box). Using the svnadmin command, dump the existing repo and put the output to a file. It is important to note that if the output gets dumped to the terminal, all sorts of human and non human characters will be written to the terminal. If you have an internal speaker, some of those nonhuman characters will cause it to beep loudly and often for a long time.
The command for the svn dump looks like this:
svnadmin dump _PATH_TO_YOUR_REPO > _DUMP_FILE_
svnadmin dump C:\repo\myProject > myProject.dump
As each revision is dumped, it is reported to the screen.
Copy this file to the new machine (or somewhere as accessable) and load it to the empty repository. Don’t forget that to load into a repository, you will need to have created one using the “svnadmin create” command.
“svnadmin load” takes input from stdin, so cat that dump file and pipe it in. This looks like:
cat _DUMP_FILE_ | svnadmin load _PATH_TO_NEW_REPO_
cat /tmp/myProject.dump | svnadmin load /svn/repos/myProject
If all goes well, you’re repository should now be loaded, and accessable on that machine.
1. Don’t set the DocumentRoot of the HTTPS virtual server to be the same as your repo. Anyone will be able to then see your repo (even if you have “Require valid-user”)
2. Make sure the “Listen 443″ is really “Listen 443 https” in ports.conf (or where the Listen directives are). If that is not set, you may see an error.