Simple Mobile FireDAC App

The DocWiki has a great mobile tutorial on building a mobile To Do app with FireDAC and SQLite. I find I usually build it a little differently though, so I thought I would share my code here.

Go ahead and lay the UI out the same, and put down most of the same FireDAC components, with the visual LiveBindings. I love how it uses the LiveBindings wizard to create the data source. What I change is the code in the event handlers, but what you don’t need is the Insert and Delete FDQuery components. While that code all works, it uses an older model that doesn’t take full advantage of the amazing features of FireDAC.

So your form will look something like this . . .

FireDAC-ToDo-1

Add an implementation uses clause

uses FMX.DialogService.Async, IOUtils;

And then your addButtonClick event handler will look like this . . .

procedure TForm42.addButtonClick(Sender: TObject);
begin
  TDialogServiceAsync.InputQuery('New item',['Name'], [''],
  procedure (const AResult: TModalResult;
             const AValues: array of string)
  begin
    if (AResult = mrOK) and (Length(AValues) > 0) and
       (Length(Trim(AValues[0])) > 0) then
    begin
      FDQuery1.InsertRecord([AValues[0]]);
    end;
    UpdateDeleteButton;
  end);
end;

You’ll notice a few changes. First of all, I used an anonymous method for the async callback. Also, instead of using an entirely different insert query, I just call InsertRecord on the existing FDQuery1, passing in the value. For simple tables like this one this is so much easier. This really simplified the code in my opinion. Also instead of spreading the code to update the Delete button’s visibility all over the place I used a procedure called UpdateDeleteButton. Here is the rest of the code with a few comments.

procedure TForm42.deleteButtonClick(Sender: TObject);
begin 
  // Again we use the built in Delete method instead of a separate
  //   Delete query. This just deletes the currently active record.
  FDQuery1.Delete;
  UpdateDeleteButton;
end;

procedure TForm42.FDConnection1AfterConnect(Sender: TObject);
begin
  // This makes sure our table exists, just in case the data file
  //   no longer exists. Makes the app more resilient. 
  FDQueryCreateTable.ExecSQL;
  // And let's not assume anything about that Delete button status
  UpdateDeleteButton;
end;

procedure TForm42.FDConnection1BeforeConnect(Sender: TObject);
begin
  // We don't need to use a compiler directive here, but that does
  //   mean our database file is in our documents folder, which 
  //   doesn't make as much since for a desktop.
  {$if DEFINED(iOS) or DEFINED(ANDROID)} 
  FDConnection1.Params.Values['Database'] := 
    TPath.Combine(TPath.GetDocumentsPath, 'todolist.sdb');  
  {$ENDIF} 
end;

procedure TForm42.ListView1Click(Sender: TObject);
begin
  UpdateDeleteButton;
end;

procedure TForm42.UpdateDeleteButton;
begin
  deleteButton.Visible := ListView1.Selected <> nil;
end;

The beauty of calling the FDQueryCreateTable.ExecSQL is that you don’t need to deploy an empty database file. It just creates an empty one the first time it runs.

So what do you think, is this simpler? What would you do differently?

This entry was posted in FireDAC. Bookmark the permalink.

4 Responses to Simple Mobile FireDAC App

  1. Christophe says:

    Hi, for demo separate the gui and logic. Use a datamodule for the logic. Experance developer know that. But a beginner will do the same like in the demo. (all the code in one form or under the onclick event). Show the right way to program. (even in a demo)

  2. Jim McKeeth says:

    Good point. Maybe I’ll refactor it. Check out ColumbusEgg4Delphi for a great example on how to separate GUI and Logic. https://community.embarcadero.com/blogs/entry/mvvm-mvc-rad-architectures-with-columbusegg4delphi

  3. Steve Jordi says:

    Christophe, I agree but, a beginner is probably in no way able to understand architectures like MVVM (or others). I think it’s a good motivation to let beginners start with something that works and is rewarding right away, and inform them that the Logic and GUI are to be separated, something they can learn later, while keeping this in mind.
    Thus, they will discover the potential of the tools first, and then consider more advanced technics as they progress too. Letting them know it’s possible to separate GUI and Logic is a point that should be mentioned, but for a quick demo, I think that Jim shows something that is nice.

  4. Joao Ferreira says:

    Christophe, I must agree with Steve with one remark: the beginners must start as soon as possible to separate the Login and GUI. It’s very easy to forget this principle and continue to use a non conventional method. I too started this way and sometimes wished to go back.

Leave a Reply