Tag Archives: DineWithMe

Dine With Me: Two (Facade design)

I am adapting the "Dine With Me" application to eventually become a full-fledged web-application. One of the issues I am facing is where to store the database information, in the current model the data is hardcoded in the Database class. I have not yet decided how I will solve this, and this blog is in part to help me think about the problem, write down my thoughts and possible solutions.

The core of the application has a facade (DineWithMeFacade), which provides a single-point-of-access, from which all other actions can be executed on the program. Pretty standard facade-pattern and nothing much interesting going on, the Swing-desktop application uses this to add friends, retrieve recipes, login, encrypt and encode information, just as you would expect. However, when developing for android, I extended the DineWithMeFacade to add android-specific features, revealing some of the caching-system methods. In addition, the "AndroidDineWithMeFacade" is singleton. This made passing data between activities easier, as well as avoid creating a new instance of the facade for every activities. (Activities don't have a very long lifetime in the app).

During this, the data was still hardcoded in the core, the Android application simply used an external jar to talk to the core. I never like to choose the "singleton" way to solve a problem, though I believe sometimes it is the right choice occasionally. Now I'm making a web-app I thought of refactoring the DineWithMe Core a little, having stopped working on the project for a month or two gave me some new insight in things I could have done better. (Honestly, putting down your code and not looking at it for a while, then picking it up, is a great way to see how easy your code is to understand!)

The refactor

Stacking the preliminary building blocks of the web-app gave me a reason to change the core. When building a web-app, I keep my project's properties in the web.xml file and thus would like to store all the database information there. After thinking about this for a while, I realised it's probably a good idea to use a database.properties file in the Swing application, as to avoid having hardcoded passwords scattered throughout the application. This doesn't come as a shock, but it is something I didn't consider when coding hours on end to reach the deadline for the mobile application project.

The key problem is 'Where to set the database parameters'. The facade exposes the setters of the database class, so any class with access to the facade can change this. So far, there is no problem to be found. The android and desktop applications can both use a properties file to read out the data, and pass it to the facade. Meanwhile, the web-app's Servlet can read the data from web.xml and pass it on through the facade, right?

This would work for the android application, but not for the desktop application. The reason? Well if the DWMAndroidFacade extends the normal Facade, but is a singleton. Thus, I could tell the facade to set the parameters for every service and finito, the work is done!
Now I am left wondering, what I should do. I can have the desktop application and web-app extend the normal facade into a "SwingFacade" and "WebFacade", which are singletons. Now the problem is gone but I'm left with more singletons (though only one singleton in the each project).

After doing a quick search through the swing application, for "new DineWithMeFacade()" the results hinted at a rather small refactor. (Well, that's relative, but it's a rather large project!)

searchresults

After writing this post I'm quite convinced that going the singleton-desktopfacade/webfacade way might be the right way. Singletons pose quite the conundrum, but for a facade I think even the GoF might agree it's acceptable! 🙂

Dine With Me: One

Over the course of the past few months, I have been working on an application titled "Dine With Me". The next few weeks I will write blogs about this project, design patterns, interesting algorithms or other related subjects.

This is the first of those blogs, and I'll explain what the application is, how it came to be and what the current state of the project is.

The past

It started around october-november, when, for a course in 'Mobile Applications' we had to create an android application. We were given complete freedom in what the application would do, but had a few requirements regarding features, such as working both online and offline, using at least one hardware feature, and being responsive (work on android phones as well as tablets).

Enter: Dine With Me.

The idea for this application came from both Vasco Freitas and myself. Vasco was an exchange student at my university, but was only part of the initial part of the project. We worked out the idea for  the application together, and created some mockups regarding the user interface. All the actual code, both SQL and Java has been written by me, as well as creating the actual user interface.

The motivation for this project was: 'When we are at our dorm, we sometimes cook for everyone, but it's hard to know who will cook when, and whom will attend'. After a while this evolved into 'When someone cooks, either at dorm or at home, whom of the "family" can attend this? Will the eldest son be joining for dinner, or will he be at university, if the dad is cooking, what is the recipe and is it something his family likes?'

With our application, users can keep a list of recipes and a list of friends. They can then create an 'Event', which they can give a name, choose a recipe they are making, and set a date/time for the event. Afterwards, people on their friends-list can get an invite and respond by either accepting or declining the offer.

 

Tools for the job

This is a short list of some tools that came in handy during this project.

  • Eclipse EE
  • PostgreSQL server
  • pgAdmin III
  • Genymotion
  • Github

pgAdmin III is a nifty tool to quickly execute queries on a postgres database, making life just a little easier by providing an easy way to alter the database structure, check where a query goes wrong, and the usual you'd expect from an 'IDE' for database administration. Genymotion is an emulator for Android phones, it's much (much!) faster than the standard emulator you get when installing the Android SDK for Eclipse, and offers some nice features as well such as a screenshot button, emulating tablets and phones of various resolution, and disabling/enabling network connectivity (Handy for the online/offline-requirement!).

The current

At this moment, the android application is finished. My course of 'Mobile Applications' is finished. (Scored 90%, or 18/20 as per Belgian university marks, I lost two marks due to my UI. I'm a software engineer, love back-end software, have zero taste in UI.). In addition to an android application, I made a Swing desktop application just for fun during the semester. It made it easy to test two accounts simultaniously, ergo it was easy to 'send a friend request from A to B with android, accept on B with swing, check friend-list update on A,...

I generated both Javadoc and Code Metrics for the core and swing application. It seems redundant to post some facts about the code here with all the metrics available, so you can check those out if you're interested in seeing how the project looks like.

Furthermore, both the 'swing' and 'android' application are available on github. Note that the swing application is really just a UI wrapper around the core, therefor the swing is included in 'DWMCore' and is packaged into a jar file for the 'DWMAndroid' application.

The UML at the current state is shown below. It's updated frequently (as it provides a good way for our lecturers to see what's going on as wel).

The future

Currently I am following a course called 'Internet Programming', for which we have to make a (distributed) web-application using Java EE as main programming language. For this course, I am extending 'Dine With Me' to a full-fledged web application, adding some features such as chatting with other users and uploading images for the recipes. This is all in the baby-phase, if you checked the github commits right now, it would say 'reboot' in which the changes made to the project are for a more flexible online-offline strategy. (Using the strategy-design pattern, instead of using a caching mechanism under android).

I'm very exited for this project, at some point I might publish it on a tomcat server, together with another application I'm working on which uses the steam-API. This one, Dine With Me, will always remain opensource software though, and anyone willing can contribute to the github project.