Monday, February 23, 2015

30 Day Android Challenge - Week 4 (Final)

I've completed the challenge and published my first android app,  Spender

In 30 hours over 30 days, you can go from a complete novice android developer to publishing an app on the Google Play Store.

So there you have it, my first app, done. Reactions from family and friends have been "Wow. Really? You're writing an app.. What does it do?". My response is "It won't make any money and its more about going through the process". I wanted to write any app rather than just thinking about writing an app.

Tuesday, February 17, 2015

30 Day Android Challenge - Week 3

You can now edit categories and set budgets for each one. Also a summary report page showing you total spend in each category alongside the budget amount.

Buy vs. Build.
To store the data, I initially wrote to a file but this week refactored it to use greenDAO. An ORM tool that makes it easier to work with sqllite. I knew I'd have to end up using sqllite - but deferred using it until I absolutely needed to. Doing so revealed the limitations of using flat files. Its fine for simple data structures and simple access. Also i didnt want to work with sqllite directly as it can be tedius, crafting together SQL. I needed speed and agility and so using an existing ORM solution is a huge timer saver.

Stretch objectives.
With only 5 days until publishing. I did take some risks over the last few days where I planned to add a few extra features and do the persistence layer refactoring from flat file to a sqllite solution. I estimated it all and sketched out the UI.

The app is far from a polished product, but it is fairly usable. Next few days I will add one final feature to move back and forth between reporting months. Then it will be bug fixing, general UI tweaks and then getting the marketing material done and then finally publish.

T-5 until launch!

Monday, February 09, 2015

30 Day Android Challenge - Week 2

Its day 15 and I’ve published an alpha version onto the play store. Three family members have downloaded it and provided good feedback. It took longer than I thought to publish the app. The APK had to be signed and zip aligned. The google store front requires minimum two graphics, two screenshots and descriptions. 

What and why did I publish it?
You can use the app to enter your spending, view it as a list grouped by date and the data is persisted. Very basic.

I published it for the feedback and to get an idea of the whole cycle. In my early days as a programmer, I read Pragmatic Programmers. It talks about Tracer Bullet Development, which is, for example writing the login functionality from front-end to back-end. The functionality hits all layers in the Architecture. The idea is to reveal any issues around integration, sooner rather than later. Now I know what steps are needed, I can plan better towards the end goal.

By keeping a timesheet, I can see that I’m averaging an hour per day on this which helps with the planning. One of the principles of Agile is coding for today and the future will take care of itself. Or, YAGNI. When it came to data storage. You can store the data to disk in CSV, append mode, to a file. This was quick and easy to implement at the time and served my purposes. I know I’ll probably re-implement this using sqlite and I’ve deferred this to future versions.

I have been quick to drop tasks that was taking too long. Like changing the action bar was taking too long so I just scrapped it. 

Being Agile
As this is a time boxed challenge with only a number of hours available to spend. One of the principles is to code for today and the future will take care of itself. Well, when it came to data storage. I very quickly decided to write the data as a CSV, in append mode, to a file. This was quick and easy to implement and at the time it served my purposes. Now, given that I do and may have time to do more fancy reporting - I may start looking into sqlite.

Hitting that wall of resistance
I admit that its getting a little hard-going. As with any project, the initial enthusiasm is starting to wear out. I’m surprised I’ve made it so far, doing this consistently for minimum 30 mins / day.

Looking at the other apps out there, and while its a good source of inspiration. On the flipped, its easy to feel deflated. These apps are rich in functionality with many thousands of downloads. So its difficult to imagine my app being successful. For my purposes, I have to put my head down and focus on the next step. Occasionally I think too big a step, and have to scale it back. Lets just work out how to create a Settings Activity and open it from the action bar. With appropriate navigation back to the Main activity.

Thinks small steps, a little progress is better than no progress...

I leave you with screenshots of what the app looks like now:

Monday, February 02, 2015

30 Day Android Challenge

If you’ve ever wanted to write an Android app. My suggestions to you is to just do it and figure out a way to get yourself to do it. Set yourself a 30 day challenge!

Last week I set myself a goal of publishing an App in 30 days. This will be a stretch considering I know little about how to write Android apps, let alone publish one.

To make this happen I've committed to least 30mins of coding everyday. Told my family and friends about this app. Although I did keep quiet until day 5 when I had some momentum, and believing this can be done. That I can win.

The app itself is based on a question I had at the beginning of the year. How much am I actually spending vs what's budgeted? So I started doing this on a spreadsheet. Every weekend, I went through bank statements and scraps of paper or receipts.  I'm now turning this process into an App. Something that I want to use.

Day 7 screenshots:

Its been a super interesting journey so far with all sorts of ideas and thoughts wrecking around my head. I’m  treating it like running a business and have been making plans, doing a timesheet and thinking about how to sell this, how to market this and talking about it with family and friends. I’m being agile and never forgetting the need to write an app that is helpful and easy to use, providing value to the end users. When you average an hour / day working on this you have to be :-)

If you want to get started with Android development, there is no better place to start then here - Download and install Android Studio + SDKs and get cracking!

Happy Android Developing!

Monday, January 26, 2015

Unit Testing - Trustworthiness

My notes from Effective Unit Testing Ch. 6 - Trustworthiness

If you can’t trust your tests, then you cannot be confident your change has not broken anything.

  • Commented-out tests. Provide no value as they’re not executed. So either fix the test or delete it.
  • Misleading comments. The code should communicate the intent, not comments. So refactor by using good names or replace comment with method. Comments should say why, not what the code is doing.
  • Never-failing tests. Use @Test expected attribute to guard against old style tests that have assertions in the catch block. If the test doesn’t throw an exception, no assertions performed and the test incorrectly passes.
  • Shallow promises. Tests with no assertions, misleading method names or nothing at all in the body. So fix/refactor.
  • Lowered expectations. Assertions that are too vague or loose. So raise the bar and be more specific. These tests typically pass even if the underlying functionality broke.
  • Platform prejudice. 
  • Conditional tests. All execution paths should have a chance of failing. So add any missing assertions and replace conditional logic with new test method to cover it.

As a developer there are times when I instinctively don’t trust the tests, now I know what to do about it :-)

Monday, January 19, 2015

Unit Testing - Maintainability

My notes from Effective Unit Testing Ch. 5 - Maintainability.

  1. (Duplication) Remove duplication from your tests so that its intention and function are clearly expressed.
  2. (Conditional logic) Avoid complexity and remove conditional logic.
  3. (Flaky tests). Any tests that involve random numbers, system time or threads are flaky and non-deterministic so may fail randomly. So, either avoid, isolate or control it.
  4. (Crippling file path). Avoid absolute file paths, replace with relative file paths or read from the classpath.
  5. (Persistent temp files). Beware of tmp files that interfere with other tests methods. For example, a temp file may linger longer than you expect and not actually deleted until the JVM exits.
  6. (Sleeping snail). Avoid Thread.sleep and replace with concurrent package concurrency constructs (CountdownLatch). 
  7. Parameterized mess.
  8. (Lack of cohesion in methods). Where tests don't use all of the test fixtures. So either coerce your test methods into using them. Split the test classes or create the test fixtures in the methods with utility classes in their own separate classes.

Tuesday, January 13, 2015

Unit Testing - Readability

I recommend Effective Unit Testing as reading it makes me want to improve my tests now! Its after work hours, so instead, I’ll summaries the chapter as a checklist.

Checklist for Readability (Ch. 4)

  1. Does your tests inform what it should do. Assertions, what it does do. And its easy to read?
  2. (Primitive assertions) Are you using too many low-level assertions for high-level abstractions? If so, improve the readability using JUnitMatchers
  3. (Hyper assertions) Are your assertions balanced. Not too broad that it breaks easily (brittle). Not too fine-grained that distracting? If so, improve with helper classes and splitting tests to leave behind the essence of the test.
  4. (Incidental Details) Does your test setup include too much detail? If so, refactor to aid understanding by extracting to set up and helper methods
  5. (Split personality). Is your test testing too much? If so, split into separate tests and group them into separate test classes.
  6. (Split logic) When reading your tests, are the pieces scattered? If so, inline the data. Use your judgement on using inlining, factory or separate data file. Aim for readability.
  7. (Magic Numbers) Replace magic numbers with constants or method-based approach.
  8. (Setup sermon) Do you have a convoluted set up, operating at the wrong abstraction-level? If so, extract methods with nice names and strive for the right abstraction level. Is there a design problem forcing difficulty when testing?
  9. (Overprotective tests). Are your assertions overprotective with scatterings of null checks which distracts the reader? If so, delete.