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!

Android CI - finally

I finally got my github -> travis ci stuff working.  It took me a while to settle on a project structure. I finally figured out that in the java world it is normal to co-mingle you test code with your production code in the same module.  I was bent on creating a separate module for testing purposes for a minute there.

So what I have is this:

• android project (the entry point, if you will, where activities are defined, etc)
• android library (builds as apklib, where I plan to do non-gui stuff that is still android-y, like services)
• pojo library (plain old java objects, where a lot of my business objects and logic are defined.  also junit tests to exercise said classes)
• android test project (instrumentation tests that run on AVD)

These were all built by using Maven archetypes, from this guy (https://github.com/akquinet/android-archetypes).  Thanks guy!

So I put in some of the logic that I already had prototyped out.  And now, we have a "clean" start.  I'll have to revisit the Gradle stuff later, but from what I understand, if your project follows a Maven-esque structure, then it's a short hop to Gradle land.

Now I want to get GCM push notifications going to the app on the device.  But I also want to work on the client side stuff too!  Ahhh!  So much work to do.  Gotta go....

Maven

Ok, I flailed around long enough with Gradle.  I really wanted to make it work, because it seems to be the way forward as the official Android build tool.

As I said before, I found a cool OCR library on GitHub.  I just want to reference the library though, I don't want to always be building, and I won't ever want to modify the code.  So I Mavenized by following this post:

http://www.jameselsey.co.uk/blogs/techblog/tesseract-ocr-on-android-is-easier-if-you-maven-ise-it-works-on-windows-too/

So now I just install this apklib to my local maven repo on my Travis CI build, and use "mvn clean install" to build my whole project.  It'll do for now.  I just couldn't let the CI thing go, but I need to get to coding.

Vagrant, GCM, Travis, Gradle, oh my

Holy shit. The number of paths you can go down when embarking on a dev project. Even as a one man team doing a hobbyist personal dev project, you end up having to have some kind of prioritized list to work from. Otherwise you become a raccoon chasing every shiny object you see. It's unbelievable.

So I found a public feed that espn uses for their Bottom Line app:

http://sports.espn.go.com/nfl/bottomline/scores

I wrote some sweet code using regular expressions to grab the scores from this ugly url encoded mess. I was pretty proud of it.

Then I thought, "I don't want to poll this url from the phone. I want to poll this url from a server and push updates to the phone." That's when I got off on the GCM (Google cloud messaging) tangent. I ended up setting up an apache server and running a .war java web app file. Pretty brave stuff for a .NET guy.

I also wanted to play with Android Studio because it seemingly has tight Gradle integration, and that supports my cause of having a CI build somewhere in the cloud that requires a build script.

So anyway, I'm just chasing shiny objects at this point. Happy to have the time to do so. My wife and I are expecting our first child in 4 weeks and I know that quiet time in front of the computer takes a massive hit.

Back to it.....

Gradle

Well, I've spent some time looking at Gradle, as it seems to be the new shiny toy in town for Java folks. From what I've read, it lives somewhere on the continuum between Ant and Maven. I set up a Travis CI build and hooked it up to my GitHub repository. That part was easy.

The part I'm flailing on is writing the Gradle build script. I spent a few hours on it, and now I'm wondering if I should defer that effort and go back to writing code. Football season is upon us afterall.

Speaking of code and design, my initial thought for building the app was that I would be able to retrieve live scores via some public feed. After having looked into it, it seems everyone wants to charge for that data( which of course makes sense). Data is gold. Especially data that changes. I know that I could get sports scores in a kind of skeevy way by ripping off ajax calls or using rest api's against their user agreements. That would kind of illegitimize my application though.

So for now, I need to get the data, keep from coupling that implementation to my core application, and swap out that data provider later.

I'm going back to coding, and I'll revisit this CI build thing later.

By the way, I'm kind of struggling with the accepted patterns for laying out a java project. In Visual Studio,I've always implemented my core business logic in dll's, and kept UI stuff with the main entry point. Although I'm currently working professionally on a WPF app utilizing PRISM framework, and that's kind of given me a new perspective on composite architecture.

Anyhow, every talks about Maven as being a bit of a nazi on enforcing project structure, and it wants it to look like this for a java project:

Project-parent-folder: -Android-Application-folder -pom.xml -Android-Tests-folder -pom.xml -Android-library-project-folder -pom.xml -pom.xml

The thing that's foreign to me is how a java project reflects exactly how the files and folders are on disk, while a .NET Visual Studio solution seems to abstract the "how it lives on the file system" part away. I know I risk sounding like the guy who is dogging java because I don't understand it, and I don't want to come off that way. Visual Studio is just my reference point after spending years there.

Anyway, back to the code...

Continuous Integration

I've made some progress on the coding side. I have AR parsing the bet confirmation screen and creating my own Ticket object from that. I'm quickly learning how to use git, at least for my minimal needs.

Like I said in a previous post, I'm kind of a stickler for end-to-end. Maybe to a fault. I like to thing about deployment up front, and I always, ALWAYS want my build to be green. So today I'm looking into Travis, which is an automated CI tool that's tightly integrated with github.com

I just want a build to fire on some server somewhere when I check in. I want it to run my unit tests. I want it to report green/red (success/fail). That's it.

Speaking of unit tests. I spent some time yesterday looking into unit testing capability in IntelliJ with Android. Coming from the VS/.NET world, I am pretty comfortable with MSTest, and I've used nUnit also. In that world, the test project was always its own assembly. In the Java world, a project is the big container (like a solution in VS), and the module is an assembly (like a project in VS). Anyway, in the Android world, a test module has a lot of scaffolding to actually run your tests on the emulator Dalvik VM. It is meant to test Activity, Service, etc. The core building blocks of an Android app.

Well, I was writing parsing code in Java (take Android out of the equation for now). I just want to quickly run the unit tests as an entry point into my parsing class. So I opted for a JUnit test over the Android Test. The biggest benefit here being speed. Anything relating to the Dalvik VM is excruciatingly slow. The JUnit test fixture is much more analagous to MSTest. You just decorate your test methods with a @Test attribute, and run the tests. Super nice.

So with football season upon us, I'm trying to get something in place. I want to share my app with some friends who bet on Android using William Hill and see what they think.
back to the code .... and the build

Structured and Unstructured data

I used to work with a guy who would spout off statistics about how much of a business' data was in unstructured form.  Sitting in filing cabinets, in people's heads, in their outlook inbox.  We were working on a CRM project, where the name of the game is structuring all the data pertinent to customer relationships and how the business runs.

Anway, I was thinking about that when I was coding AR. Here is a typical image that I would be processing:

Here is a result of feeding that image through the OCR processing library:

Confirm Bet
        Bet Confirmation
        RODNEY SMITH (4292)
        Ticket Id: 141 C-B5C9-8229
        $4 Straight Bet
        31-AUG-2013 BI: 923 MARINERS -103
        MONEY LINE
        Cost: $4
        Payoff: $7.90
        Your bet has been placed.
        'Ticket Id’ is your confirmation.

One thing that is weird about this is that the "fi" in the word confirmation is actually a single ascii character (ascii code 64257).  So if I test for the sub-string "confirm", it returns false.  So I have the classic problem of trying to scrub data that I'm not in control of.  It is compounded by the fact that the OCR, which does a fantastic job by the way, will not reliably give me back english strings as expected.

I am trying to get this data into a DTO class that looks like this:

public class Ticket

{

    DateTime dateTime;

    Money wagerAmount;

    String sportsBook;

    BetType betType;

    List<String> games;

}

So I am basically writing tedious parsing code that takes raw text and looks for certain keywords.  If William Hill decides to change the way they present the data, my parsing code is broken and my app is broken.

Sounds like a perfect case for placing the parsing logic behind an interface, so that I can have multiple implementations of said interface and keep my architecture nice and clean.

So that's what I'm working on now.  Also, I had always heard that Joda Time was a superior DateTime library to the native Java api, so I went and added that via Maven (which is like NuGet for Java projects) and it was pretty painless.  Also ran across Joda Money class, so figured I'd use that too for the wager amounts rather than straight float or double.

Anyway, I'm going back to coding.