Adding more functionality

I've spent this afternoon getting back in to developing my Driver Tool app having not contributed to this project in quite a while. I would like to get back working on this on a regular basis and try get it published on the android market place so that I can start using it.

Today I completed the functionality of the settings menu, for selecting either metric or imperial as a measurement system. A user will be prompted with this menu upon first installing the app. Once the user has selected their preference they are not prompted upon app start up again. They can access the options menu through the menu button. I've also included the functionality of adding and deleting a car with an options menu which operates more or less in the same way as the transaction adding and deleting functionality. I've give the user the option to enter in the manufacturer and car model themselves when adding a car. I may update this in the future to populate a selection of drop down menus from a database of makes and models. Due to the tedious nature of populating such a database I've left that out for now.

There are a number of things that need to be done still which I'm going to start on. The first of these things is the tyre pressure calculator. I'm going to get back in to OpenGL for this. I'll have to come up with a spec for this part of the app, because I've only a couple of concept ideas in my head right now. I suppose I should probably remove the tab and finish up testing the already implemented functionality to push for a release. One of the other things that still needs doing is to build non-place holder assets for the menus and tabs, and work on the styling of the app. I think I would like to change the background from the standard black.

Measurement systems

Over the last couple of days I've made a number of changes to the Driver Tools app. A lot of them were purely aesthetic, however the biggest change is the addition of a static settings class for storing information that is saved across sessions about the user's preference for either the metric or imperial system. As a result you can now view the stats information in either Miles and Miles per imperial gallon, or you can view it as kilometres and litres/100k.

The next thing that I need to do is include a menu for changing this setting and finish of the mechanic for only ever allowing a configuration dialogue to appear once upon first starting up the app. Other areas that can be improved would be to graph or visualise more information on the stats page, and to clean up the fuel transaction log page. I also need to clean up the car picker menu and possibly allow a user to add a picture to their car.

Once those changes have been made and I finalise all of the pages or data that I'm going to track with analytics the app should be ready for release on the Android market.

Speaking of google analytics, I've built up a full weeks worth of stats and they're interesting. I'll write a full post on this at a later point with pretty pictures and graphs and stuff.

Lotto Checker stats, now with analytics results!

It's been an interesting few days with the inclusion of google analytics, however downloads is quickly approaching the 5000 marks, and with the inclusion of google analytics I now have a better idea of how people are using the app. The first day I updated my app to include analytics I saw that on Saturday 746 people started my app, with 452 on Sunday. I updated the app on Friday, so I would imagine that a lot of these hits were due to people checking out the app to see if there was anything new. I will have to observe the numbers over a longer sample period to gauge the weekly trends. It will be interesting to see next weekend and on Wednesday if the trend matches this Weekends usage, as the Irish lotto games are on Wednesdays and Saturdays.

I'm also looking at the pages that people are viewing. There were a total number of 1872 pages tracked on Saturday night, 778 of which were Lotto. An interesting observation is that my app has had more page view tracks than this blog has had in the number of months I've been posting to it. There were quire a large number of Lotto checks on Sunday as well at 498, probably because people might have resorted to checking numbers the day after the draw.

One of the most interesting parts of google analytics is the way in which you can present the data. The live data tracker is also quite impressive, where you can witness page events being tracked in real time on a sliding graph. It also gives you insight in to how many users were on the app at any given time.

I'm going to get back developing my Driver Tools app this week and try and get some debugging done on the graph information. There are a number of other design features I would like to review also, however I can't think of them at the minute. I'll have an update later on in the week.

Google analytics update and saving sessions. Back in the game!

These past two weeks that I've had off for Christmas have been the longest period of time that I've taken off work in the last 3 years. I didn't expect to enjoy doing literally nothing productive over the course of my time off, however it happened. I think I needed the break. I've had enough of doing nothing for now anyway, and I suppose my time away from development gave me a bit of time to think about the approach I was taking for this app.

I opened up a Claude Debussy playlist on iTunes and started coding again tonight and managed to get Google analytics working. I'm currently only tracking three pages, however once I decide on what exactly it is that I'm going to track, then I'll include more. Other changes include the addition of an abstract class for handling all of the session data. This is also used for tracking various pages. It's an abstract class with a number of variables which are encapsulated to make everything nice and tidy. The only other variable it stores for the minute about the session is the ID of the selected car. It also saves this to the app's settings upon creating and destroying the app.

I made a few slight changes to the database adapter, to include a function for getting all of the transactions for the currently selected car in the session. So that now it only shows all of the transactions and stats for the selectd car. I may include a feature to show the spending across all cars at a later point.

Also, happy new year!

Post Christmas update!

I haven't had much time to dive back in to the driver tools project yet, with all of the social events going on over the Christmas holidays. This is going to change by tomorrow. Either later on tonight or tomorrow morning, I'm going to figure out how to get google analytics working properly, and I'll be looking in to setting up some app data with regards to the car that a user will select. I'll have an update soon

Deadline status update.

Today is the deadline I set for a releasable version of this project. The app is divided in to four parts. It has a tool for logging fuel transactions, a tool for picking and displaying information about your car, a tool for displaying information graphically about a user's driving habits and a tyre section for optimising wheel size and tyre pressure for maximum performance and economy. So far I have a beta version of the transaction and graphing tools and as as of tonight I can say that the car picker tool is now out of alpha and in to beta. The tyre pressure calculator can be done at a later point, and I'm not all that concerned about that for the minute.

The app in it's current state could be released on the market, however the styling of the app is not currently at the level of that which was originally envisaged and as a result of this fact I will not release the app to the market yet.

Currently all of the core functionality for in the beta version of the app has been implemented, but before I release it I would like to include google ads and goolge analytics and then clean up the interface to make it look as good as it can. So to summarise, the app functionality requirements have mostly been met but I will not be releasing the app just yet.

Checklist update

I've added most of the functionality to the database adapter for pulling out and inserting the data to and from the database. There's still a bit of testing that needs to be done, and there are a number of tables that I just haven't bothered implementing yet. I'll update these at a later point.

I've also modified the car picker tab to now display all of the cars in a table format, much in the same way the fuel transactions are displayed. I may change this to a relative layout which would look a lot better. The basic functionality is there. I also still need to test this class fully.

I've also identified a number of short cuts I can take now, such as the car manufacturer and model tables in the database because I won't actually be using them yet. I've taken out the blob column in the car database until I can research if there's a better way of storing such images. But I can knock off two and a half items from my check list. More will be done tomorrow.

Structured development time and to do list

I saw this blog post on linkedin there and I can see how a number of the things mentioned in the article hinder productivity. In particular multi tasking. Multi-tasking is bullshit.

I'm going to list out a number of different things I'd like to get done tonight and tomorrow night. These will be small steps of implementation which will lead me towards completing the integration of the new database schema and hopefully it will get put me on time for release on Sunday night. Also, I'm going to try and code in blocks of an hour at a time, then go do something else for a bit, and come back. I always thought it was a good idea to go and take a break, which usually consisted of a cigarette break in college, and by the time I came back to my computer I would practically have the problem solved. When you look at something after taking a break, sometimes the solution just jumps out at you and it appears so obvious that you feel embarrassed you had a problem with it in the first place. I can definitely see structuring my time like this benefiting my development.

• Add method to database adapter for getting all cars as a list of cars, similar to the way transactions are retrieved.
• Add view for displaying cars in cars tab.
• Add method of adding, editing and deleting cars.
• Add session data so that app can store which car is selected. To be used for adding relating car to transactions.
• Fix transactions so that only those for the car that's selected for the session are displayed.

If I get half of these done tonight I'll be doing well. I'll try get a mix of the more complex and more simple ones done tonight, and do the same again tomorrow night.

Database changes and plans to save the state of the app.

It's been a while since I've touched anything databases related but I've made a number of changes to the database structure so that now it includes the following tables.

Brand

• Brand ID - primary key
• Brand Name

Model

• Model ID - primary key
• Brand ID - foreign key
• Model name

User Cars

• Car ID - primary key
• Model ID - foreign key
• Mileage
• Car Picture

I'm eventually going to add more columns to the Model table for some of the specifications for each model. I'll need to make a number of changes to the database adapter in order to store transactions with the new schema, so that when data is added to the database it adds it to conform with the new foreign keys.

In updating the database, the previous database was wiped and as a result I discovered that when viewing the stats tab when there was nothing in the database it would cause a null pointer exception. I amended the method for formatting the database results in to a Androidplot compatible data structure to only do so if there was data being returned.

The fact that the database wiped on an update to the schematics of the database got me thinking that I really need to look in to a way of converting the data that's currently in the database to form what ever the new schema is during an app update if the original schema is changed. There could well be an easy solution for all of this but as I stated above, it's been a while since I've got in to some solid database design.

Currently nothing is being done with these new tables, but I'm going to work on modifying the existing classes and their methods to fit the new schema this week, and I want to change up the car tab so that the main tab displays a list of the user's cars that he's added to their app (i.e. what will be stored in the UserCars table). The user can select which car the app uses which can be saved as part of the app's settings. This will link in to the transactions so that the mileage being displayed is for the selected car's mileage and the stats being displayed will have a relationship with individual cars in the user cars table too. I just need to change the user_id column in the transactions table to be a foreign key from the UserCars table.

Graphs implemented

I've finished implementing the other graphs on the stats page for now. Currently it graphs MPG over time, Price over time and Distance between transactions. I need to seed the database for testing purposes with some fake data that might look like it has been entered over the course of a couple of months so that I can take a better look at how that data looks over longer periods of time, but I'll work on that maybe tomorrow or the next day. It might also be a good idea to implement the car picker part of the app. I want to include the ability to take a picture of your car and store it. This will require an amendment to the database and probably an amendment to the database adapter to get all transactions by a user id.

Styling and implementing AndroidPlot graphs

I've been back working on my driver tools app this evening and I've been messing about with the graph styling. So far I've had a look through the XYPlot class to see what's available for styling the graphs and I've added '€' as a prefix to the range increments and I've also corrected how they were being displayed so that now they display to the correct number of decimal places. Other changes to the way in which the fuel price over time graph include setting the domain boundary to a fixed minimum of 0 and setting the maximum range boundary to 50 which can grow should the data exceed this boundary.

Finally I've added a couple of new methods to the stats display activity class for pulling data the from the database, calculating the data required and then adding them to data structures that can be used to plot graphs. I've changed where the function is called from within the activity to the onResume() method, so that the graphs will update every time the activity is popped from the activity stack. This means that the graphs will always update when the focus returns to the stats GUI because the only way of invoking a change to the way in which stats is through other activities which will push the stats activity to the activity stack.

The next steps involve calculating the distances between each transaction which should be easy enough, as it's a simple subtraction. The distance between transactions is going to have to be calculated from the first transaction onwards for now, until when picking your car you can initially set the odometer.

The fuel economy is going to be more difficult to calculate, although the actual formula is easy, the MPG is going to result in issues due to the fact that if someone decides to refill their tank when it's not empty they will get a very low fuel economy rating. I'll implement it anyway and think of a solution later as the solution will probably involve adding a check at the point where a user enters the transaction details.

Deadline pushed back by one week

I've decided to push back the deadline that I gave myself by one week due to a number of factors. The first being that I was out of action last Saturday and then on Sunday I only had the guts of half a day to work on the project whilst I re-set up my development environment on a new laptop. Also, this week I've been busy taking on three separate web development projects, two of which involved teaching basic HTML and CSS to some web-dev students who were falling way behind, and the third being a website I'm currently working on for a swimming club. I'm currently finished with the web dev tutoring, and only the third project remains

The swimming club project only involves installing, configuring and styling Joomla, however there are some configuration issues with the web server the clients have which is a shared hosting solution. The issues that I'm having stem from the fact that they don't have the right version of php installed, which means I'll have to get on to their support team to maybe see if they can install php version 5.3 or later. If they can't do that I'm looking at some major work in trying to get Joomla 1.5 set up, and I haven't even begun trying to solve that bundle of problems.

Anyway, I'll be focusing on the joomla project for the remainder of the week, and possibly this weekend I'll get back in with some solid development on the driver tools app. Hopefully by the 18th December I'll have something to publish, or maybe before. There's not all that much left to do for the first level of functionality, so who knows.

An update and review of the deleting transactions functionality

I've managed to complete the functionality of deleting specific transactions with a neat little algorithm. There's an item click listener for each row of the list and I then have an array of booleans of the size of the number of list items which are all initialised to false. When the click listener recognises a click on that particular list item, it sets the array of booleans to true at the index of the list item was recognised from. Once the user selects delete, it iterates through the list of transactions whilst incrementing through the array of booleans and if that particular boolean index equals to true, it grabs the transaction ID from that current transaction in the list and passes it through to be deleted using the database adapter class.

Having completed this component, I then decided to move on to re-structuring the way in which transactions are displayed and it occurred to me that bringing up a list to select which transactions to delete offers more or less the same functionality that the actual fuel tab offers.

I guess that the fuel tab offers a lot more detail at the minute, with database entries such as the date, the userid(this may be car id at a later point), the total cost of the transaction, the total volume of the fuel for the transaction, the mileage at the time of the transactions, the fuel type and any comments a user might wish to leave. The delete shows the number of the transaction and the date on which the transaction occurred.

I guess for now I'll leave it since its a more or less fully functional component. But while I re-design the fuel tab display so that clicking on each transaction will add another row to display more detail and some calculated data, I'll be thinking coding with the idea of adding more functionality to that display. Functionality such as check boxes to allow items to be deleted with out bringing up a second list of transactions in a dialogue, or the ability to edit transactions.

New Laptop

I've finally got a working computer of my own again. I've been sharing a computer since I spilled coffee on my laptop during the last week of college, and after that I had been using a number of old PC's that were seriously useless for developing on. After getting eclipse set up on my new machine, installing the Android sdk, installing the ADT plugin and then transferring all of the projects in the workspace I had before, I was able to get back to work.

With a week left until the deadline I had set myself and being unable to work on this project yesterday due to a serious hangover, I've set myself a mini goal for tonight.

My goal for tonight is simply to finish off the functionality for deleting transactions from the list. After that if I have time I'm going to work on an expandable graphical user interface for viewing more data about each transaction, which should make the GUI much prettier and less congested.

When transferring the projects from one pc to another, I had an issue with there being no data in the database on the new emulator. When it came to drawing data on a graph, the whole app started to hang, so I'm either going to have to include some check to make sure there is data to draw if an attempt is made by a user to graph something. I also might include some kind of initial process for a user to follow where by the user has to select their car and add information about the mileage upon opening the app up for the first time. I'll come up with a more solid plan and design for doing this later on in the week. It's now time to get coding.

Working on gui for adding and deleting from the database.

I've been working all day today on a method of adding to the database. I had my dialog set up before which set the content view to a static XML layout. When it came to implementing a way of storing the information from this layout I ran in to trouble. I was setting up a listener for an "add" button within the dialog and this had an onClickListener anonymous inner class implementation. This would fetch all of the data from the input forms and add it to the database, however there was an issue with the resources it could access which was causing a NullPointerException when trying to inflate the button from the layout. There seemed to be some issue with loading the Button in with the findViewById() method which had something to do with the access level from within the inner-class to the outer-class's super-class and the fact that it used a common interface which was being overridden from with in the inner-class (A mouth-full, I know!).

I then switched my approach and used an AlertDialog instead. This worked out to be a much better solution because I was able to manually inflate the XML layout and add it as a single view to the AlertDialog builder. Then when it came to implementing another listener for the setPositiveButton method of the builder, I could just open a new database connection using the database adapter and add the transaction that way. It's a much cleaner solution that doesn't involve trying to figure out all of the inheritance and access issues.

I used the same approach for deleting transactions, however the AlertDialog builder has some pretty cool methods for building check-box lists for a dialog, and now I'm just working on a solution for deleting the selected items from the database.

List selection for deleting transactions

Next thing I've got to do is add a method for deleting a list of transactions from the database in the database adapter class, and pass the list of selected transactions through for deleting from the above list. Some error checking to ensure the forms don't contain an empty string will also need to be put in place because I'd imagine that could generate a NullPointerException, however I haven't fully tested the input sanitisation yet.

I also would like to review how I'm going to display the list of transactions, because viewing by date doesn't look that good. I'm thinking now that maybe I should just add a tick box to each row in the table and if it's selected the user can bring up the menu and delete them that way instead as well as perform other tasks. I'll think about that some more at a later point.

Menus and dialogs

So, now that I have my transaction database set up, it's time to add the functionality for adding transactions to the database. The way I envisage doing this is by adding a menu that the user can select an icon to add or delete a transaction. The menu option the user selects will pop up a dialog that the user can then enter in the details of the transaction they wish to add. For deleting a transaction the user can maybe then enter the id of the transaction or else select from a list of transactions they wish to delete. Upon pressing the back or enter button, the fuel tab should then be refreshed to update the transaction list.

So far tonight, I've manage to get the menu implemented, and a number of methods that pop up a dialog when a menu item is selected. There are currently place holder assets for the menu icons which need to be changed. Now it's just a matter of designing the input dialog layout and sanitising the input, and adding the sanitised input to the database. I'll probably get the input dialog designed by the time I'm done tonight, but I think I'll leave the sanitisation for another day because it's a much bigger job that requires me to be completely focused. I'm making good progress.

In other news, I was able to sign up for internet banking today which means that my google wallet account has been verified which means I can start charging money for apps. I'm not planning on charging for anything quite at the minute, but based on how much of an app I've got by the deadline I've set myself and how much functionality I can provide a user with beyond that I might decide to place a charge on a premium version of my Driver Tools app as I had originally stated in the concept blog post. Nothing has been decided yet however and it will be initially be released for free regardless.

Database amendments and custom adapter debugging

This morning, I have made a number of amendments a couple of the classes which include the adding of a method for setting the date to the Transaction class. Currently the constructor for the Transaction class sets the '_transactionDate' field to the current date which means that the new setDate method is useful for if I simply want to use the Transaction class for storing information about a transaction that has been pulled from the database. This helped me fix a bug where the date was not displaying correctly in the graph in the stats tab. I have also added a "getDisplayDate()" method which returns the date of that transaction object as a formatted string which is a conversion of the "_transactionDate" field which is an epoch.

I have also added a method to the to the database adapter class which returns a linked list of transactions from the database which makes it easier for adding data to the user interface, as before I had a method that returned a cursor which contained all of the information from the database that was queried. Other small changes include an updated graph which uses actual information from the database. It currently looks like the following.

Cost over time graph with transaction database data

Table containing transaction history

As you can see some changes need to be made to the visuals, however most of that are very minor changes and the core bones of the app is in place for more functionality to be added. Next on the list will be a for a user to be able to scroll up and down the table of transactions and a menu for the fuel tab that will add a new activity to the stack for a user to enter in a new fuel transaction. Last on the list is the sorting out the user interface, but I do want to get that done before I move on to something else. I don't want to let all of the work in debugging the user interface stack up on me because it will slow things right down.

As for the deadline I have set myself, I think I'm making good progress to be done in time for the date I set myself. Even though I only really have time on the weekends, last week I tried to do a small bit of coding when I got home from work and I managed that. Hopefully I'll be able to increase the amount of time I spend coding more and more over the upcoming weeks.

Simple transaction database implementation

After a bit of messing about with android database tutorials and mocking up simple ERDs with the mySQL workbench tool, I've managed to come up with a basic database design model. I'll be starting off with one table and implementing the features of the database as I implement each iteration of functionality in to the app. I'll be starting with the fuel transaction side of things, which means I've set up a fuel transaction table. So far the columns that exist are transaction id, user id, price, mileage, volume, fuel type and comments. The primary key is the Transaction ID, and the user id which is not being used at the minute, will be a foreign key.

Other Tables that will be included will be a car manufacturer table, a car model table and a user table. It's current state is quite simplistic in it's design but it will grow in complexity over time.

As for the implementation of this database, so far today I've managed to implement a database helper class, which deals with creating the tables if they don't already exist and updating the database if changes are made to the structure of it. I also implemented a database adapter class for dealing with raw sql queries for adding, editing and modifying entries; opening and closing the database; and also for fetching from the database. I now just have to work on the GUI for displaying the results of the database in a pretty way, and also for giving the user an intuitive way of entering in transactions and making it fit in to the GUI in a way that looks good. I also need to add a date column that stores the time of the transaction in the database.

First week in new job!

Last Monday I started a new job with Realex Payments as an Integration and Support Analyst. It has been an exciting week becoming familiar with my new role in the company, but unfortunately I hadn't had much time to work on my android projects lately. My weekday consists of an early start out in Monkstown which involves an hour of sitting in traffic every morning. After work after about another hour of sitting in traffic I battle falling asleep on the couch at home, so I'm usually too tired to work on projects in the evening. I do however have weekends off which is new to me, because of my previous job. I plan to make full use of this perk and get some solid development time in on the weekends that I now have off.

This weekend I'm planning on getting the back end of the app set up with a few classes for storing information about different things. I'll do a bit of reading tonight so that I'll be ready to get stuck in tomorrow and hopefully I'll have something worth adding to the project by tomorrow night.

Also, a quick stats update for the lotto checker app. I'm currently at 1859 installs and 1461 active installs. This is a 78.59% success rate with users, and my impression would be that a lot of UK users probably download my app due to the fact that it is featured in the top 30 in the productivity section of the android market with out realising that it is targeted at Irish users for Irish lotto results. I'll have a look at the UK lotto website and see if that may be something to incorporate in to the next iteration of that project.

Database design and android plot library.

Today I downloaded the latest stable release of android plot with the intent of learning how to set up simple graphs with static data and displaying them in a tabbed frame with in an android app. The API is fairly straight forward and there are a few tutorials on their wiki page with code snippets of the correct usage of the package. Using the samples from the wiki and what I have done so far, I added a simple X,Y graph showing fuel economy over time to the stats tab. For now the values are hard coded as the exercise was for the purpose of visualising what the graph looks like, and also for familiarising myself with the API should I chose to use it. It certainly looks well despite the fact that I haven't really messed about with the formatting of the default graphs.

Pretty Graphics!

When dealing with dates and adding them to a domain, they are put in an array as epochs which is the number of miliseconds since the date January 1, 1970. This will make storing dates easier in a database, but some method of converting string formatted dates to epochs will need to be investigated. I don't currently know if there is a method of doing it in any of the standard java classes.

The next thing I'll be working on is designing the database for storing information about transactions which can be adapted at a later point to store information about the individual models and makes of cars and their respective stats. So far the variables that will need to be stored as part of one fuel transaction are the total cost of the transaction, the current mileage on the odometer, how many liters were paid for and the date of the transaction. On the fuel tab I plan to have a list of all previous transactions which can be cleared if the user wants, or specific individual entries can be deleted from the database if they were entered incorrectly. I need to come up with a table design for the database that will allow me to expand on it in future when it comes to implementing other features of the app. Also I need to think about what kind of information I need to store about the users for the purpose of identifying the user or having multiple accounts or whether it is even needed.