Well, its been a bit over a week since my last blog because I have not been able to pull myself away from coding.  The goal for the week originally was to get hip roofs done, but falling behind a bit last week made me shoot fro getting hips and gables done in the same week.  This did not turn out to be possible as there were a number of obstacles which presented themselves as the week went on.  I can say at this point that basic the hip roof is fully functional but so far there is no option for valley rafters and valley jacks.  As it turned out, the hip roof consisted of more than was originally considered, ballooning from 3 different rafters to as many as 8 if there is a valley.

So why did hip roofs turn out to be so so complex?  Well to start with, I only considered the 3 most basic rafters needed when building a hip roof, the common, hip and hip jack rafters.  However, once I emerged myself in the task I realized how short my intentions fell.  I’ll start with the first issue encountered strictly regarding the design of my hip implementation; and I will discuss issues encountered in the code design next.  The first set back when designing a hip roof was that many code books require a ‘double hip’, meaning there are two hip rafters which connect the ridge pole to a corner of the building.  The two rafters, while sharing many values in common, differ in compound angles and the process for cutting.  The second issue I encountered was putting a hip on a square frame.  In the beginning, I had intended on making a hip roof object that only had one roof pitch, but in the event of a square frame the hip rafters would meet in the very center of the building leaving no room for a ridge pole.  The way to circumvent this problem was to now offer unequal pitches.  Now users can select 2 pitches  for example: pitch A could be 5/12 and B 7/12.  I wont get into the finer details here but suffice it to say it was a lot more work behind the scenes handling unequal pitches.  It also created the need for two individual rafter jacks and valley jacks.  Just to put this in perspective, a shed roof or gable consist of one common rafter but a hip can have a common, inner hip, outer hip, inner valley, outer valley, hip jack A, hip jack B, valley jack A, valley jack B which was a bit more to keep track of.  I never even got to think about Gambrel roofs this week but they will be next.  Now I will explain the refactoring I did this week and why.

For refactoring this week there where two goals in mind, code to an interface not an implementation and cleanliness of code or easiness to read.  Thus far, I had been putting all my data into what android calls a bundle or passed it directly via an android Activities Intent.  The bundle and data were passed along to all Activities and Fragments which are essentially sub activities and used or updated as needed.  However, it was very messy and hard to follow.  Furthermore it caused a situation were rafters were being created in all different areas as soon as the necessary data was collected instead of in one place every time.  I felt like this decreased the modularity of the code and readability.  My solution was to trace all the code from the very beginning and make sure I always used a bundle to pass data and that only one was actually created and simply passed between activities.  Fragments would no longer be responsible for updating the bundle, they just pass the data back to the activity which places it into the bundle and sends the bundle along.  So this solved my issue of passing data in a clear and concise manner but I still had an issue with the design of my rafter classes, up until this week – there was only one…

To start tackling the problem I did something that can be difficult, nothing.  What I mean is I coded nothing, after all there is a time to think and a time to act.  I needed to find a way to package everything I needed under one roof, pun intended (haha), and have it be modular and versatile.  I could not help but think back to a strategy class I took and so I started reading up on strategy patterns.  What I landed on, I don’t believe is technically a pattern; though I could be wrong, but rather a fundamental principle to code by.  Program to an interface not an implementation, meaning write your code to fill out an already designed interface that outlines what you want, do not just code classes separately to do what you want and worry about modularity later.  Up until now as I said I only had one rafter class, which executed different logic based on whether I asked for a shed rafter or a common rafter.  I also had a separate fascia/soffit class; ugly but it worked for the time.   After a few days of careful planning, I decided that I would Start from a Roof interface which all roof classes would implement.  The sole purpose of the roof class is to create the needed rafters and add them to a rafter array.  That leads me to another good point going back to strategies which is, its better when a class has an object as opposed to trying to be that object.  Meaning the roof should not try and handle rafter logic, but simply create rafters which contain all there own logic.  All roofs implements the roof interface so I can pass then generically throughout the code and have one purpose delivering an array of rafters.  The rafters themselves were handled the same way, but first I had to condense the fascia/soffit logic in with the rafter logic as it really belonged together.  Then I created a rafter interface again allowing my objects to be passed generically, and making it easy to change a rafters concrete class at run time.  Now rafters and roofs are completely self contained and modular, making it simple to create a roof which then provides the output and instruction activities with a rafter array. Thus allowing those activity classes to easily access data generically – not needing to know what type of rafter it has.

I wish I could say that was all I had to deal with this week but it wasn’t. I also ran into an ‘out of memory’ error when testing on older phones. This was actually an old error come back to haunt me which cost about a day and a half spent creating a custom view class.  The only way I could get height and width of a layout was to extend view which was impossible in my activity classes because they already extend Activity.  So basically the solution was to add the custom view to a FrameLayout which contains an image view, an image, the resources and the activity containing everything.  This has allowed to modularize the resizing and loading of images large.  The only issue I found was that when cycling images in and out of a Frame Layout you must remove the old image before adding the new one or performance can seriously suffer.  Now my code uses a fraction of the heap space it was and is faster and more efficient.

The last issue of the week was with the action bar and running on older devices.  Certain API’s only support certain action bar functions and API’s 10 and under require a support library for action bars.  I will stay backwards compatible at a minimum as far back as API 11, but I will probably support back to API 8 as well.  In the end what it means is I have different looking action bars for API’s less than 11, then from 11 to 13 and then customized action bars for API’s 14 and up.  At this point I am well within the fourth week of classes and starting to feel the pressure so I am sure my next blog will be full of updates just like this one.

Till next time,

Jason Hintlian.

From the blog jasonhintlian » cs-wsu by jasonhintlian and used with permission of the author. All other rights reserved by the author.