idleSoftwareDeveloper

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

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.

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.

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.

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.

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.

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.

First of all, my lotto checker app has surpassed 3000 downloads.

Secondly, I saw the following image posted on the Android development blog. It appears that the number of apps downloaded from the android market place has almost doubled since June. That's some pretty impressive growth

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.

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.

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.

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.

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.

I'm laying out a number of bugs and design flaws that I've noticed so far that will need to be addressed, listed in order of importance.

Menu input inconsistent with looping indexes for pulling data, and needs a complete overhaul.
Values of number of options for each prediction needs to be dependent and consistent with the total number of options and predictions. The sum of all of the options per prediction should equal the total number of options.
There is currently no method for retrieving a list of users who have selected the correct options.
Some of the user names which are not plain text still have formatting tags surrounding them such as italics tags and bold tags.

I'll try and get a flow chart for the process of identifying the winners and then adding the points subtotals and I'll post it either tonight or tomorrow night.

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.

I've been working on the Driver Tools app for the previous 4 hours and I've made some amendments to the way in which data is stored. There is now a Transaction class for storing information about a transaction through out the life of the app. There is a method in the database adapter for storing a transaction object in the transaction table. I also have a dynamic table display now for the transaction display in the fuel tab. I've changed the fuel transaction database table to now include the date which is an epoch. This will be handier for adding time as a domain on a graph when it comes to that.

The next thing that needs doing is minor tweaks to the user interface, and maybe the set up of a xml style resource for making future changes to the way in which data is displayed in the app. I'm also going to write a method in the stats class for pulling the data from the database in to a list of transaction objects, at which point I can make other lists of data for setting up the graphs. There are also a few bugs which result in crashes when I pull data from certain columns in the database which I have to look in to so I'll try stay on top of things this weekend.

I've been working on the cruncher implementation for an hour or two each day this week and the progress so far is that I have the poll results page being parsed and each voter is stored in a hash-map where the key is the option they voted for and the pair is the user. The program accepts the url for the poll from the command line and for now the user is then prompted with a number of inputs for information about what each of the poll options mean. I think this will change in the future, and once I've debugged and tested this version of the application, I'll think about implementing some kind of dynamic GUI using java swing. Thought I'd post an update since I haven't yet mentioned anything about the implementation of this project. For now though, I'm going to start working back on the driver tools app, so a progress report can be expected later tonight or tomorrow.

Due to the fact that I made quite a bit of progress with yesterday and this morning's back end implementation, I have decided to Start a small side project that I want to get going while I'm working on the Driver Tracker app. This might turn in to larger project at a later point if I can get some more developers who want to get involved.

On the boards.ie motorsport forum they run competitions where by the put up a multiple choice poll with predictions about an upcoming race. Each prediction will have a number of points associated with it depending on how likely it will be as an outcome. The points are added up for each person who takes part in the competition and they are added to that posters total in a google docs spreadsheet. Due to the large number of people participating in this competition the results collection can be quite a bit tedious and I have offered my services to build a tool to automate this process.

I plan to build a tool for crunching these results and outputting the results to some kind of readable file. The program will be run from the command line and will accept a URL of the poll results as a parameter, as seen here. The next parameter should be the number of predictions, and the following parameters should be the number of poll options for each prediction group. For example, if we had a poll where there were 4 predictions and the first prediction had 4 possible outcomes, the second had 2 possible out comes, the third also had 2 possible outcomes and the last option had 3 possible outcomes, the correct use of the tool should then look something like "java F1NumberCruncher http://www.boards.ie/vbulletin/poll.php?do=showresults&pollid=20560 4 5 2 2 3".

I don't know how many other people might want to get involved, but once I have a beta version of this ill distribute it among the people who are in charge of updating the competition results and see if I can get another developer to try and do up a GUI for this or maybe work on exporting the data to a google docs exel format of some kind.

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.

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.

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.

The first thing I'm going to start working on is the tire information tool. The things I would like the tool to be able to do is educate a user about grip levels for braking, handling and acceleration; calculate the optimal tire pressure based on the weight and tire information; display data about the tire including information about the tires load, maximum velocity and some form of tool for compensating for increased speed indication due to a larger than standard rim size.

A lot of information about tire codes and general information about good tire practice can be found here. There are a number of other websites that will be useful for getting ideas about graphing grip thresholds and other important information that will be presented to the user.

Using the tutorial I linked earlier on the Android developer references website, I've managed to code up the tabs and I have some make shift icons in the tabs place. This will be my starting point for developing this app now, and I'm looking at examples of sqlite and how to connect to a database in Android.

Tabs!

I'm now having a look at various different widgets for graph drawing and this one looks pretty straight forward.

I've decided to get back in action developing apps with a brand new app. The reason I'm starting on a new app while I'm still testing and publishing updates for my last app is because I'm starting a new job on Monday which involves driving across town quite a distance every morning and then back again in the evening. I want to develop a driver tools app which will log fuel economy over time and it will contain a bunch of other tools for a driver to be able to adapt their driving style for a more economic drive. I feel this tool will be useful to me in the upcoming weeks as I drive to work.

Some of the things I would like the app to feature are graphing of fuel economy over time, tire pressure calculators and wheel size stats, route tracker which compares different routes on fuel economy and individual car profiles. This will mean that I'll be using APIs such as the GPS API and the databases API which is a side to android I have not yet used.

I've got an idea for the user interface design. I'm going to tab each of the functionality activities in tabs which I'm using this tutorial for. The methodology I'm going to approach this project with will be heavily orientated around good user interface design, robustness and security. I am also going to create two versions of this app, one of which will be free with ads the other will contain a bit more functionality and will not contain ads. I'll divided up the functionality and decide on how much I'll release for free once I've I'm in beta testing and I think I might release a beta on the market and update it until it is at an acceptable level of functionality to release a premium version.

In other news, my lotto checker app surpassed 1280 installs with just over 1000 active users today.

I've had a bit of a lack of progress with any updates of the lotto checker app because I've been busy with work and floods and I also bought the F12011 game which is awesome. I doubt I'll get much done this weekend either, between working late and partying hard for Halloween but as soon as I get a chande next week, I'll try finish debugging ahd testing the euro millions and all or nothing ticket chrcker. In other news the total number of Downloads surpassed 800 today!

This week was a horrible week for motorsport with the death of Dan Wheldon last weekend annd this weekend the death of Marco Simoncelli. There were also three deaths at the Isle of Man TT this year including Irish racer Derek Brien. Also this year we saw the release of the film 'Senna', a film about the life and death about the legendary Ayrton Senna. This was a stark reminder of how dangerous motor sport is and I think that following this weekend a lot of the formula 1 drivers will be on edge at the introduction of the latest circuit in the formula 1 calendar in India. Let's hope for a safe end to the season and let's look forward to the progression of saftey in motorsport and motoring across the board

I solved a number of issues with the ticket checker and I am now glad to say that I have just published an update to the android market that will allow a user to check their Lotto or Monday Millions numbers to see how many matches they have. There is still an issue with the ticket checker for the Euro Millions draw which will I'll test for over the rest of the weekend, and I haven't even begun to test for the All or Nothing draw which I have a feeling will work pretty flawlessly on the methods already implemented for checking the lotto and Monday Millions to be honest. I'm not sure how long the app market takes to update or when it will be ready for downloading, but it has been uploaded and activated so it shouldn't be too long.

I'm currently testing an update for my lotto checker to allow users to check against the Irish lotto results and maybe the Monday millions only. This is because the Monday millions and lotto share the same format and any tests performed on the ticket checker component can be tested for both games. I need to fully test for the other games, euro millions being more tricky because of the number of bonus numbers but hopefully I'll have it updated soon enough. I want to get the update on the market tonight if possible, in time for tomorrows Lotto game. I think I have it at a state at the minute where the ticket checker can't crash, and I haven't encountered a scenario yet where the number of matching numbers is wrong.

I discovered today that my app is ranked 23 on the list of free apps in the productivity category which may be why the number of downloads is shooting up. I currently have 400 installs with 325 active installs which is an 81.25% success rate. Hopefully this update will bring more users but due to the fact that I'm now publishing to 325 or more people I want to make sure the update will not dilute the quality of the app in its current state.

I've been updating my ticket checker class today and I'm ironing out the bugs, but the update should be ready to upload tonight. I think it's important to get a further update and some of the lotto checker functionality in as soon as possible. Currently I've removed the functionality for telling the user how much they have won because testing for that will take about three or four days in my best estimation.

In other news I sat a phone interview last week for a software integration consultant role with a company. Out of that phone interview I managed to get an personal interview which I sat last Monday, and out of that interview I managed to get a job, so things are looking up. This blog was originally set up to help me get a job, but since I'm actually enjoying updating my apps and I've actually warmed up to posting development updates here I'll be continuing this blog, even though traffic is slightly lacking. I'm currently getting more app downloads per week than I am hits to this blog. The current number of downloads of my app is 261.

Over the last two days I've started back working on the interface for allowing a user to enter in lines on their ticket to be checked against the latest results. So far the functionality exists where a row of EditText boxes are dynamically added to a linear layout along with a button which reads "Add Line". When the user clicks the button, it runs through each of the text boxes first making sure that the input is valid, then checking that the input is not a replication of an entry in one of the previous text boxes. After checking for each of these conditions on each edit box, if they meet the criteria they are appended to an array in a specific format that can be used to check against the results in the results class. A text view is updated with this line to show that the user has entered a line in for checking. If a user wants to add another line to be checked, the new line will also be checked against the existing lines in the text view.

New Ticket Checker GUI

I've started using the Toast class for displaying messages when a user tries to input data that is doesn't meet the described conditions (i.e. numbers) which actually reminds me of something I had forgotten. I currently don't have something to ensure that numbers entered are above 0 and below what ever the highest number that can be picked for each game is. I'll get back on that tomorrow.

Other updates include the addition of a Stats class which is used for storing information about winnings. The functionality for parsing the winnings table from the accessible results has also been added. The winnings table displays information about the number of winners of each winning combination of numbers, the number of Irish jack pot winners, and how much each winning combination has won. In the Stats class it keeps a linked list of Stat objects which stores a row of the winnings table. I'm thinking it might be a better idea to store it in a HashMap instead, because then if I pass a Stats object through the lotto checker activity I can get specific Stat objects using based on how many numbers the user has matched as a key. This should make displaying how much the user has won quite a great deal easier.

I was in the middle of a post about what I'm currently coding at the minute, which shall be posted soon and I thought I'd give a quick update about my Lotto Results app that I uploaded a couple of days ago. So I decided to post a completely separate update for it.

According to the android developer console, so far I have had 75 total installs, 53 of which are actively installed. If I use the percentage of people who have installed my app and not uninstalled it having deemed it not worth using, I have a success rate of 73.9% which is not too bad at all.

Other stats include that the most of the users are using Android 2.3.3+ at 60.4%, Android 2.2 is second at 26.4% and Android 2.1 is only 11% of the user base. The last 2.2% is made up of a combination of Android 2.3, Android 3.0 and Android 3.1.

Mobile Devices by percentage of installs.

Rank	Device	User Share
1	Samsung Galaxy S2	15.1%
2	HTC Desire S	11.3%
3	HTC Desire	11.3%
4	HTC Wildfire S	9.4%
5	Samsung Galaxy Ace	7.5%
6	HTC Sensation 4G	5.7%
7	SEMC Xperia X8	5.7%
8	HTC Wildfire	3.8%
9	Samsung Galaxy Mini	3.8%
10	Samsung Galaxy S	3.8%

As can be seen in the the above table, 15.1% of installs were on a Samsung Gallaxy S2, with 11.3% of installs on HTC Desire S and HTC Desire each. HTC Wildfire S has 9.3% and Samsung Galaxy Ace has 7.3%. This gives me a lot of important information about what kind of screen size I am deploying to which will help me further in designing my user interface.

I would like to publish an update with the ticket checking functionality as soon as possible, so that hopefully I will be able to get more downloads and increase my install/uninstall ratio further.

I've decided to work on making my GUI look better so I set up a test project with the express purpose of messing about with different layouts whilst trying to comply with best practices for GUI efficiency as described in the android reference documents. The GUI looks as follows.

Multi Component List Items

Each list item contains an ImageView on the left which is an anchor for a TextView to it's right, which in turn is an anchor for the TextView title which is above. There is no problem displaying this purely in a RelativeLayout, however when it comes to adding this kind of layout to a ListActivity I seem to be running in to trouble. I'm only able to set the text in one of the two boxes. I think the answer lies with creating a custom Adapter class for seeding the ListView.

So I've taken a bit of a break from my lotto checker app, because I want to start messing about with SQL and XML parsing. I'm going to design and build a tool for storing items taken from an xml file in an SQLite database so that I when it comes to developing the motoring app I posted about the other day, I'll be able to come up with a more solid design, the build should be much quicker and I can focus a lot more of my efforts on testing.

I'm now at the point with the lotto checker where I need to tinker about with the input a bit more to perfect it, at which point the app will be complete. I' was thinking about writing a custom keyboard class based on a grid layout with image buttons.

A basic version of the lotto checker app should now be live on the android market.

Watching the formula 1 qualifying I was reminded by Eddie Jordan that I have a slow puncture on my left rear tire which I've been topping up with air for the last week or two because I haven't bothered going to get it sealed. I had a quick look on the android market and there's no free apps for doing tire pressure calculations.

There are a couple of apps out there for fuel economy management and speedometer recalibration based on tire size, but I think an app that will encompass all of this functionality with an easy to use interface would not only be something I would use on a regular basis, but something that I think other people would be interested in. I'm going to finish up this weekend with the lotto checker and I think this should be my next project.

Tomorrow I'll be up at 5 for the Japanese grand prix qualifier and the Irish rugby match against Wales and after I'm going to review my Results class. I think maybe the class should be an abstract class with an implementation of the checking method. Then I can write a subclass of the Result class for each type of game. I think it would be a more logical structure to the app and it should make the addition of new game types easier. Also, maybe the functionality for pulling the information from the web should be a method of each game type.

Today I decided it would be best to add a class for storing and checking the results. This way all of the results for a game can be passed through with the intent for opening the ticket checker GUI. For this to be possible the Results class had to use the serializable interface. Contained in the Results class are methods for comparing a string of lotto results to the results contained with in the instance of the Results class. The method returns the number of matching numbers. This makes the implementation of the Ticket Checker GUI a lot more straight forward now since most of the functionality for comparing the numbers for each game type has now been implemented. All I need to do now is implement a way of entering in numbers and I can begin testing.

Once I'm finished testing, I'm toying with the idea of integrating some form of map functionality which will display all of the lotto retailers in Ireland so a user can find the nearest point to where he/she can cash their lotto ticket in. Of course I'll have to find a list of retailers first, but I don't think this will be too much work and it allows me to jump in to the geo location side of things which interests me.

Today I by started by designing a system for entering in the numbers on your lotto ticket to check against the results but I'm finding it difficult to decide on what form of input and layout to use. I'm currently looking at using a number picker widget, however I'd have to write a new layout for each type of game. The number picker widget not only allows you to scroll through a list of numbers, but it allows you to enter numbers in to the box manually using the keyboard as input. The range of numbers can be restricted. This seems like a simple enough method of entering details of a lotto ticket, then based on which game type, a new layout can be loaded which has the details regarding how many numbers pickers will be required in a row. The following is an example of the number picker widget I'm looking at.

Number Picker Widget

In other news, I've fixed a bunch of formatting issues with the lotto feed and I've implemented the algorithm for pulling the results for both the Euro Millions and All Or Nothing results, I did a bit of testing on a couple of different emulators and deployed the app on my archos. I decided to make the font double the size and it's now at an acceptable size for reading on both smart phones and tablets. I'm going to register a developer account and maybe upload it to the android market tomorrow for free. There's not a lot of content at the minute, because it only functions as a feed for the results, but if it gets approved I can update it with more functionality the next couple of days and weeks.

I've decided to change the entry point GUI so that instead of displaying two buttons for checking the latest results and older results. Instead you now get a ListView with all of the different lottery games. This solves a number of problems, the first being that I can remove the functionality of searching for older results from this iterations design specs. I can maybe integrate that functionality in at a later point. The second thing this change does is make the user interface look a lot better. The following is a screenshot of the new layout.

New Screen 1 Layout

Less data each time the app fetches results

The third thing that these changes have affected is that now because the game type that the app is looking for the results of is being passed through with the intent, the app can stop trying to parse results from the lotto results webpage once it has found what it's looking for which makes the whole process quicker. It also means my code is more organised now because I've created a function to check for each individual game which gets called based on the game type. With this approach I can modify how it parses each type of game result. This is important because not every game has the same amount of numbers and the formatting changes slightly for each game. Only the Lotto and Monday Millions have the exact same formatting.

It's been a long day of coding and I'm going to call it a night after I update this blog. I've got the formatting of the results all sorted out by splitting the strings on regular expressions. I've also integrated the web page parser in to the app now and I've sorted out the activity permissions so everything is working with in the emulator.

Next on the list of things to do is to thread the parsing of the results page so that the GUI will not freeze up. It doesn't currently freeze on the emulator, but because of the difference in hardware for mobile phones it may freeze on a slower device.

There are only a few components I need to implement before I start testing everything.

The Lotto checker activity
The List of previous results
Utilization of threads
Graphics update, making the app look pretty.

I'm going to have to brain storm about how I'm going to be able to pull off old results for the old results list. Unfortunately I won't be able to get them from the source I'm getting my current ones from which makes things a little bit more tricky. We'll see. I love Android.

I've decided to set up another eclipse project so that I can write the component for pulling the lotto results from the lotto website and get the formatting right and then swap it in to the android app at a later point. Hopefully the only thing I'll have to swap around is some of code for setting up the connection and maybe some of the error handling.

I'm now using a different results page which I believe is formatted in a way which should make it easier to grab all of the results at once. So far the code sets up a connection to the lotto web server and reads line by line each page, looking for a specific piece of html, at which point functions are called to parse each set of results from that line down. It's worked pretty well so far. I'm just messing about with the formatting of the text at the minute cleaning it up a little. So far it looks like the following.

Wednesday 28 September 2011
Result: 5 10 15 27 35 43 Bonus: l
Plus 1 Draw: 17 19 25 30 41 44 Bonus: 42
Plus 2 Draw: 12 15 32 35 41 44 Bonus: 24

It's having trouble with some of dates because of the way I've written how it looks for that segment of code, but it's not important for the minute. I'll come back to it.

I have most of the UI structured and sorted out at this point. There are three main user interfaces for this app. The first is the menu. The menu has a couple of buttons which when pressed create an intent and start up another activity. So far there are only two buttons, one of which will create an intent to start up a "ListActivity" displaying the previous lotto results. The second will create an intent to start up another result checking activity for displaying the latest results. This activity will can also be started by clicking on an item in the list activity for that set of results. On the result checking activity it will display the lotto numbers of that date and there will be a further button to enter your lotto numbers to check if you've won on that activity UI.

Main Screen

Old Results Screen

I'm currently working on the screen that displays the results, but it will probably be just a TextView with a button that leads to another UI for entering in your ticket or something. Once I'm done with that I'm going to look in to the best way of pulling the results from the web, because I don't think the full java.net package is available on android and I think you have to register network connectivity as a function in the manifest or something. I'll look in to it.

Something that I only really found out quite interested me after I got my archos was the android live wall papers. I've just been looking at this tutorial and it looks like a quick and easy enough project to do in the near future, once I'm finished with this one. I'll be able to apply some of my 2D game physics knowledge to try make a bit of cash or even just stick it up on the android market for free or something.

After about a week I've finally got back to messing about with Android. I'm still making my way through the tutorials, developer documentation and sample source code but I feel like I'm making some progress. I've just bought a second hand Archos 101 (android 2.3.1) tablet from a previous college lecturer which I will use as a test device.

Obviously when developing for a tablet there are some things you have to consider, for instance the larger screen. I think I can use this to my advantage by ensuring the gui I create is robust and will work well on multiple devices. All of the tutorials so far that I have gone through implement the GUI using XML which will aid development of this app across different phones.

I've also got my hands on a book called "Starting Android Tablet Application Development" which is aimed at people beginning developing with Android. I've only really had a glace through the first couple of pages of the book, and what I've read so far has been more insightful than the Android documentation. I have to say I'm looking forward to really getting in to this project now.

I've been reading for a bit and I like the way Android operates. The activity tasks and back stack and the activity life cycle is something I will probably find myself coming back to look at in the future. The more I read the more I'm finding it similar to J2ME which is a good thing.

The four main component classes that you extend (Activities, Services, Content Providers and Broadcast Recievers) will make the design a lot easier and the ap better structured. For now I can see the use of both the Activity and Service classes and later on if I want to integrate some kind of image processing element I forsee the use of the Broadcast Receiver. I'm looking at code examples now whilst I make my way through the documentation.

Now that I've decided on what my first project for this blog is going to be it's time to get down to business. As I have never worked with android before, the first step is to actually read some of the documentation, of which there is plenty of. From what I've seen before it's quite similar to J2ME in the sense that there's a bit of boiler plate code that's bare minimum for setting up the graphics device and appending stuff to it. I don't think it's going to be too difficult to learn!

In terms of the IDE, I'll be using Eclipse. So far, I've downloaded the Android SDK and I've installed the ADT Plugin for Eclipse, which has now just been configured as of this moment! I'm going to spend the next couple of hours learning the basics of the framework before I start up on designing how this ap will function, at which point ill draw up a few class diagrams and do a few pretty flow charts and stuff.

After a good weekend of Rugby,Moto GP and GAA I guess it's time to actually get down to business. I'm going to kick start this thing off with a project that I've been thinking of doing for a while. There's a handy little tool for checking your lotto numbers on the lotto.ie website. The tool allows you to enter in the numbers you have on your lotto ticket, it then checks the numbers against the winning numbers and tells you how much you've won.

My project involves the recreation of this lotto checking functionality as an android ap. I would first like to develop this ap as a means of familiarizing myself with the basics of Android development which shouldn't be too difficult as I have quite a bit of experience with J2ME.

Once the initial functionality has been implemented I will look in to what image processing frameworks and api's there are available for android and see if it's possible to implement a system where you can simply take a picture of your lotto ticket instead of manually entering in all of your numbers.

Hi and welcome to my new blog! Ironically, I have never been really that interested in blogging before, nor am I now. I find the whole process a bit tedious, however I was watching the film "The Social Network" the other day and in that film Mark Zuckerburg was keeping a semi personal/development blog which he used as a mirror for reflecting upon ideas he had at the time which in turn aided him in implementing these ideas in to reality. Don't get me wrong, I'd highly doubt anything as big as Facebook will come of this blog but since I am constantly coming up with ideas for mobile aps, websites and other bits of technology that I never actually get around to doing anything about or else I start but never finish.

The purpose of this blog will be as a tool to aid me in recording, designing and developing these ideas. It is also my hope is that this blog will be keep me motivated as I learn to use new technology such as the android SDK. I'm not sure how often I'm going to update this blog, but I'll do my best to keep it quite frequent and semi-interesting.

29 December 2011

18 December 2011

14 December 2011

12 December 2011

11 December 2011

10 December 2011

7 December 2011

4 December 2011

26 November 2011

23 November 2011

22 November 2011

19 November 2011

17 November 2011

13 November 2011

11 November 2011

6 November 2011

4 November 2011

28 October 2011

24 October 2011

22 October 2011

19 October 2011

16 October 2011

15 October 2011

Mobile Devices by percentage of installs.

12 October 2011

10 October 2011

8 October 2011

5 October 2011

4 October 2011

2 October 2011

1 October 2011

30 September 2011

26 September 2011

21 September 2011

19 September 2011

14 September 2011