Android EditText setFocusable(true) does not work if you remove focus

I came across this weird issue where the EditText view, once focus was removed, would not allow you to type even if you set it to focusable again. I was basically doing this:

editTextField.setFocusable(someCondition);

The problem was though that the view would get focus again, but you couldn’t type anything. I googled around for a bit and noticed this was an issue that had been previously reported, but hadn’t been fixed yet. There is a way around it however, you just have to do:

if (someCondition)
   editTextField.setFocusable(false);
else
   editTextField.setFocusableInTouchMode(true);

Setting it true in setFocusableInTouchMode() seems to do the trick, at least until it is fixed.

CAA – Canadian Automobile Association application release

I meant to post an update about this, but for some reason it completely slipped my mind. On Nov. 17, the CAA application (my very first mobile application I got to work on!) was approved by CAA and all the app stores, so it is now available for public download!

You can get the different platform versions:

• iPhone
• Android (OS 2.1 and greater)
• BlackBerry (OS 5.0 and greater)

I hope you get to test it out if you get a chance! I think trying to write about all the different things I learned during this project would be at least a 20 page essay, so I’ll try to highlight the key points:

• It is extremely important to anticipate and think about areas of change in your code. Code will have to be written to be as easily modifiable as possible. This means low coupling, high cohesion, minimal hard coding, using OO paradigms (Android and BlackBerry use Java, iPhone uses Objective-C), and being ready for change. You will get changes to the requirements, it is possible some things may not be possible, and although these requirements should all be determined at the beginning of the project, that is a perfect world situation that I have yet to experience.
• Meetings are good, but too many meetings, or overly long meetings are terrible. Having a quick meeting to update and sync up with the status of the project and any issues on a daily or weekly basis is great. However, if these meetings drag on too long, then it’s pretty much a waste of time.
• Design patterns are awesome. Use them. People have been developing for a long time, so use the plans they have laid out!
• Testing is incredibly important. And there are many, many kinds of testing. They are all important. It’s better to catch all your bugs before things go into production because user feedback about how to duplicate a bug is not often helpful. Try to set it up so that if your application crashes it can email you the crash log, which is infinitely more useful than a user description.
• User experience can make or break an application. I can write an extremely difficult application which took years to develop and can do everything from tell you the time to drive your car, but if you can’t figure out how to use it, it’s worthless. Applications that are simple to program, but easy to use, are what make it to the top of the app store lists. Make sure you get a designer to help you out with it, and do some user experience testing as well.
• Meet all your deadlines, but don’t freak out about your deadlines. In the beginning I would worry, fret, panic, and have multiple heart attacks on delivery days. All very useless. Work on it consistently and make sure you do all your testing at least a day before the delivery date. When you change how something work 2 minutes before a release is supposed to go out, you should go through all your tests again. Just because it works for the one case doesn’t mean it works for everything!
• BugZilla (or a bug tracking software) is only useful if you know how to use it. We were using BugZilla to keep track of all of our incoming bugs, closed bugs, and just generally keeping track of things through it, but I could not for the life of me figure out how to use it. I had to go through an incredibly painful process where I set up email notification for every bug opened, and then I would save all those emails, and when the time came, open up every single email to try to figure out which bugs were open, closed, in progress, or not bugs anymore. (I really wish they would upgrade their system … it’s still so hard to use!). Eventually I kind of figured out how to use it for my project and my bugs, and it became easier.
• Whether you choose to use Git, SVN, Mercurial, make sure you fully understand how to use it. There are benefits and drawbacks to each, make sure you know how to use your chosen repository system’s features.

I think the last two points can essentially be summarized to: know how to use the tools you’re developing with. I think that’s a long enough list, however. I hope that’s useful to someone if they ever come across it!

And if you can, download the app and tell me how it goes for you! Let me know if I can make it better for you, and how :).

LadiesLearningCode: WordPress

I had the opportunity to volunteer at a LadiesLearningCode (LLC) event, where the topic of discussion was WordPress.

I was basically a mentor helping out, so I attended a session where we went over the content of the day, tried to figure out the content we should talk about, then tried to achieve a good balance between theory/practical experience to get the learners get some experience. The workshop was open to men as well as women, and is a nonprofit organization which puts on a series of workshops for people interested in learning how to code, with a target towards women. I believe the point of it is that since there are so few women, it’s nice to meet others in the field so you don’t feel as alone!

Someone eventually linked the event to HackerNews, where the had a discussion about whether or not it is actually useful or pretty pointless. When I first started school, I used to ask this question a lot, mostly despairingly because I didn’t understand why my life had gone from equal amounts of girl friends and guy friends to practically no girl friends at all. Eventually, I moved past it and got over it, it doesn’t really make a difference to me now. I still think it would be nice to meet more females in the tech field, as it would be easy to relate to them, but it’s not a huge issue for me anymore.

The event itself was great, it started at 8:30am and went on until about 5:30-6pm. We set up a server to run on everyone’s machine (interestingly enough, of the 85-90 people that were learners, everyone except for 2-3 people were on Macs, not Windows), installed a WordPress site, customized it, played around with some php, went through some nitty gritty WordPress details, and made some basic and complicated changes that most people like for their websites. It was very interesting, and I even learned a few things myself that day :) (a big one would be how to use Mac machines…). Breakfast (thank you for this!!), lunch, snacks, and drinks were provided and much fun was had.

I had a great time at the event and it really encouraged me to get more involved in the tech community and tech scene in Toronto, which I was previously unaware of. SF might be where everyone thinks all the innovation happens, but there is some serious talent and skill in Toronto as well!

The Importance of Project Plans and Communication

Before starting work I never really understood the importance of project planning. I had worked in large groups before to create a program, modify an existing software, complete assignments. I also enrolled in two courses which dealt with project management – we had to create project plans, created burn down charts, estimated effort and time, analyzed different strategies for finishing a problem, and created COPIOUS amounts of UML diagrams (class, use case, sequence, activity, etc). In a classroom environment however, even though we worked on real life projects (open source and for the TDSB), I still never truly understood the importance.

However, after a short period of time at work, I saw the usefulness of planning immediately. It becomes very obvious when you have payments and expectations from a customer who knows pretty much nothing about programming and software development. In my case, a mobile application, can be split into many phases. We have a very large stack of things to do, and the customer only has one date: the release date. Everything else must be planned backwards. You can’t just take into time the development period for the programmer, but testing time, time to understand the many, many documents the customer will release outlining their expectations, and meetings. One thing that really stuck out for me is the huge number of documents you have to wade through to understand what the customer wants, their API, and so on. I really wish there was some standardized way of presenting this information on a wiki page or something, so you don’t have to go through six or seven different word documents trying to find the customers specifications or an API call.

I digress. Planning becomes extremely important when your deadlines are tied to payments. When you realize that yes, your employees can come in during the weekend to work, and they can stay late, but how often are you going to do this? Repeatedly doing this will make your employees unhappy, can potentially make them sick, and how will they produce good quality work if they are exhausted and unhappy? You need clearly defined deadlines, with clear expectations. In short, a plan will come in very handy.

I also saw evidence of this in my summer side project group. We were a group of friends who decided on a project we wanted to work on, and then split up the tasks among ourselves. It fell apart, very quickly. Some people’s tasks relied on someone else to complete their task first, so until the first person finished they were assigned “research”.

Strike 1 – No clearly defined goals or expectations. Just a general task for one person (e.g. sound), with no expectation.

We also decided that because we all had our own schedules (most of us are on a co-op work term, while the others take summer school / work part time), we wouldn’t set any deadlines or dates, just see how things went. We also didn’t want it to seem too much like school, because we were worried about it becoming too much like an assignment rather than something we were interested in.

Strike 2 – No clearly defined dates. What is there to work towards?

As well, because we split up the tasks, when one person finished their part and we had to integrate our work, it took time. We never created any sort of diagram or laid out too many specifications, and thus, time was spent on learning how code was structured so that we could integrate our own sections.

Strike 3 – No sort of software specifications.

The three major strikes above caused us to spend a lot of unnecessary and extra time, and hindered our progress greatly. I feel that due to the lack of structure and tasks, some people dropped out of the project (also because some people really did not have the time to devote to the project). We did not count the effort and time that would be required, at all.

The last thing that is essential for a project to go well is COMMUNICATION. Daily communication between developers at least, is very  important in my opinion, and in person face-to-face communication is always better than email. Even skype communication (video chat) is better than email! It is very easy to misinterpret something, and if you have a different understanding of something, it is easy to explain and catch in person if you ask them to explain it to you. However, if it is through an email … and the person will read it in six hours and then work for 8 hours and then email you a status update which you will read after another six hours … if there is miscommunication or misunderstanding, then the mistake or misunderstanding has already been incorporated into the code. It’s too late.

In summary, there are, in my opinion, a few things that can make or break a project (with regards to project planning and communication):

1. Clearly defined goals/expectations. What EXACTLY do you want to accomplish?
2. Dates. Set dates for team project reviews, and then release dates for the customer.
3. Software Specifications – related to #1, but more in detail. Outline what the customer wants, whereas #1 is more for what the developer needs to do.
4. Communication. Good communication is crucial.

I hope that was helpful!

Easy Redundancy Fix

A really common mistake (or redundancy issue) I see often is the following:

if (someCondition) {
     //some code
     return something;
} else {
     return somethingElse;
}

A return statement steps out of the method and returns to the point where it originated. Thus, if the first condition is met, it will exit the method and not execute any other statement. Then you simply have to do:

if (condition) {
    //execute some code
    return something;
}
return somethingElse;

To be even better, if you are doing something like:

if (cond) {
   return true;
} else {
   return false;
}

Notice that if the condition is true, you return true. If it is false, you return false. You may as well return the conditional statement! So:

return(cond);

It’s really simple and very obvious, but it’s just something I see quite often.

And one I missed but pointed out by Gooble in the comments:

(booleanExpression ? trueResult : elseResult)

An if/else kind of statement, but as a one line operation! Also useful when you’re just assigning variables a value based on some condition, or returning something.

Hope that was helpful!

Commit Early, Commit Often

One of the most important lessons I’ve probably learned over this past week is the mantra that should be drilled into every programmer’s head and then explained:

Commit Early, Commit Often

Even though I’ve been told and heard in the past numerous times that to commit early and commit often is a good thing, I didn’t do a very good job of it in practice. For some reason, I didn’t want to commit anything until I had completed a large portion of code, or a new feature, or fixed not one or two, but many bugs. I basically wanted to build a program / project with as few commits as possible.

I talk about this with respect to version control systems, I think they’re incredibly useful and once you start using them, you’ll never go back to life without them.

Reasons why I thought this was good: 

• If I commit now, it might cause conflicts with the other person working on this as well, which will be problematic. I don’t want to screw up my code by updating, so I’ll just finish up a lot and make it work.

BAD: This actually doesn’t make a lot of sense. I wasn’t even able to convince myself of this. There will be conflicts if more than one person is working on the same function in the code or same area. There will be MORE if you commit after a long period of time. If you commit early and commit often, small conflicts will be easy to change and fix as opposed to a huge one.

• I don’t want to look like a bad programmer by submitting things that might not be complete or really neat … I’ll just fix it up later and then commit.

BAD: This is terrible! The only way you can improve is by practicing, and by receiving critique. If you let no one look at your code for fear of judgement and being thought of as inferior, how will you improve? Secondly, just try to learn as much as possible!

• I will commit after I have completed feature x or y, or after I have fixed bugs x, y, z, and q.

BAD: Commit early and commit often! This is in direct violation of that rule! If you wait until you have a big feature or a lot of bugs fixed, it can cause problems! You might lose your data, your files can get corrupted (all worst case scenario things of course, but Murphy’s always waiting to strike!) and then you’ll lose everything you worked for. Commit early and commit often.

• I don’t want to break the build.

GOOD/BAD: It’s excellent to not want to break the build, it’s not good to refuse to commit for large periods of time. Better to test your code out (I’ve heard in Microsoft they test on three different machines with a variety of tests before they add the code to the build).

Reasons that you should always, always always commit early and commit often:

• Your code is not you. Receive feedback, critiques, improve code, do not make same mistake again. Life’s all about that, isn’t it?
• If someone catches a mistake you’re making early on (or even you do), then it’s super easy to rectify in the beginning, as opposed to later in the game. Then it gets 10x harder. I believe there’s a law for this that goes something like:

The amount of effort/difficulty to fix a bug that is found increases 10x for each stage that it is missed in (the stages being requirements, design, implementation, verification, production, and then maintenance).

• If something corrupts, you have a revision that was working pretty close to the one you have right now!
• If you haven’t committed and someone else commits code and then your code breaks after they commit, you can’t really argue their code is the reason for this. It can possibly  be the reason, and it is also possible that there was something in your code that is wrong.
• If you make a really stupid delete file or overwrite file mistake, retrieving it is not difficult at all!

That’s all I can think of at the moment, but I hope I’ve convinced or argued enough to help anyone reading this to remember to COMMIT EARLY, COMMIT OFTEN!  I learned this the hard way, hopefully my example will be enough to save others!

Android: layout_gravity vs. gravity & wrap_content vs. fill_parent

When creating the user interface in Android, you can choose to use the interface builder that is provided (for Eclipse) or you can edit the XML files. I usually prefer editing the XML files because dragging around the different elements on the canvas and scrolling through the properties of each object gets tedious. If you edit the XML file you can also pretty much copy paste in elements of code that are repeated from screen to screen.

In the beginning, I often made a mistake regarding two major topics: content fill, and alignment. For content fill there are two important properties you need to know: wrap_content and fill_parent. For alignment you need to know the difference between the layout_gravity and gravity attributes.

layout_gravity vs. gravity

layout_gravity sets the gravity (alignment) of the View or Layout inside its parent. If you have a text view inside a linear layout, then setting the layout_gravity of the text view will alter its alignment in the layout. gravity sets the alignment of the content of the view or layout it is applied on. If you want your text (in the text view) to be left aligned, center, or right aligned, then modify the gravity attribute of the text view.

layout_gravity and gravity have the following options:

• for gravity and layout_gravity : here 

Here’s an example of what I’m saying:

<!-- Modifying <span class="hiddenGrammarError" pre="Modifying ">the gravity of</span> text to be center aligned, and for the text view to be center aligned (both horizontally and vertically) in the layout -->
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:background="@drawable/background"
    android:layout_width="fill_parent"
    android:orientation="vertical"
    android:layout_height="fill_parent"
    android:id="@+id/linearLayout">
    <TextView
        android:text="Current Location"
        android:layout_gravity="center_vertical|center_horizontal"
        android:id="@+id/textView"
        android:layout_width="wrap_content"><!--<span class="hiddenSpellError" pre=""-->TextView>
<!--<span class="hiddenSpellError" pre=""-->LinearLayout>

Note how for layout_gravity you can set for it to be aligned both horizontally and vertically by OR’ing the bits together. You could also replace “center_vertical|center_horizontal” with “center” and it would work as well. Important to note that it doesn’t work if you do “center_vertical | center_horizontal”, so spaces do matter.

Pictures will be added soon to give a visual explanation of what I’m saying.

wrap_content vs. fill_parent

The difference between wrap_content and fill_parent are both attributes which can modify the width and height of a view or layout. The fill_parent attribute sets the view/layout to take expand (either in width or height, depending on which it has been applied to) to take up all the space in the parent layout in which it is placed. If you set the width or height of a view/layout to wrap_content, it will only expand as much as its children.

If you have a text view inside a linear layout with the text attribute “Hello World”, if the width of the text view was set to fill_parent, it would expand to take up all the space (width wise) in the linear layout. If the width was set to wrap_content however, the width of the text view would only be the width required for the text “Hello World”.

<!-- Setting width and height to "fill_parent" of layout and "wrap_content" for child -->
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:background="@drawable/background"
    android:layout_width="fill_parent"
    android:orientation="vertical"
    android:layout_height="fill_parent"
    android:id="@+id/linearLayout">
       <TextView
            android:id="@+id/textView"
            android:text="Hello World"
            android:layout_width="wrap_content"></TextView>
</LinearLayout>

<!-- This will basically cause the root layout (linear layout) to take up <span class="hiddenSuggestion" pre="up ">the whole</span> screen, and the text view to expand only to the width of the text "Hello World" -->

Pictures will be added soon to give a visual example of what I’m saying.

I hope that was helpful, and clear enough to understand.

“IE vs Every Other Browser On the Planet”

I go on many different websites when I’m sitting on a computer reading the news, trying to research something, or looking for an elegant solution. Occasionally, I stumble upon a website that has some really great features or looks really attractive. When this happens, I spend some time looking at the page source, to see what they’re doing and how they’re doing it. While looking at one websites javascript files, I came across this gem of a function:

function getNewHTTPObject() {
       var xmlhttp;
/** Special IE only code ... */
       /*@cc_on
          @if (@_jscript_version >= 5)
              try {
                  xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
              } catch (e) {
                  try {
                      xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
                  } catch (E) {
                      xmlhttp = false;
                  }
             }
          @else
             xmlhttp = false;
        @end @*/

/** Every other browser on the planet */
if (!xmlhttp && typeof XMLHttpRequest != 'undefined') {
            try {
                xmlhttp = new XMLHttpRequest();
            } catch (e) {
                xmlhttp = false;
            }
        }
        return xmlhttp;
}

The amusing part is in the comments (I’ve bolded to make it more clear). Just highlighting the inconsistency in IE as opposed to other browsers. I remember coding a “Towers of Hanoi” web application, which worked for almost all browsers except for IE. I’ve seen CSS and HTML that has to be fixed especially for IE.

They really should make an effort to standardize themselves. It doesn’t necessarily make them better because they’re different in this case. It just makes life harder for web programmers.

Setting up your environment for BlackBerry development

The first thing I tried to do after I started work was to get the same environment set up at home. I ran into some problems, but they were all eventually resolved. I’ll start by listing the steps involved (it’s really easy actually) to get it setup, and then talk a bit about why it is like this and the history.

To get it set up:

1. You will need Eclipse. Download the most recent version of Eclipse (I believe any of them will work, although I have only tested it with Helios and Ganymede). You can download from here:  www.eclipse.org/downloads/. I used the classic version of Eclipse, not JEE, to allow for Java development as well with Eclipse.
2. You will also need the latest JDK (1.6 at the moment). Download that here: www.oracle.com/technetwork/java/javase/downloads/index.html.
3. You will need 32 bit Windows. You can work around it if you have 64 bit but it is a little trickier (see Problems section below).
4. Next, download and run the JDE (BlackBerry Eclipse plugin). You can get that here:  http://us.blackberry.com/developers/javaappdev/javaplugin.jsp. Scroll down to the “Download” button with the two green arrows (it is about ~400 MB).
5. Once that is done, go to Eclipse and Help > Install new software. Type in this url: www.blackberry.com/go/eclipseUpdate/3.6/java and hit Enter. A list will appear of the JDK you need to install, click the check box beside each and install. This installs the simulators.  For older simulators and JRE for 4.x and 5.0, repeat this step with this url: http://www.blackberry.com/go/eclipseUpdate/3.5/java.
6. In your Environment Variables, set JAVA_HOME to the 1.6 JDK you installed in the second step. To find the Environment Variables, go to My Computer, right click Properties. Under the Advanced tab, click Environment Variables. You can edit or add new ones.
7.  The last thing you’ll have to do is go to Windows > Preferences > Java Compiler, and set the compiler compliance level to 1.4.

That should get you set up to do some blackberry development! Have fun.

Problems

If you have a 64 bit machine, you will need to get 32 bit JDK and Eclipse if needed. This is because RIM only has the JDE available for 32 bit, as the Flash component they use only works for 32 bit machines. For 64 bit machines, you have to find a work around. You have to do the following:

1. Download Eclipse (step 1 above has the link).
2. Download the 32 bit JDK (step 2 above has the link).
3. Download the JDE for Eclipse (step 4 above).
4. Set your PATH (JAVA_HOME) variable to your JDK file location (step 6 above).
5. Next, go to the Eclipse folder (where it was installed), right click the eclipse.exe file and under the Compatibility tab, check Run this program in compatibility mode for  and select Windows XP (Service Pack 3). Also check the Run this program as an administrator check box, then click OK.
6. Next, go to the Eclipse installed folder, right click and select Properties>Security, and then the Edit button. Add the user that will be doing the development, then give that user Full Control by checking their name in the Allow section.
7. If you want to import projects that worked on a 32 bit machine: File >Import >Import Legacy BlackBerry projects.
8. The last thing you’ll have to do is go to Windows > Preferences > Java Compiler, and set the compiler compliance level to 1.4.

Signing

If you want to deploy your application, you will have to sign it, which means you will have to sign up and make a developer account with RIM, and then download their signature tool. It will provide a username/password combo which you can use to sign your application!

History

To give you a short, brief history, RIM initially had their own development environment (JDE – java development environment) for programming blackberry applications. It became terrible for developing applications that were large (a rough estimate would be greater than ~100 files), and it soon became obsolete. Currently, they work with the Eclipse plugin only. So if you see anyone telling you to only install the JDE, it’s an old post, when the JDE used to be the only way to develop for it. Now it’s simply a plugin for Eclipse.

I hope that was useful for you!

A PEY Placement

The University of Toronto’s Computer Science Department offers a unique internship experience: the PEY experience, short for Professional Experience Year. This program is a minimum 12 month, maximum 16 month internship, and a 40 hours / week commitment. This also means that you will graduate one year later than you were supposed to, and that in total, it will take you 5 years to get your degree, not 4.

As well, this experience is probably the best real world experience you can have before graduating and looking for full time work. Going to a prestigious school with a renowned department helps, but it does not guarantee anything. Employers are looking for talent, a willingness to work hard, and the ability to learn.

Before I applied to any jobs, I laid out a list of requirements I wanted in an ideal job:

• Extensive software engineering experience
• Preferably the option to play different roles on a team
• One which I could learn a lot from
• A project / concept the company was working on which excited me
• Preferably a manager who wouldn’t yell at me all the time or had a short temper
• A placement where communication was important to the team
• Preferably close to home, so a small commute time (I commute ~1.5 hours at least for school one way daily)

Perhaps I had more requirements than some of my peers, whom I heard say once or twice wanted a job that gave them good money, and that was it. I understand the importance of money, and do not advocate necessarily selling out your services for free all the time, as you need to make an earning for yourself. I do not feel however, that money should be your only consideration for a PEY position. I was not financially strapped however, to let money be my only deciding factor, although I agree it is important. I do point however, to all the open source communities out there, who are putting in hours of work for something they get no return from financially. They program because they are passionate and benefit from seeing others use it. Look at Blender and Gimp, just to name two.

Taking all of these accounts into consideration, I interviewed at a variety of locations. I got a few offers from some companies that I would have loved to work with and hopefully will be able to in the future, but in the end, I chose a mobile app development company, which is still considered a startup in Canada.

I chose it because it gave me almost all of the things I wanted in a job, and because I’ve wanted to develop mobile apps for a long time, and this was the perfect opportunity to do what I was really interested in and be paid for it as well ;)!

And thus, I embark on a sixteen month internship, fresh out of school. I look forward to blogging about my experiences, and keeping a note of useful tips and tricks I learn over the course of the next sixteen months.