I gave a Tech Talk at my company, GenUI. It’s a lightweight overview, with a short discussion afterwords.
I learned Flutter for a client who wanted to explore Flutter for a project they had in mind. They wanted someone with knowledge of iOS, Android, and anything else that might come up.
You can view the presentation below.
Learning Flutter was a lot of fun! Since then I’ve been on a few native mobile projects. There are times I feel that Flutter might have made a lot of sense for them. I hope to get the chance to use Flutter again in the future.
I also wrote a small demo of a validating DropDown widget for Flutter. You can view it at my github page: https://github.com/jjerome00/dropdown_formfield_demo
I should note that I had to put this together on short notice. I would have liked to have the demo a little more hashed out.
Recently I’ve been having a lot of fun playing around with other people’s code.
I’ve been forking games on Github to learn a little about how they work. I then change them so that they are impossible to lose. They turn out to be very short and completely useless beyond a couple laughs. Messing around with the code is almost more fun than the end result.
This started when a coworker was telling me that he had never won a video game. A few of us started coming up with ideas for games where it was impossible to lose. They seemed pretty funny, so I decided to play around with the idea a little bit.
I’ve only done a couple games so far. I’ve had some challenges along the way:
Most of these projects are stale and need a little work to get them working again. I spent a lot of time importing Eclipse projects into Android studio and working out the details
I had to pull apart a lot of conveniences: game options, number of lives, difficulty settings
I’m impressed how entertaining they are to put them together when I have no regards for playing it safe. Every hack is on the table as a possibility. I only have to worry about one thing – never lose.
“Tetris Can’t Lose”
I named this game after the old tv show “Parker Lewis Can’t Lose”
This was my first attempt at changing a game. It had a couple of surprises:
Tetris isn’t designed to win! You keep playing until you lose. So I had to come up with a way to win the game, and add it as an option in the game play.
I decided to add a funny “TaDa!” sound, so I had to add MediaPlayer and SoundPool. This change has become my exclamation point, and has made it into the other games as well.
I had to clean up some code, create a new launch icon, etc
One thing I regret is that I didn’t fork the repo correctly. I ended up losing some history that I wanted to show in Github. It’s not a big deal, but I wanted to make sure whoever ran into the project knew that I based it off someone else’s work. I ended up adding a note to the project’s readme.
I ran across this breakout game on Github. It had all the parts that I was looking for, and as a bonus it included lots of documentation. It was a sample game that explained a lot about how to write a game for Android.
It was rather stale, so it took a bit to import it into Android Studio and get it to work
It had a lot of game options I had to remove or change for my needs
I had to play around with the settings to get the most humor out of it
This one was different in that you don’t win immediately like in the Tetris game. You can move the paddle around and try to make the process faster, but it doesn’t matter.
Keeping the game play intact was a good idea – it makes the game a little more fun. The ball can’t fit past the paddle, but it looks like it could. It’s amazing to see people’s first reaction when they play. They have an initial sense of urgency to save the ball even though it’s impossible for it to fit past the paddle.
I’m sorry to report that Good To Go have updated their website and it has broken the app. I have been in contact with them about a promised API, but it appears one is not in the works. Sadly, I had to unpublish the app.
I included it here because it was a great experience to build and release the original application.
Where did this idea come from? I came up with the idea for this app while crossing the SR 520 bridge, which is a toll road. All tolling is handled by an automated system that is linked to an online account you setup with the State of Washington. You can read more about the program
at http://mygoodtogo.com . You sign up for an account, and provide a credit card to get started. When you cross the bridge (or another tolled area) their system reads your pass and deducts the toll
from your account.
I had read some stories about people who had racked up large fines for failing to notice they had outstanding tolls and fees on their accounts. I decided to double-check my account, but couldn’t remember my username or password. It would be ok if it happened
once, but every time I wanted to check my account I would have to go through the process of forgetting my username or password and having to reset my account.
So I built this app. It allows me to quickly view my tolling activity without having to reset my password. Now when I want to quickly review my account, I can just open the app and refresh for my most recent activity.
It has also saved us money. We had a car that had problems with a sticker pass. The system would recognize the pass but someone at Good To Go had to visually confirm the toll via a photo. It’s called a photo enforcement fee, and you get charged an additional
25 cents for each time it occurs. It happened so frequently that it became cost effective to get a new pass.
How long did it take to build? I think it was about a year. It was done in my spare time, and I allowed some other interests to get in the way if needed, like painting my fridge to look like a TARDIS.
What’s your status? I’m a full-time contractor, so I was looking for something to do on the side for fun. I don’t do any advertising for my apps, and I feel if I was ever going to look to do this more seriously it would be beneficial for me to keep publishing apps.
What got you into Android development? Honestly, I couldn’t afford a computer from Apple. I did some robotics development a few years ago that I very much liked. The same bug that might render a web page incorrectly might sent your robot into a ditch. Android development reminded me of that past, so I wanted to explore it further.
What challenges did you face with building the app?
My other apps were Activity-based apps, and I wanted to play with fragments. It was a bit of pain, because some things I knew, but not enough to do everything I wanted to do. So I was making jagged progress – some things came quickly, others moved forward like a snail.
InApp billing was a little bit of a pain. For starters, InApp billing needs more real-world examples, and the ability to debug a beta APK with InApp billing enabled
The technique to implement a Navigation Drawer changed half way through my development of the app. Honestly I’m glad I put the time in to change it because the new way is better.
It seems petty, but would it kill Android Studio to allow you to set a breakpoint on an empty line? I mean that I want it to stop before the next executable line. Android Studio will let you set the breakpoint on an empty line, but completely ignores it come debug time.
What’s next? I have a few ideas rolling around in my head, and some friends with ideas of their own. My biggest fear is that since I’m doing this myself that I’m missing out on the collaborative learning I would get if I was working with a team.
