private repos

I think Hall & Oates had a song called Private Dancer.  Nope, just googled it and it's Tina Turner.  Anyway...

Ok, I know github.com is all the rage, but dammit, I'm not ready to share all my hard work with the world.  So I've decided to go private.  This post sums up my sentiments:

http://somatose.com/2011/10/from-github-to-bitbucket-in-60-seconds.html

So we live in a world where people won't pay $7/month if there is a free alternative.  What can I say.  It's a slippery slope, because as soon as I go with a private github repo, then travis ci wants to charge to integrate with a private github repo.  Now it's almost $20 a month!  That's like 4 beers at Great Basin Brewery!

I'm embarking on these projects mostly because I get off on developing, and especially on learning new stuff.  But I also like to control my assets.  I know that listing a public github repo on a resume makes it really easy for a potential employer to look over your "portfolio", but oh well, I'm gonna go with the proverbial "available upon request".

I'd like to get an app on the app store anyway, and let the finished product speak for itself.

As for dev details, I dusted off the Tapster project after having lunch with my friend/former colleague Nick W. last week. It was his idea to mount a phone to a keg and make it do cool stuff to begin with.  That codebase is surprisingly in good shape.  It was my first Android project and I learned quite a bit.  Some things I did different on AR/Trakker versus Tapster:

Tapster:  All external dependencies I went and found the jar file, put it in a libs folder, and checked it into source control
Trakker:  I discovered Maven.  Nuff said.

Tapster: I actually used Dagger for Di
Trakker:  I fiddled with Dagger again and chose RoboGuice because it seemed easier.  Weird when your former self could figure out something your present self couldn't

Tapster:  Wrote my own data access layer in the "standard" Android way.  No ORM tools.  Old fashioned SQL statements.
Trakker:  Went with OrmLite.  Did I mention I hate SQL?

Tapster:  Had my college roommate Big Bill design me a sweet pint glass for an icon.
Trakker:  Still using stock icon.  Need to make pretty.

Tapster:  No CI
Trakker:  Travis CI.  Although, as mentioned above, I am about to turn my workstation into my own CI server and ditch paid services. At least until if/when this turns into more than a hobby.

Learning and experience are awesome.  Want more.

Root

Well, my wife and I had a big week.  Our son was born on Wednesday, Oct 9th, 2013. I took a week off work and I'm hanging out with my son...pretty awesome.  He's laying in his bassinet next to me now as I try to sneak in a little dev time.

My current challenge is that Google Play Services does not play well with the android emulator.  Ok fine, use a physical device for development.  Ok, but when I try to adb to the device and browse to the data folder, I get a permission denied.

So I'm rooting my phone so that I have a nice "dev" device.  It's not my main phone, but it's a Nexus S 4G that I bought off ebay a couple years ago for my Tapster project.

So that's what I'm up to.  Learning to be a dad, and rooting android phones.  We are in week 6 of the NFL season so I would like to get the basics in place and get version 1.0 onto the app store, if possible.

Stay tuned!

The burden of CI

Man, I'm hooked on the ease of Maven dependencies now.  You just add a little snippet of xml and you're golden.  So my new dependencies are google-play-services (for Gcm) and compatibility-v4 (for WakefulBroadcastReceiver).

There is a cool project that will just put these into your local maven repo, so that you can add your little xml bit to pom.xml, it's called maven android sdk deployer (https://github.com/mosabua/maven-android-sdk-deployer)

So, now I'm fiddling with my travis.yml file to make sure that it downloads the proper bits and puts things in the right places.  My unix shell skills are rusty, but i'm shaking off the cobwebs!

Android / Azure

Well, I created a simple azure website and published it out to Azure hosting.  I am able to use PushSharp on the backend to send my Gcm notifications to my phone.  Life is good.

I still need to get the android app to register with Gcm & my server when it starts up.   There is some good sample code available to demonstrate this, so it shouldn't be too much trouble.  The thing I'm struggling with a little bit is understanding Android application entry point.

I have an Activity that is registered to receive share intent from photo gallery.  This is not the same Activity that is marked as my startup Activity.  All the sample code for using GcmRegistrar to set up the client phone with Gcm shows it happening in an activity.  It would seem to make more sense to me to do it in the Application class, as that code seems guaranteed to run everytime, regardless of which Activity is the startup activity.  Anyway, it would probably be better to post this to SO or some place that I can get some help, rather than talking about it in my own private blog that no one reads :)

In non-dev related news:  my wife and I will be go from DINKS (dual income no kids) to parents next week, so that should be an interesting life transition.  It's not a new chapter, it's a whole new book!

GCM - PushSharp

I got my first push notification working this weekend.  I found a cool library called PushSharp, where someone wrote a C# implementation of push notifications for all kinds of different platforms (Android, iOS, Blackberry, etc.)  It's really well written and easy to use.

I've got some basic Mockito working for unit testing, but I had to put setters on my business objects to allow the injection, and I had to manually inject the mock when running the unit test.  I know there is a way to do it using annotations only, but I spent too much time trying to figure it out and then moved on.

I also got my local database reads and writes working using OrmLite.  So I've got that going for me .. which is nice.

Oh yeah, on the topic of getting score data.  I am going to switch over to an MS-NBC feed that supplies structured data in JSON form.  My plan now is to have all the score collection run on the server, then push the data to the client devices.

I still need to write the logic that actually analyzes the bet tickets against the actual scores, and then update the user that a ticket is won/lost or, in the case of a parlay, dead or alive.  I would like to have a notification to the user like "Game 1 of 4 final, 3 more to go!" .  Or "Parlay ticket is dead, because Steelers did not cover"

I'm still having a lot of fun writing the app.  The thing that I battle is deciding whether to read all the Android design guidelines and best practices, or just cowboying through it with the nagging feeling that I'm doing something wrong.  I'll probably go with option B, because hey, it's a hobbyist project and that option is fun!

Android Dependency Injection

Dependency injection is just good practice.  It makes your code more testable, decoupled, readable, and whole bunch of other good things.  I've been using a Unity IoC container for a project at work, using the PRISM framework for a WPF app, and it really has spoiled me.  When I need a service in a new class that I'm writing, I just put it into the constructor and the framework takes care of the rest.  Nice.

I'm not opposed to "poor man's DI", which is DI without a framework.  I watched a Greg Young talk recently where he basically said frameworks=magic=bad.  I tend to agree somewhat.

It turns out you can't do DI in Android development without a framework.  The core building blocks (Activities and Services) are new'd up by the Android framework.  You don't get a chance to inject your dependencies.  For example, when you send an Intent, you never really get the opportunity to inject any dependencies.

So I went shopping for a DI framework for Android.  My only criteria was that it had to cost exactly zero dollars:)

Everyone is hyping up Dagger, because it is faster when the app starts up.  I found it cumbersome, and went with RoboGuice.  Less friction for me to get it working.

Now, I need to look into how to mock these dependencies when I write my tests.  RoboElectric seems promising.  Mostly because anything using the Dalvik VM is painfully slow, and they claim to allow you to test using just the JVM locally.

I know it seems like I am focusing more on doing these "setup" tasks rather than just cowboying some code.  And it's true.  It gets frustrating for me too, because I want working software.  But this effort is more than just about working software, it's about learning and instituting good practices so that maybe I can gain velocity later.  We'll see!

Android ORM

Well, I came to the point that nearly all apps arrive at:  the need for persistence. I'll admit it, I am not a database guy.  They don't excite me.  I don't like talking about indexes, query plans, triggers, schemas, etc.  None of that shit.  I'm a coder, and storage is a necessary evil that I would prefer to have abstracted away.

So my needs for this project (AR) are that I will be creating a Ticket object, which consists of one or more Game objects.  Think parlay ticket if you are a sports bettor, or a single game "straight bet".  My business objects are fairly straightforward.  For the last Android app that I wrote, Tapster, I wrote the data access layer "by hand".  Some people contend that ORM frameworks are evil and afford you less control, and they are probably right.  But I don't want to mange table creation nor write tedious sql.

What are my options?  I could use a traditional sql relational database.  I could use a NoSql option like Mongo or Couch.  I can persist locally.  I can persist to the cloud.  I can do both.  I should probably go read a best practices document for android storage patterns.

I've decided to start with a local SqlLite db.  I also went looking for an ORM framework for Android, because like I said, I'd prefer the CRUD to be magically taken care of for me.  I found a couple, Green DAO and OrmLite.  I settled on OrmLite after reading one testimony on StackOverflow.  Pretty diligent on the research eh?  It really came down to quality of documentation and abundance of sample code.

So, one thing that bugs me in the Android world, and I've seen quite a bit of it, is that every framework wants you to inherit from their base classes.  OrmLite is no different.  I don't like to "commit" to a framework like that, so I don't want to intertwine my code with theirs.  When I decide later to swap it out, I'd like it to be painless.  I guess this is where programmers prove their worth, by going the extra mile to isolate things.

Anyway, I'm looking forward to spending some time this weekend on the app and hopefully get a preliminary version working.

Adios amigos!