Tag Archives: Android

New Year – Same Old Stuff

New year always gets you thinking about what you did in the previous and what you hope to achieve in the next.  To recap my side-project life in 2016:

  • Merged two of three Parse apps over to Firebase and to keep them running
  • Didn’t merge the other, will unpublish from Google Play until I get around to it
  • Spent a healthy amount of time writing a Daily Fantasy Sports (DFS) lineup generating program (I haven’t written about this, but TLDR; it didn’t win me millions)
  • Learned how to throw together a quick and dirty Chrome Extension and then take the first step towards robustification by adding a Flask/Postgres back-end and deploying to Heroku

Doesn’t look too bad from afar, but really I’m still not producing programs which can reach an audience.  I kept two lightly used Android apps alive, ignoring a third.  I nearly reached minimum viable product territory with a Chrome Extension, but stopped short.

The bigger thing I’ve come to realize is that by switching around and/or dropping things, I’m often stopping short of the point of learning enough to be useful in whatever language/framework/whatever I’m attempting to learn.  When I drop something and pick it up a couple of months later, I have to re-learn most of it just to get rolling again because I didn’t get deep enough the first time to have the lessons sink in.  That’s a problem.  I’m not producing anything and I’m not retaining a workable knowledge of anything I’m learning.

With that being said, what’s the goal for 2017?

  1. Finish that Chrome Extension
  2. Port that 3rd app
  3. ????

The Chrome Extension is something I’ll hopefully write about in the future, but it’s a minor utility that took a night to write with zero Chrome Extension knowledge.  The hard/fun/educational part is adding everything around that to make it a usable product.  I took the first steps by switching to Flask with a Postgres DB to store the data received from the extension (I originally just threw up an sqlite DB running with Bottle).  The next steps are users and views to access the data we’re now storing, breaking down and paying Heroku to host the thing, releasing it to the Chrome Store and trying to get people to use it (I have a partner to handle the latter of those).

I actually picked up the extension project tonight which inspired me to write here.  I fixed a lingering bug and did the preliminary research on how to add users so I could authenticate and allow view access to the data.  Just picking it up after a long layoff was a big step, I tend to drop things like that and move onto the next shiny idea that comes along.  I’m planning on pushing on this with a dedicated one night per week schedule.  Hopefully I will be returning soon to do a full entry about this.

As for the third Parse app. It’s not being used so it’d be easy to ignore it, but I like the idea of having working apps in Google Play, so I do hope to do the conversion.  It is a bit more tricky than the two apps I did convert because it is the only one with users and the requirement of storing user data.  I don’t imagine this will be difficult, I just haven’t done it.  I want to finish for completion’s sake.

Beyond that, I really just want to keep learning.  I would prefer to start getting deep into something(s) rather than continue to be jumping around.  Maybe I can find another project to work on using Flask.  I want to get to the point where when I sit down to start a new web project I don’t have to re-learn everything.  Over the years I’ve switching between Django, Rails, Bottle, and Flask (I think that’s all, I’m probably forgetting some).  It’s nice to have a familiarity with a wide range of frameworks, but for the sake of getting things done, I clearly need to narrow the focus.

I guess one concrete goal would be to post here more often.  If I’m doing that then that means I have been doing work, so that’s a win.

Moving On From Parse

My last post mentioned that the backend for all of my Android apps Parse was halting service early in 2017.  This meant all of my apps would stop working.  Nobody might ever notice except me, but still…

I was faced with a few options:

  1. Run through the Parse-approved migration to MongoDB/Heroku
  2. Setup my own backend and host it myself
  3. Find a roughly equivalent online service to switch to

I tried each of these choices with varying levels of enthusiasm.  The results…

Run through the Parse-approved migration to MongoDB/Heroku

I wasn’t very excited about this because well, MongoDB hosting a Parse Server on Heroku?  I don’t particularly care to go in depth in any of those three.  Nevertheless, if this was going to be a simple switch I thought it was worth doing.  It wasn’t.  I admittedly didn’t put much effort here, but I ran into issues every step along the way I did manage to attempt:  getting my data into Mongo, getting Mongo into Heroku, etc…  This was a while ago now so I forget the details, but after one night of annoyance, I threw in the towel here.

Setup my own backend and host it myself

This was much more appealing because I’ve been messing around with various server side frameworks for a while but never found anything to deploy.  This idea quickly dead-ended when I discovered how difficult it was to deploy any of the big frameworks to Dreamhost (Django, Rails, Flask, etc…).  I wasn’t ready to give into Heroku yet, so I moved on.

Find a roughly equivalent online service to switch to

I put this mess down for a few months after step 2.  I worked on other things and (more frequently) didn’t work on much at all.  Eventually I happened across a Reddit thread about back-ends for Android apps.  Somebody suggested Firebase which I had heard of but not looked at in a while.  Apparently they were purchased by Google, who knew (besides anyone paying attention…)?

This looked promising. It promised much of the same as Parse.  Single back-end to be used cross platform.  Authenticated users.  Analytics.  Etc…  I jumped in.

The Good

The API was incredibly straightfoward.  Like amazingly simple.  It took under 20 minutes for me to switch one of my Parse calls to a Firebase call in an app and start receiving data. I mean, 20 minutes?  The calls were much simpler as was retrieving and parsing the results of those calls.

The Different

I hesitate to use “bad” here because it was more unexpected than a negative for me.  The Firebase database is a JSON database.  Everything you enter has to be in JSON.  I’ve never taken more than a small baby step outside of the world of relational databases, so this was a shock.  Not bad, just different.  This changed the way I had to store the data and, more importantly, how I cross referenced data.  This required some thought, luckily the first app I was porting was the simplest of my three so it wasn’t bad.

Wrap It Up

So there’s what I did. Tried what should have been the easiest thing (migrating using a set of instructions written by the Parse team), the hardest thing (write my own), and the one in the middle (Firebase).  I ended up in the middle and found a great service in Firebase.  If someone has a Parse (I forget what formats they let you export to?) to Firebase DB conversion tool that would be amazing.  As it is, I’ll soon be finished with one out of three apps.  I will have remaining two apps worth of very simple code changes (Firebase is that easy, seriously, try it) and a mountain of data to transfer over.  Typing out loud gave me the idea of writing an app to read in Parse and export to Firebase, maybe that’ll be the subject of my next entry here…

Parse – Lessons Learned

Well damn.  If you wander to the “Projects” section of this website you will see my Android apps are all Parse-based.  If you are a Parse user yourself, you are probably now aware of today’s announcement.  This sucks.

I chose Parse because it was straightforward.  I wanted to spent my time developing my app, not deploying, updating, migrating, and whatever else-ing a database on my server.  Parse allowed me to do that, pretty easily.  There was some headache with earlier versions of Parse which required a Javascript middleman between the app and the database to perform certain queries, but hey, any chance to brush up on a rarely used language isn’t that bad.  I then went through the pain of upgrading my apps when they put the API through a fairly major overhaul.  It was worth it because it allowed me to ignore that entire side of the app.  My data would be sitting on a Parse sever and would be easily accessible, no worries.

Now that is going away.  Parse is officially recommending a slow migration to a MongoDB setup followed by a hosting switch where you can run the new open source Parse Server to connect to your fancy new MongoDB instance.  Blerg.  I’m not sure what I’m going to do, I like the fact that I have working apps available, but they aren’t exactly tearing up the Google Play store rankings, so I have to decide what level of effort is acceptable to support essentially unused apps.

The lesson here, I guess, is to be weary of anybody offering you a sweet free service.  Or, if you want something done right, you have to do it yourself. Or something else, I don’t really know.  For now, I’ve got a year to switch away from Parse or let my apps die a slow, quiet, unnoticed death.

New App Launched

Last year I spent a few weeks putting together a simple Android app for my brother (Garage Games). It was a straightforward app for the most part, I learned a little about using the Parse framework, image loading, etc… but the main goal of the app was to actually deliver something to the Play store. I had been playing around with Android development, off and on, for a year or so but never had anything I was invested enough in to see to completion. I figured by releasing something I would break the dam and start becoming a prolific app developer.

Fast forward a year and it is still the only app I have to my name. Not a big deal, lack of ideas, life getting in the way, it happens. I did decide to think about a manageable project I could get done with limited time over the course of a few weeks or months. Enter the Middle Creek Disc Golf App (Google Play Store Link). I play disc golf, I enjoy it, but I have a lot of friends who REALLY enjoy it, so it is always a topic of conversation. It is also a rapidly growing sport, in my area there have been a handful of new courses opened or started to be built over the past couple of years. Point being: there might actually be a market of people out there willing to download an app related to the sport.

I won’t go into the details here, but the app basically provides an overview of a specific disc golf course in my area. A scorecard, hole overviews, playing tips, etc… the kind of stuff you would expect to see in an app dedicated to a golf course.

The real point of anything I do on the side is to learn something new. There were no new technologies in play here, I used Parse again to store the data being loaded by the app. I did spend a lot of time in GIMP generating pretty pictures, but that isn’t exactly a resume builder. So, what did I actually learn? Honestly, not a whole lot that I hadn’t done before.

So, with no obvious technical advantages to developing this app, why do it? Mainly because I wanted the experience of developing something with the hopes of strangers downloading it. My previously published app had an audience of about 10 people. The hiccups and quirks could be overlooked because everybody who would be downloading it knows me personally. Optimize the image loading and caching? Nah, no need…polish up the visuals for a consistent look which follows the Android standard guidelines? Why bother?

Also, having just launched the app, I’m looking forward to seeing how it does, or doesn’t, get off the ground and find an audience. With an audience comes honest scrutiny which is important. I think it looks okay, passable at least, but will others uninstall immediately after seeing my poor excuse for a popup dialog? I don’t have any illusions that this will get hundreds of installs, but if it even makes the rounds through my disc golfing friends and friends-of-friends, it will be a new experience in having a product reach a wider audience than a small circle of friends.