This is my new blog, all of the content posted here will relate to Computer Science or Worcester State University.

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

Hi this is pavani its my first CS blog!!!

Thank you!!

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

I was originally thinking I would talk about inheritance in this blog entry but I decided to step it up a notch and talk about something more interesting. I will be breaking the content up between two or three blogs as it will be fairly in depth.

Any one who has been programming in Android recently, probably knows fragments are a necessity if you want to have cool looking UI’s on multiple devices but If your new to Android and have not used fragments or simply don’t get them, this blog/tutorial might help you.  Fragments were introduced back in February of 2011 with the release of Android 3.0 so this is not a brand new topic but its a crucial one and so here it goes.

Fragments allow you the developer to have separate sub activities within your current activity and essentially host multiple independent UI’s on the same screen.  They are great for displaying multiple activities at once on larger tablets and you can even replace existing fragments with other fragments on the fly.  That means you no longer need to have an activity for every page.  Sort of any way.  A single activity lets say running on a phone for instance, so it is only displaying one fragment at a time, can switch fragments in and out as it needs them; but realize that “fragment” is just a clever name for a sub activity so every fragment still must be hosted by an activity.  If your developing in Android you will want to get comfortable with fragments so you can have a professional looking app, regardless of what device its being run on.

There are two ways android allows you to use fragment in your XML file.  You can hard code a fragments into a your page layout or you can create FrameLayout and then add fragments late using code.  The second option, using a FrameLayout, allows you to not only add but also replace fragments on the fly using code.  Taking this approach will provide you much more flexibility and so its the approach I will be showing using code from my most recent project.

Here is the rafter_output.xml file from my Rafter Maker project.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:baselineAligned="false"
 android:orientation="horizontal" >

 <FrameLayout
 android:id="@+id/fragmenta"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:layout_weight="7" />

 <FrameLayout
 android:id="@+id/fragmentb"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:layout_weight="3" />

</LinearLayout>

Notice at line 6 the orientation is set to horizontal and then on lines 12 and 18 I have applied a weight to each FrameLayout. This will divide the screen real-estate amongst each fragment accordingly when we load them in later.  Something worth mentioning here is how weights are calculated, only because in my opinion the process is a bit counter intuitive.  One would think that if fragmentA has a weight of 2 and fragmentB has a weight of 1 that we add them together to get 3 and then divide the weight of either fragment by that 3 to get the percentage it occupies on screen  Meaning fragmentA would get 66% and fragmentB gets 33% but that is not the case, its actually the reverse.  FragmentB will only occupy 66% while fragmentA will occupies the other 33%.  Why it works that way I could not say.

Now next I will show the xml page layouts that we will be displaying in the fragments, which will eventually get loaded into our FrameLayouts.  Below is a simplified version of my fragment_rafter_output.xml file.  They original has many more rows of data which is why I choses to use a TableLayout as the root of the xml page.

<?xml version="1.0" encoding="utf-8"?>
<TableLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:id="@+id/tableLayout1"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:layout_alignParentTop="true"
 android:layout_marginLeft="10dp"
 android:background="@color/theme_secondary_color" >

 <TableRow
 android:id="@+id/tableRow1"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content" >

 <TextView
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="Angle A = "
 android:textAppearance="?android:attr/textAppearanceLarge"
 android:textSize="20sp" />

 <TextView
 android:id="@+id/tva"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="0"
 android:textAppearance="?android:attr/textAppearanceLarge"
 android:textColor="@color/text_color"
 android:textSize="20sp" />
 </TableRow>
</TableLayout>

Now here we have my fragment_image_output.xml. file.  I’ll show the whole file because most of it will become relevant as we move on.

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:id="@+id/RootView">

 <View
 android:layout_width="10dp"
 android:layout_height="fill_parent"
 android:background="@drawable/shadow_left" />

 <LinearLayout
 android:id="@+id/llbuttons"
 android:layout_width="match_parent"
 android:layout_height="wrap_content"
 android:layout_alignParentBottom="true"
 android:layout_marginLeft="10dp"
 android:layout_marginRight="5dp"
 android:layout_marginBottom="5dp"
 android:orientation="horizontal" >

 <Button
 android:id="@+id/bback"
 style="@style/ButtonText"
 android:layout_weight="2.5"
 android:background="@drawable/btn_blue"
 android:text="&lt;" />
 <Button
 android:id="@+id/bcreate"
 style="@style/ButtonText"
 android:layout_weight="1"
 android:background="@drawable/btn_blue"
 android:text="create" />

 <Button
 android:id="@+id/bnext"
 style="@style/ButtonText"
 android:layout_weight="2.5"
 android:background="@drawable/btn_blue"
 android:text="&gt;" />
 </LinearLayout>

 <TextView
 android:id="@+id/tvStep"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:layout_alignParentTop="true"
 android:layout_centerHorizontal="true"
 android:text="data"
 android:textSize="20sp"
 android:textStyle="bold" />

 <FrameLayout
 android:id="@+id/flimage"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:layout_below="@id/tvStep"
 android:layout_above="@id/llbuttons">

 <ImageView
 android:id="@+id/ivInstImage"
 android:layout_width="match_parent"
 android:layout_height="match_parent" />
 </FrameLayout>

</RelativeLayout>

The first thing I want to point out is a small added bonus. If you look at lines 7-10 you will notice a View which sets a background gradient called shadow which is 10 dp wide and is the height of the page. This will make the page to its left appear closer to the user and add an element of depth to your app. The other thing to notice is the three buttons. We will be using those later to update our fragments. The last thing to notice is the FrameLayout containing our ImageView. When we click the next or back button a new rafter image will be loaded and the data fragment will be updated accordingly as well.

Well, that takes care of the XML layouts we will need, the next part to handle will be the the code that defines our fragments and our host activity in Java.

Till then,

Jason Hintlian

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

This week I have decided to take the blog in a different direction.  Instead of blogging about the weeks’ progress and what’s to come, I am going to start focusing much more on being informative and helpful to readers who may have had similar troubles.  Today, I am going to be talking about interfaces in Java, and how I used them in developing my Rafter Maker app for Android.  Now, why would I want to use an interface?  Well, an interface will allow you to pass objects in your code generically.  For instance, I can create any number of objects which implement the Rafter interface and then pass them all throughout the code defined generically as Rafter.  This makes it possible to retrieve the same data from any type of rafter through a generic variable, while allowing the code in each rafter object to  be unique.  I created some examples to illustrate my point.

public interface Rafter{

getAngle();
getLength();
getName();

}

Above, is a simplified example of the Rafter interface in my app.  The original has more methods, but that’s the only difference.  

public class ShedRafter implements Rafter{

private double angle, length;

public ShedRafter(double rise, double run){
// calculate angle and length from rise and run
}

@Override
getAngle(){
return angle
}
@Override
getLength(){
return length
}
@Override
getName(){
return "Shed Rafter";
}

Above is a simplified example of a shed rafter class from my app. Notice it implements the Rafter interface and overrides each empty method declaration in the interface. Any class that implements an interface must override all the methods within that interface otherwise you will get an error that says something like “must implement the inherited abstract methods” meaning the abstract (undefined) methods in the interface.

public class GableRafter implements Rafter{

private double angle, length;

public GableRafter(string pitch, double span){

// calculate angle and length from pitch and span
<pre>
@Override
getAngle(){
return angle
}
@Override
getLength(){
return length
}
@Override
getName(){
return "Gable Rafter";
}
}

Above here is a simplified example of a gable rafter class from my app which differs from the shed rafter class, but notice that both classes implement the Rafter interface allowing the creation of a Rafter object that can be a ShedRafter or a GableRafter .

double span = 144, rise = 60, run = 144;
String pitch = "5/12"

Rafter rafter = new ShedRafter(rise, run);
rafter = new GableRafter(span, pitch)

The classes take different  arguments with different names and the algorithms for calculating a rafter from a rise and run versus a pitch and span are also different; though I don’t show them for the purpose of simplicity.  This approach allowed me to perform completely different calculations in each rafter object and on different variables, while still adhering to the interface definition by overriding getAngle(), getLength() and getName().  This way both classes were Rafters and Rafters are  generic.   While in contrast each individual rafter class implementing Rafter’s  is  unique.

This made it easy to create any rafter on the fly and pass it to my output class, which is responsible for displaying the angle length and name of  the rafter.  Now there is no need to check or know what type of rafter you have, because it does not matter, all the differences between rafters have been compartmentalized within the individual definitions.  For instance, the getName() method is easily modified to return the proper names for each rafter, and likewise I can easily change the way I calculate angle and length in the constructor.  The behavior of methods I might add to the interface later on will also be easily modified and will require minimal updating to the code overall.

double span = 144, rise = 60, run = 144;
String pitch = "5/12"

Rafter rafter = new ShedRafter(rise, run);

System.out.println("Print " + rafter.getName() + " Data\n");
System.out.println("The angle is = " + rafter.getAngle());
System.out.println("The length is = " + rafter.getLength() + "\n");

rafter = new GableRafter(span, pitch)

System.out.println("Print " + rafter.getName() + " Data\n");
System.out.println("The angle is = " + rafter.getAngle());
System.out.println("The length is = " + rafter.getLength() + "\n");

Above you can see it is easy now to define a single Rafter variable and use it to get the values from any rafter class which implements the Rafter interface.

Well, thats it for this blog.

Till next time.

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

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.