Category Archives: Week 4

Android Audio Recording and Playback, and an Animation False Start

This week, I spent a lot of time with animations in Android. And yet, I still could not get transitions to work to my liking. After reading Android’s docs, I resorted to a few different videos and tutorials, some of which seemed straightforward but were using methods of Android past.

The goal was to animate the title of a single audio file in a list, to move to the top of the screen and become a heading for details about that file. Animations are easy enough if you’re transitioning between Activities. But it appears that having a RecyclerView in a Fragment to list audio files adds some complications. I did successfully animate between the screens, but the first item in the RecyclerView’s list was animated, and it abruptly changed to the correct title when the motion ended. The issue is that this transition animation requires two elements to have a shared “transitionName”. Because I am using Card objects to display each of the audio files, only one Card can use that transitionName and be animated.

The solution is to set the name in the RecyclerView’s ViewHolder, so that when objects are bound to a specific card, they can get a unique transitionName. This can then be applied to the Fragment’s View before the animation begins. Attempts to do this caused some problems due to Android’s Lifecycle. Many a blog post have been written on this subject, but I’d like to discuss it in the near future to gain a stronger understanding.

All of this is to say: I want to efficiently getting from point A to point B by realizing which subjects and features are most important. Understanding the Android Lifecycle is clearly more important than an animation, and apparently prerequisite knowledge. And recording and playback are at the heart of the app itself. So my progress in animation is stashed in Git and ready for me to continue once I accomplish these other tasks.

Luckily, getting audio to record and play back was a much more enjoyable process. This might be due to my greater interest in the feature, but I was able to break down the problem and troubleshoot issues much easier.

I erroneously believed that my simple spike project would easily translate to my app. Android’s guide to MediaRecorder and MediaPlayer made it simple to get something quickly up and running. However, using their code directly would create a nightmare of an Activity, which neither properly separate concerns nor follow basic OOP principles. Furthermore, I needed the recording to begin immediately upon opening a new “RecordActivity”. This caused some issues with Android’s lifecycle, so I took to opportunity to explore that. The problem came from trying to start recording in onCreate(), which did not provide enough time to load the MediaRecorder into memory. The solution was to start recording on the onResume() event. However, this may be called more than once in the life of an Activity, so I simply check if the MediaRecorder is currently recording, and start recording if it isn’t.

I spent a bit too much time trying to find the recorded audio files in phone’s physical storage. It seems they do not appear, and I haven’t found a good explanation for this. Luckily, Android Studio’s Device File Explorer did reveal that the files were saved and properly recorded audio.

From there, implementing audio playback as a Service (which in Android is essentially an Activity without a UI) was rather smooth. This also allows playback to be initiated from anywhere in the app by passing the file name in a single line of code.

I have always been a function-over-form kind of guy. I made significant progress on the app this week in the function department. Hopefully the form will come in time.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

The Long Road

When I started programming, I was hoping to be a professional programmer within a year. Maybe two. I pictured myself as an expert, and studied the minutia of Python. If I memorized the documentation, I’d be an expert, wouldn’t I?

This apprenticeship pattern describes why that line of thinking is false. Becoming an expert is a lifelong experience, and the expert realizes there is always more to learn. It warns against taking the best, highest-paying job as soon as possible. Instead, value learning and accept the role of an apprentice.

I beat myself up for not pursuing my interest in programming when I was a child. I asked a cousin how he programmed video games when I was 10 years old, but didn’t write my first line of code for 5 years. Even then, I found the task daunting. Obsessing over details slowed me down. I didn’t completely dive into bigger projects until my 20’s.

The best learning experience I’ve had was an internship. I had freedom to try new things, make mistakes, and overcome challenges. I built a large project on my own, which my team loved. At a larger company, I would have likely worked on a much smaller piece of a huge puzzle. The experience of starting on my own will pay dividends for my entire career.

Similarly, while returning to college after a few years of programming was frustrating, it was helpful. I had thought CS-101 would be a complete waste of time. Instead, it was a chance to dive deeper into subjects I was already familiar with and gain exposure to concepts I hadn’t. It provided a foundation, which is the essence of this pattern.

This section of the book says there is no one so far ahead that you cannot catch up if you think decades ahead. This idea is an extreme relief to those of us who started a bit late. It’s tempting to compare ourselves to the teenage CEOs of the world and take shortcuts to catch up tomorrow. But I plan to write software for the rest of my career, so this pattern is a reminder to take my time, enjoy the process, and understand that consistent, continual effort will get my skills where I’d like them to be.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 3: Confront Your Ignorance

“Confront Your Ignorance” is another pattern that struck a chord with me from the Apprenticeship Patterns book. I chose to talk about this pattern now because of its strong relationship with the “Expose Your Ignorance” pattern which I talked about in a recent post. As a developer who is relatively early in their journey, I realize that there is some skill or tool that I should know that I may be unfamiliar with almost daily.

Confronting your ignorance is all about taking the list of skills and tools that one creates when exposing their ignorance and setting aside time to learn that skill. The approach with which one learns a given skill or tool is unique to the individual. The main goal of this pattern is to be able to confidently say that you understand how to implement a given skill or effectively use a tool after confronting that gap in your skill set. It is important to reflect often and decide, once you have reached satisfactory knowledge in an area, whether you should switch topics or delve deeper into the current one. If a developer does a great job of exposing their ignorance without ever confronting it they can never take the step to being a software craftsman. They will find comfort in their ignorance and rely on others to fill in the gaps. Conversely, if a developer always confronts their ignorance without exposing it, it creates a work environment where everyone pretends to have a skill and then learns it in hiding to appear adequate. This would be a bad application of this pattern and should be avoided as much as possible.

For myself, I find that my learning and application of a skill tend to go hand in hand. I find myself confronting my ignorance at the same time as trying to deliver a product which tends to end in frustration and a sense of failure. In employing this pattern I can save myself the frustration by setting aside time to toy with a tool and learn a skill. Inevitable failures when learning how to use a tool no longer equate to failures in being able to deliver a product. After reading “Confront Your Ignorance” I will immediately start to employ this pattern in daily life. I will expose my ignorance and then give myself the time to fill those gaps in my skill set.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Dig Deeper Pattern

This pattern focuses on being able to decompose problems entirely and understand each part thoroughly. Many times, in the work force, people will only have enough approximate knowledge to help them get through their days, but when problems arise, they become useless. It is extremely important to be able to take all parts of a problem and truly understand them. To be able to decompose these large problems, it is important to study and understand every part that goes into it. While doing this however, it is important not to become too narrowly focused on one idea.

I connected with this pattern a lot due to the fact that many times when working on a project, I will run into an issue that I can provide a “hacky” fix to by reading it online, but I never acquire the knowledge of that topic specifically. I often times make the excuse that school causes timelines and completion of projects that are often unreasonable to be able to fully delve into the project. However, I need to start taking these problems apart piece by piece in order to start fully learning anything I come into contact with. If I am able to start with small sections of material, eventually there will be overlaps in knowledge that will build on top of each other until the projects that I’m faced with, now appear to be far easier. It is often overwhelming to start off researching into an entire idea of a project but being able to take small slices of it will make it far more manageable.

I enjoyed in this pattern how they discussed that often times there is a more knowledgeable person in order to fill in the gaps that you may have. In the workforce this can be a co-worker or a higher-up, but often times it is the teacher in school. Being able to create the knowledge for oneself is far superior in the long run than consistently going to the person that may have a better understanding. In order for anyone to reach that status of knowledge, they all took their time to break down and understand individual components of any problem they run into.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Kindred Spirits: Programming inspired by Anne of Green Gables

When reading the kindred spirits apprenticeship pattern, I was immediately reminded of my first real programming class, CS140, wherein I met some of the friendly faces I would spend the next two years becoming a programmer with. A few of these faces were a part of my group in that class’s lab and with them we challenged each other in the subject and helped fill each other’s blind spots. While this is hardly unique, I’m sure, it exemplifies what the pattern is all about: finding peers who you can learn and grow with. Now with those two years nearly behind us and the end (of our education) is in sight, those same friends have been amazing resources.

As new learners, we tend to go in all different directions, not favoring any set method because we have yet to find the path of least resistance or best practices. Subsequently, we create puzzles pieces with our bits of knowledge that we all can combine to get a clear picture of a language, framework, et cetera. I have found as well, that what was often very useful was the ability to politely disagree – read: bicker like an old couple – with your peer and push back and forth on each other to really challenge one’s knowledge or understanding of something. It was through this back and forth that many of the solutions we were so desperately searching for came about; which is something the pattern even addresses, stating that it is imperative to avoid group think and challenge each other.

I remember distinctly have an erratic mass of code segments and illustrations of a particular data structure, the exact one I cannot remember, all over the board in the Science and Technology center study rooms. Data Structures, our major’s trial by fire, has crushed fledgling programmers of far greater skill than me. I can say with no doubt, that had it not been for these brain-storming sessions I would not have passed that class or even completely the projects thoroughly in the way that I eventually did. As I look forward to internships and even jobs after graduation, I hope to keep those around me who I have learned so much from and find new kindred spirits to take on this next chapter of my programming career.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Record what you learn

“You should not also underestimate the power of writing itself…You can lose your larger sense of purpose. But writing lets you step back and think through a problem. Even the angriest rant forces the writer to achieve a degree of thoughtfulness.”

—Atul Gawande, Better

Record what you learn has the purpose to make everyone able to memorize things for a very long time. Using this pattern, it’s not just about writing down notes in a paper and then forget about it. It is about writing down the information you need to learn and read it continuously to keep that information stored in your brain. Keeping a record of your lessons to a blog or personal wiki, it is not a bad idea at all. You decide whom you’re going to share it with, or not share it at all. As long as you write down your notes and get back to them to read or even to make improvements, your brain will be in the perfect shape of memorizing things.

This pattern made me realize that taking notes and writing the most important parts of the lesson is not the end of the learning process. Most of the time when I have to learn something new, I write pages and pages that never end, read them, and then I write a summary without looking at the notes. The problem with this is that after I am done with that lesson, I don’t really go back and read those notes, nor the summary. I wonder if I still have those notes?!

I found this pattern very useful and interesting in my career. Starting from today, I will keep track of my writings, add more details to them, and stick the date they get written, so that when I go back, I would find very organized writing that would make me go back to it over and over again. There is no better thing as reading constantly and memorizing useful information. Another important part of this pattern is that when you go back to read you realize how much things have evolved for a specific topic, and you ask yourself if you should update the original or not? In my opinion, the same as everything nowadays gets updated, writings need an update as well. As a conclusion, keep a record of your writings, the same way you keep a record of bank transactions…

From the blog CS@Worcester – Gloris's Blog by Gloris Pina and used with permission of the author. All other rights reserved by the author.

Singleton…

This week was all about design
patterns and ways to implement them. We have only just begun and to start with
we talked about Singleton. It is a design pattern that creates a single
instance of a class to be used from a well-known access point. I had some previous
interaction with this particular design pattern at my work, when we were using
the C++ language this was one of the ways we got around some of the problems we
had, since moving to C# it went away but still I knew about singleton before
this weeks class at school. I was a little bit curious and wanted to read about
it more, so I looked up blog post by Ted Neward called, surprise, surprise: “Singleton”.
Link to it is here.

                In this
blog Ted talks about it extensively in my opinion, from the context of it, the
problem that it solves and the consequences of the Singleton implementation. I definitely
like the information provided and it help me expand my knowledge of the design
pattern, which is a good extension on my current knowledge both from work and
school. One of the parts in the blog really helped me understand it better and
that is: “Reduced name space. “Singleton” is just “global” hiding behind
another name. One of the explicit goals (in 1995) was to be able to have the
necessary scope-wide state, but without accidentally clashing over names in
that global namespace. Languages which support explicit namespacing (Java, C#,
C++, Swift, yeah pretty much all of them) mean that we can have this benefit
even without doing anything more than moving the global variable into one of
those namespacing mechanisms.” This describes Singleton as global and I like
this description because it really drove home what Singleton is and how to use
it, I think….

                Overall,
I know I will be learning about many other design patterns and implementations
but for now having this is good enough, who knows maybe others will be a better
solution than Singleton, but I think it is the simplest one to learn. Neward
mention couple of time the debate of Singleton vs statics and that is something
interesting on its own. Something that I will research a little bit more when
time allows. Until then I remember one thing my boss said about singletons back
in the day: “Singletons were used everywhere, and somehow it worked, we didn’t
know why, but it did.”

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

The Singleton Design Pattern

Recently in CS-343, I have been introduced to the concept of
design patterns. These are essentially code-writing techniques that help make
code easier to describe, modify and maintain. There are a wide variety of design
patterns, each with different benefits and drawbacks. My last class on Thursday
ended as we began to cover the Singleton Pattern, and so I decided I would look
into Singleton in advance of our activities next class about it. My research
led me to Andrew Powell-Morse’s blog post “Creational Design Patterns:
Singleton,” which can be found here:

https://airbrake.io/blog/design-patterns/creational-design-patterns-singleton

This post, as you may expect, is focused on explaining the
Singleton pattern to the reader. Powell-Morse accomplishes this by using real-world
analogies to describe the concept of Singleton and a programming example to show
how the pattern can be implemented in code. I chose to write about this blog
not only because it explains Singleton well, but also because I found the
programming example interesting. The purpose of the Singleton pattern is to
ensure only a single instance of certain classes can exist at a time, which Powell-Morse
clearly states right at the start of the blog. This is a simple enough concept
to grasp, but Powell-Morse elaborates further by explaining that Singleton
should be thought of in terms of uniqueness rather than singularity. He uses real-world
examples of uniqueness, those being individuality in people and a unique deck
of cards used for poker games, to describe situations in which Singleton can be
useful. These examples, especially the deck of cards, have helped me understand
that Singleton is useful in programs that only require a single instance of a
class, and I could definitely see myself applying this concept in future
projects to help reduce memory usage from unnecessary objects.

Since I found the deck of cards analogy especially helpful, I was pleased to discover that it was the focus of Powell-Morse’s programming example. However, the example’s complexity made it somewhat difficult to understand at first. Instead of simply demonstrating how Singleton is coded, Powell-Morse applies the concept to a program using multiple threads that separately remove card from the same deck instance. I have not written many programs myself that use multi-threading, and this lack of experience made the example confusing initially. The example is also written in C#, which is a language I am not nearly as experienced in as I am with Java. Despite my initial confusion, I eventually understood the example and grew to appreciate its complexity. The use of multi-threading in the example helped demonstrate a major drawback of Singleton and how to work around it in C#. The example not only taught me how to implement Singleton into my future coding projects using static variables, but it also showed me how to work around Singleton’s issues with multi-threading. This blog post also taught me more about a language that isn’t Java, which is always welcome.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Putting the ‘O’ in SOLID

We
covered the Open/Close principle in a recent lab, and it prompted a desire to
cover some of the SOLID principles. I have determined however, that the length
of this blog is short enough that I should dedicate it to a single principle at
a time, beginning with the aforementioned Open/Close principle.

              This particular object-oriented
principle was outlined by Bertrand Meyer and states:

“…entities should be open for extension, but closed for modification.”

              This of course, is a complex way
of expressing a simple guideline for software development; which is that new
functionality should be able to added without having to radically change existing
code. The operative word, extension, is illustrative. If your code was a home,
and you wanted to add more square-footage (read: functionality), you shouldn’t
need to knock all the walls, or the whole thing, down to add a bathroom.

              In the blog chosen, the author summarizes
a talk he gave about the very subject. In it, he provides an example of a program
he is developing for a company that calculates the total area of a set of rectangles.
As the customer requests more and more shapes be added to the calculator, the original
code changes drastically and gets longer and longer. This modification is opposed
to this principle. In opposition, creating a Shape class that contains many children
of different specific shapes – each with their own area function – with the
ability to add more, eliminates constant modification of the main class, and
allows for constant extensionability in the form of new shapes.

              To say simply that code should be
modular is unhelpful, as it is broad and the general definition of so many more
good coding practices. Our class and homework provide another perfect example.
Why should we have to constantly Override and rewrite portions of a superclass’
methods in each of its child classes to achieve proper functionality. Instead, in
making a Quack/Fly Behavior interface we have established a broad mold that
many new behaviors can be built off of; access to all of which is then granted
by the relationship to the single respective behavior interface.

              Therefore, the ability of code to be
extended with new functionalities, using a single reference – in this case the behaviors,
or shapes – instead of needing to rewrite or overwrite code is what is meant by
extension; while keeping the existing code from needing constant revisions, is being
closed for modification. Like the house example earlier, you should constantly be
building out, not renovating what exists already.

Sources:

A
simple example of the Open/Closed Principle

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

The KISS and RoP Trade-off

I’ve discussed trade-offs in software before. The more you delve into the world of design and engineering, the more evident it becomes that trade-offs are an underlying principle to rule all principles. There is no perfect software; there is no perfect solution. My aim to strive for the best software, however, led to me choose this topic to discuss.

I intended to keep it simple and focus on KISS (Keep it Simple, Stupid), which claims that a simple, straightforward solution is the better solution. But after listening to a podcast about design principles by SoftwareArchitekTOUR*, I was forced to make a trade-off between a simple blog post and a more powerful, generic one. Specifically, they mentioned the RoP (Rule of Power) principle or GP (generalization principle), which states “that a more generic solution is better than a specific one”.

You will never produce a perfect design… but you can’t typically have both [KISS and RoP]. Either it is simple and specific, or it’s very generic and flexible and therefore no longer simple but rather has a certain degree of complexity. You can typically only strive for a Pareto-Optimal Solution.”

Christian Rehn (translated from German), SoftwareArchitekTOUR Episode 60, 14:30 – 15:45

Rehn says it’s a balancing act, and neither principle is either right nor wrong. The concept of a Pareto-optimal solution is rather simple: find a solution that is better in at least one aspect, but at least as good in every other aspect. As Rehn says, you have to ask yourself what works best in your situation. What is the best compromise?

So what does this mean when choosing between KISS and RoP? Like any new concept or principle, both should be practiced in isolation, with small projects. It is only with this basic experience that you can learn how to make these decisions in more complicated systems.

In learning design principles, I have refactored code in order to make it adhere to a design pattern or principle. When new situations arise, the old solution may no longer hold water. But each time, the code was kept as simple as possible given the requirements. The Pareto-optimal solution is the simplest solution that provides the required functionality. This leads me to conclude that KISS trumps RoP, especially considering other principles such as YAGNI, which strives to prevent the code smell of unneeded complexity. But on the other hand, the simplest solution in which every class does a single, specific thing, would itself become extremely verbose, violating DRY in particular.

Determining how to make these trade-offs is an art and comes with experience. In the mean time, I plan to keep my code as simple as possible and add complexity and generalizations as needed.

* This podcast is only available in German, but the English show notes explain the topics of the podcast in detail.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.