I spent this week tidying up a few odds and ends in my rafter creation app as well as drawing diagrams and creating icons.  I have done a bit of coding, as well as correcting a bug I discovered with gambrel and mansard fascia calculations.  There will be more coding needed before I can publish still, but not too much, the rafter instructions are not yet housed independently in their respective classes.  That – and I still need to build in an options menu with an ‘about’ page and an option to quit the application.  I have honestly been debating whether it is entirely necessary, but have been leaning towards yes.  The reason being, I don’t want the user to become frustrated with clicking the back button repeatedly when they want to quit.  There is also an issue with the fascia options regarding what to do when the user selection will not allow for a standard fascia cut.  In the event of steep pitches and short fascia projections, it can become necessary to notch the birds mouth cut of the rafter above the top plate.  When this happens you need to lace the plywood or sheathing with the portion of the rafter that is notched out.  I show this situation in the picture below.  

The problem is the user may already have sheathed their building, in which case their needs to be some sort of warning to let the user know the affect of their choice.  There are a few ways I could handle this.  I could limit the user from making choices that create this situation.  The draw back here is it is not a bad practice to notch above the plate in order to accommodate the proper fascia size, and there is no reason not to apply it other than that it will require more work.  I could also choose to allow the situation to occur and just give the user a warning.  However, that would not be very helpful to the user and it would require disabling the creation instructions because they would be incorrect in such a situation.  The last and I think best scenario is to catch the situation and warn the user, giving them the option to re-enter new data or proceed.  In the event that they proceed the fascia activity will pass a message along to the output activity.  This message will let the output activity know what changes to make to the images and instruction in order to accommodate the new fascia cuts.  As a bonus to this approach, the app would be able to accommodate any fascia size in any circumstance.  The draw back would be that it will take the most time to implement and I am severely short on time.

I have completed some of my diagrams and icons this week so here are some pictures of the final product.  

My plan is to utilize top down views to show the necessary inputs for hips, unequal hips, mansards and sheds with hips, as my original 2D approach left to much to be assumed on the user end.  For instance you cannot show to different opposing pitches with a 2D diagram.  I will be working on those soon and will post some more pics when they are ready.  In addition to that I still need to draw all the instructional diagrams, which depict how cut up each rafter.  The textual instructions for cutting common rafters are complete but I still need to write instructions for cutting other more complex rafters.  I expect to finish all diagrams and textual instruction by the end of the week.  I will be working in order of what is most important.  Any instructional texts that don’t get done by the end of week will have to be part of the second version at this point.  That’s pretty much all thats left before I can publish so I had better get back to it.

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.

Well, It would seem another two weeks has flown by but with midterms this past week; I hardly noticed.  I honestly would have had nothing to post a week ago due to a test in Operating Systems which required a lot of preparation.  I also had to set up two other operating systems on my Mac Book Pro Retina MBPR for that class as well this past week and write a report on it.  That said I am going to try and post a tutorial for setting up Ubuntu and Windows 8.1 on a  MBPR using the Refind boot loader, I downloaded from GitHub.  Reason being it is not very straight forward and I could not find any clear instructions myself for setting up a triple boot system on a MBPR.

Anyway, once I finished all that I was in the clear to get some work done on my rafter app.  I decided I would tackle Gambrels and Mansards simultaneously due to there similarity in nature.  Simply put, a Mansard is a Gambrel with hips.  Considering all the mathematical logic I needed was already completed doing past roofs, it only took two days to implement everything else involved.  Although, I have to admit one of those days was severely inhibited due to a Saint Patricks Day work party my wife and I had to go to the night before.  In any event, all the roofs I will be offering in the first version are complete now and by that I mean the great majority of the code is completed.  I have neglected art work, diagrams and the instructions sets which is basically the content of the app, in an attempt to catch up on my tentative deadlines.  Unfortunately, I am not much of an artist and it tends to take me a long time to create icons and diagrams.  The plan now – regardless – is to complete all of that which I imagine will take a couple weeks at least.

This is not what I had hoped for, but the fact is it leaves four maybe five weeks to convert the app to iOS.  However, I am convinced that with layouts, instructions, icons, and themes finished in Android, the conversion will go smoothly.  There was really nothing I could cut from the first version, other than dormers, in order to expedite the process.  Dormers would have been a slightly different animal and they should have needed there own menu as well, so it made sense to cut them.  As a consolation for the loss of dormers from my original proposal though, the app now includes sheds roofs with hips, unequal hip roofs and mansard roofs.  I felt this was a rational and fair trade-off. 

In addition to the two new roof options I added this week, I also made some major updates regarding theming.  Android makes it very easy to customize the look and feel of your app.  You can create customized backgrounds for anything that supports a background; which is almost every UI component available.  In addition to that Android provides a style.xml file in your res/value folder where you can set themes for the entire app like text styles, menu styles, action bar style etc..  It took a little while to wrap my head around it at first, but now changing the theme of the app has become quite trivial.  I spent a good amount of time this week just playing with all the different options and trying to decide which themes best suited my app.  I will be working to finish my icons this week and diagrams so I can post some pictures of the app.  The instructions will more than likely be written before the instructional diagrams, but I will be able to post pics of the menu and input screens soon.

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.

It has been a rather unfruitful couple of weeks.  I have been battling with Android’s infamous out of memory errors for most of the past two weeks.  It has been seemingly impossible to find a solution for my app which satisfies all of its necessary requirements.  I would like to have an independent class for handling the execution of images on a background thread.  I also want that class to create Bitmaps, which fit the ImageView so as to not waste heap space.  Then I want to cache those images, to increase load times while avoiding the creation of duplicate bitmaps, again saving heap space.  So what are the problems?

Well for starters, I need some way of grabbing the width and height of the ImageView; which is more difficult than you would expect.  You cannot simply create an ImageView in the activities onCreate method and call its getWidth and getHeight methods because the screen has not been laid out yet. One way you can get around this is to use the ViewTreeObserver class to set up an OnPreDrawListener or a GlobalLayoutListener, then grab the image width and height from within them.  For example, you can override the onPreDraw method within the OnPreDrawListener and fire any code you want from within there. The Android developers page says onPreDraw is the “Callback method to be invoked when the view tree is about to be drawn”.  The method is constantly being called; perhaps every time the screen refreshes.  That means to use it I needed some kind of catch so my code only fires when a new bitmap is loaded. It was simple enough to handle with a boolean value, but it seemed wasteful to be in a constant cycle when I only need the value once.   Another attempt I made was to override the onWindowFocusChanged method in the Activity classes, which holds my fragments and then call a custom method within the fragments to populate the imageView with the properly sized bitmap.  At first I thought it worked, but the method is only called when the activity sets up, not when each fragment is loaded.  That, and it was not a very modular approach requiring a method override in every activity where I wanted to use images.

In the end, I settled on a different solution.  I had seen a blog, before this out of memory issue ever began; and I was able to implement the solution.  I searched for the blog again but I could not find it, I think because it was a link within one of the hundreds of Stack Overflow posts I have been reading lately.  That said, if I come across the blog again I will post the link.

Anyway, the idea was to add a CustomView class to a FrameLayout and within the CustomView class override the onSizeChanged method.  Then within that method, you can set the newX and newY parameter values as your width and height for the bitmap you want to create.  Originally, I did not want to use this approach because wrapping my imageView in a FrameLayout seemed unnecessary.  OnSizeChanged is not called if you don’t add the CustomView to the FrameLayout.  It also turns out that Layouts in general provide some basic animations for developers.  That was a bonus, unfortunately the animations I made felt a bit clunky and created unnecessary animation delays.  I decided to avoid animation for now, at least until I understand a bit more about it.  Also, I don’t want to waste any of my semester on unnecessary improvements until the basic functions are complete.  In any event, I had overcome the first unexpected hurdle of the week and am now able to generate properly sized bitmaps.  I used the suggested code from the Android Developers page for decoding large bitmaps.

Unfortunately, loading properly sized bitmaps did not fix the out of memory issue, but it was happening less frequently.  I decided I would continue following the advice on the Android developers sight regarding Displaying Bitmaps Efficiently  at https://developer.android.com/training/displaying-bitmaps/index.html as best I could.  Personally, I find there to be a huge lack of details on the Android developers page, which can make implementing their code difficult at times.

I eventually was able to use the AsyncTask class to handle my images on an independent thread, build a cache for the images, and create custom sized bitmaps all in one class that extends View in order to grab the ImageView dimensions.  Along with some clean up in the onDestroy methods of my fragments; I managed to greatly reduce the memory leak to the point where a user would need to button mash through the pictures for a long time before it would crash.  However, this was obviously still unacceptable.

The leak left was much to small to crash the app when used normally, but I knew it was there and it irritated me to no end.  I eventually realized I was creating a new custom view each time I was loading an image, instead of overwriting the same view.  I also discovered that some of what I thought was a memory leak is not,  in the case of loading multiple images in and out of the same ImageView the heap space will appear to be growing by a few kilobytes each time the image changes.  However, that memory is eventually reclaimed, perhaps it is simply the heap space becoming fragmented which is eventually cleaned up, but I am really not sure.  To be sure there was no longer a leak though, I set up an onPreDrawListener which changed the image every time it was called, many times each second.  Then I left the app to run for a couple of hours loading images on my Samsung Galaxy S3 and it no longer crashed due to an out of memory error.  Success!

In the end, I actually decided to remove the cache logic.  My reasons are the cache requires more heap space for storing multiple images, and when a fragment loses focus the entire cache is stored on the heap so the user can go back.  You can recycle the bitmaps in the onPause method, but then they need to be loaded into the cache again.  It sort of defeats the purpose of having the cache.  Furthermore, users will not typically be cycling through images when using the app and it did not make sense because you can only cache only 3 or 4 large bitmaps before one must be evicted.  When I tested the app on actual devices, the image load times seemed instantaneous too.  I only needed to be sure that if the user cycled through all the images repeatedly the app would not crash and the gain in speed for memory the cache offers does not seem worth it.

On top of all that, I made some UI changes to my app this week and I think they will make using the app much clearer.  I broke what was three roofs into five, allowing me to remove valley and hip sets from the instruction section and allow them to be standard when needed.  Along with that, templates have their own create button now. I also provided buttons for cycling through multiple roof rafters.  Now the instructions tab can house nothing but actual instruction texts and the app as a whole seems more intuitive. I was hoping to add more roofs and content these past two weeks, but it just did not work out.  This week I will tackle gambrel and mansard roofs.  Next, it will be onto adding textual content, drawing diagrams, publishing the Android version; and beginning on the iOS version.  As time becomes to much of a constraint I may add the mansard roof in the next version of the app.

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.

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.

So, it appears that I’ve been under the false assumption that my only way to contribute to a large project, regardless of corporate or open source, was through straight programming.  How fortunate I am that I’ve been wrong.

I’ve never considered myself an ‘ace programmer’ by any means, and I have more than one not so fond memories of staring at pages of code wondering why it won’t work.  This has lead to a more favored past time of coding, debugging.  Generating code for me is often slow, and tedious.  While the pseudo-code can flow easily, actual implementation takes a bit more work and requires even more headaches.  But, once I get the general code going, debugging it for errors and making it run a bit more efficient seems to be something I can do, rather easily; especially when its belongs to someone else.  Perhaps that is what I should be setting my sights on, improving how well I can debug code, as it appears to be just another valuable facet of coding.

In a somewhat related event, the class I am working with on the OpenMRS project has been introduce to yet another invaluable tool, IRC chat.  Nothing can help you become familiar with a new program then spending a couple hours straight working with it and communicating with your peers.  Reminds me a little bit of MSN messenger or AOL back in my youth, but now with actual purpose.

From the blog aboulais » CS WSU by aboulais and used with permission of the author. All other rights reserved by the author.

I began this week hoping to finish the hip rafter roof system implementation for my new Rafter Maker app.  However, I ran into a bit of a snag which required some restructuring.  The issue was – up until now, every roof system I have done, shed and gables, has only required one rafter, but a hip roof has three different rafters.   At first it did not seem like much of an issue but it became apparent that with the way the apps navigation was set up; I could not simply add a next button.  The underlying reason was thus far every class and activity has been reusable, because rafters are very similar whether or not they belong different roof systems.  Thus far I was developing separate input classes for each roof type, which would cause my program to have unnecessary repetitive code.  Instead, I chose to simply build a few FragmentActivities and fragments, which take in common inputs.  They passed a RoofState by the main menu when a roof is selected which has allowed me to reduce the number of classes and code overall.

In addition to this, there was a more obvious design issue with having multiple instruction sets.  With only one rafter to handle for shed and gable roofs it was easy to just offer an instruction button once the template data was generated.  However, having the one button for instructions would not allow room for a ‘next rafter’ button; in the case of a hip or gambrel roof, which require multiple different rafters, without effecting the ascetics of the app.  For that reason, I spent a good bit of time studying the android action bar.  I set up an spinner and several buttons and menus to get a feel for what I liked and eventually settled on just using an Xml menu item with other nested menu items creating the effect of a button with a submenu.  This allowed me to display an icon as well as text in the action bar that offers other options for instruction.  Now the app will be able to offer multiple instructions sets to help users throughout the process of building their roof, as well as handle roof systems with multiple different rafters.

The progress made this week was undoubtably in the right direction, but it has left me slightly behind on my timeline for completion.  In an attempt to make up lost time I will implement hip and gambrel roof templates this week.  The following week will be spent adding a few more templates and then the week after that on drawing up the rest of the diagrams I need and instructions.  I will be hoping to launch the android beta in about four weeks.  Then I will begin working on the iOS version, which should go smoother having already worked out a good many kinks developing for Android.  I have decided I will post pics in a few weeks once I have completed the necessary diagrams to truly show off the apps functionality.

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.