Well, it has been over a month since I've posted here. My wife and I had our first child, and I grossly underestimated the demands on my time. But, it's been amazing and I don't regret putting my hobbies on hold.
The football season is more than half way over. I love betting on football, and I still believe there is a need for helping to track bets. That's why I love working on this app, because scratching your own itch is when writing software is the most rewarding.
I've come a long way with the application, and I still intend to get into usable shape. But, you know, priorities, and life, and stuff.
Sunday, November 24, 2013
Saturday, October 19, 2013
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.
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.
Sunday, October 13, 2013
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!
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!
Thursday, October 3, 2013
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!
Tuesday, October 1, 2013
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!
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!
Monday, September 23, 2013
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!
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!
Tuesday, September 17, 2013
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!
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!
Friday, September 13, 2013
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!
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!
Wednesday, September 11, 2013
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:
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....
Monday, September 9, 2013
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.
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.
Friday, September 6, 2013
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.....
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.....
Wednesday, September 4, 2013
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...
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...
Monday, September 2, 2013
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
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
Sunday, September 1, 2013
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:
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.
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.
Saturday, August 31, 2013
Git
Learning git, finally. I've been using TFS and things like it (subversion) for a number of years now. When it comes to source control and builds, I'm definitely a believer in the critical importance of them. On the current contract job I'm doing, they told me they couldn't get me a TFS build for my project on their build server, because of blah blah. To me, that's like asking a pilot to fly without all his instruments being functional. You wouldn't do it, it's a safety violation. So I had to turn my own workstation into a build server using TeamCity (free).
Anyway, I'm getting my new project, AR, all framed out and setup on github. And I have to say, there is a bit of a learning curve. But I'm plugging away at it. It's important to me that the source code that's in source control always builds and has its unit tests all green and happy. Yeah, I'm kinda anal like that.
So I did some coding on AR this morning. This OCR library that I found, tesseract (http://gaut.am/making-an-ocr-android-app-using-tesseract/), was a little more unwieldy than I had hoped. I'm spoiled by all the free libraries that I can add from NuGet in a couple of keystrokes. For this OCR lib, I had to download the open source from GitHub, and then get CygWin and the Android NDK, and actually get it to build. Then I had to import the module into my Android project in IntelliJ. I really wanted to just reference a jar file, but I ended up checking all this code in to source once I got it building and working.
So doing OCR is apparently very processor intensive. It probably makes sense to farm the work out to a server somewhere, but I'm doing it right on the phone. My big stride I made this morning was putting that work into an IntentService and getting it off the GUI thread. Yea!
After that, I decided to see if my source base was actually valid. So I downloaded the code from GitHub to a different location on my machine and built and ran. It built and ran. It also crashed when I ran it. So I used Beyond Compare to compare the folders of my working version versus my freshly checked out version, and I found some libs folder under this tesseract OCR library that I hadn't checked in. The .gitignore file screened out the folder. Apparently this native android code business does some runtime linking or something.
So that's the update. It's going a little slow but I'm moving forward.
Anyway, I'm getting my new project, AR, all framed out and setup on github. And I have to say, there is a bit of a learning curve. But I'm plugging away at it. It's important to me that the source code that's in source control always builds and has its unit tests all green and happy. Yeah, I'm kinda anal like that.
So I did some coding on AR this morning. This OCR library that I found, tesseract (http://gaut.am/making-an-ocr-android-app-using-tesseract/), was a little more unwieldy than I had hoped. I'm spoiled by all the free libraries that I can add from NuGet in a couple of keystrokes. For this OCR lib, I had to download the open source from GitHub, and then get CygWin and the Android NDK, and actually get it to build. Then I had to import the module into my Android project in IntelliJ. I really wanted to just reference a jar file, but I ended up checking all this code in to source once I got it building and working.
So doing OCR is apparently very processor intensive. It probably makes sense to farm the work out to a server somewhere, but I'm doing it right on the phone. My big stride I made this morning was putting that work into an IntentService and getting it off the GUI thread. Yea!
After that, I decided to see if my source base was actually valid. So I downloaded the code from GitHub to a different location on my machine and built and ran. It built and ran. It also crashed when I ran it. So I used Beyond Compare to compare the folders of my working version versus my freshly checked out version, and I found some libs folder under this tesseract OCR library that I hadn't checked in. The .gitignore file screened out the folder. Apparently this native android code business does some runtime linking or something.
So that's the update. It's going a little slow but I'm moving forward.
Welcome
I've recently embarked on writing my second Android app. My first one, Tapster, was kind of a novelty app that was built to entertain me and my colleagues while working at PerTrac.
This new app, working title ActionReaction, came about as a means of scratching my own itch. I use William Hill sportsbook on my phone (http://www.williamhill.us/). It is legal in Nevada, where I live. Anyway, I spray around a bunch of little bets, mostly on football, as a means of entertaining myself. Well, the app is good for getting your bet in, but not good for much more than that. So I'm writing an app that will help me track and follow bets, hopefully with some real time updates when scores change and so forth.
So, with that being said, I started writing the app this week. The basic toolchain is:
This new app, working title ActionReaction, came about as a means of scratching my own itch. I use William Hill sportsbook on my phone (http://www.williamhill.us/). It is legal in Nevada, where I live. Anyway, I spray around a bunch of little bets, mostly on football, as a means of entertaining myself. Well, the app is good for getting your bet in, but not good for much more than that. So I'm writing an app that will help me track and follow bets, hopefully with some real time updates when scores change and so forth.
So, with that being said, I started writing the app this week. The basic toolchain is:
- IDE: IntelliJ IDEA 12
- Android Platform: 4.2.2
Some risks:
- If I move out of the state of Nevada, I can't use the app and the project is basically dead
- I probably can't put it on the Google Play store, as they frown on gambling. You currently have to download the William Hill app from their site, you can't get it on Google Play store. This sucks because it cuts of a big distribution channel.
With that being said, it's still fun to write apps that have a purpose, rather than contrived ones that you're not really passionate about. So I'm going for it.
One of the things I needed was OCR (Optical Character Recognition). After placing a bet in the William Hill app, the best you can get for a summary is a screenshot. They give you no email, no copy past ability, nothing. So the best workflow I could come up with is to screenshot the summary screen, and then share the picture with my application.
Through the use of Intents, my application (I'll use the abbreviation AR for my app) will take the image and parse the text out of it. Then I'll have to model the domain and turn this information into tickets,or bets, with types (parlay, straight bet, etc). At this point, I'm thinking of calling into some web based API to get scores or live updates, so that I can notify the user that some action is happening in his game(s).
I'll try to keep this blog updated as much as possible and chronicle my efforts as I go. Stay tuned!
Subscribe to:
Posts (Atom)