Recent

Author Topic: Database for small GTD Todo application  (Read 14504 times)

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: Database for small GTD Todo application
« Reply #15 on: February 19, 2017, 11:59:44 pm »
Let's see how it progresses..
I know about Firebase and Android, that's one option.
The other options.. ?
Well, I am sure I will figure it out once it's relevant.

I will bookmark this topic and return to it after a while, because now would be a good time to don the thinking hat, take out the sketch pad while at the same time get the basics of the application up and running.
Otherwise I will be stuck in thinking mode for a long, long time. :)
more signal - less noise

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Database for small GTD Todo application
« Reply #16 on: February 20, 2017, 12:16:59 am »
get the basics of the application up and running.

Just make sure you have a path forward for how you want to do syncing.

About 5 years ago, I had an idea for an app that I was calling a sort of "data journal". Probably not too different from the kind of functionality that your app will have. It seemed like a lot of people kept journals, formal or informal, of various numeric information, not so much words. For example, people record rain gauge data, how many miles they bicycle, golf scores, etc. So my app had two requirements: (1) That all categories could be user-defined, with a small set of pre-defined starter categories provided as examples, and (2) all categories could have various stats calculated for them (mean, median, frequency, monthly averages, whatever, all user specified).

So I created a nice little iOS prototype that used SQLite. But where I stopped was when even 5 years ago it occurred to me that of course this app needed to be able to sync its data, so if I created a desktop version one day, the data would automatically flow in from the mobile version. And I could see that this was a non-trivial exercise. So the app fell by the wayside.

Many mobile apps have had this capability for years. And not just calendars and e-mail clients. For example, with Apple's Pages word processor, it doesn't matter where I create or edit the document: iOS, OS X or Web browser (icloud.com). Everything gets synced automatically. I think from day one I would set that as a requirement for any app of this kind, including an app like what you're thinking of.

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: Database for small GTD Todo application
« Reply #17 on: February 20, 2017, 12:27:53 am »
Noted.  ;D
Good advise!

Edit:
I do have a preliminary plan to let the application talk JSON with a API sitting on my server - I will write it in PHP (Yii Framework) - so no worries.
« Last Edit: February 20, 2017, 12:36:05 am by jacmoe »
more signal - less noise

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Database for small GTD Todo application
« Reply #18 on: February 20, 2017, 12:37:40 am »
Noted.  ;D
Good advise!

The key is you don't want to outgrow your app before it's even finished. That's what happened to me. I could see that without cloud awareness, that even I probably wouldn't use the app.

I would also encourage you to do a Web version. That will ensure that you've properly separated the non-UI code from the UI code. I've grown generally pretty skeptical of RAD development as defined by Delphi and Lazarus. RAD often just leads to bad design, where the non-UI code is all mixed into the form code files. A Web app will ensure that you don't make that mistake.

The other advantage to a Web version is that it would mean you wouldn't necessarily have to do all desktop and mobile platforms, since users of unsupported platforms would at least have a Web-based fallback to use.

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: Database for small GTD Todo application
« Reply #19 on: February 20, 2017, 01:19:26 am »
I am actually approaching this from the opposite direction, so to speak: have been developing web applications for a couple of years, and I want to return to the desktop. ;)
So, while the application is primarily developed at the desktop, I think I have a good chance of picturing where it fits in relation to the web.

One of the primary goals is to develop an old school offline first desktop application, while at the same time seamlessly allowing it to sync over the wire.
Anything that put the cloud into the equation should be done in a pluggable way.
Ideally, this is going to be a good application when an apocalypse strikes and the internet goes black.  :)
((At the same time, it will definitely be able to connect if it comes back online again :p ))
« Last Edit: February 20, 2017, 01:28:46 am by jacmoe »
more signal - less noise

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: Database for small GTD Todo application
« Reply #20 on: February 20, 2017, 05:40:18 pm »
So, I've decided to try mORMot - with Lazarus/FPC "Fixes", not trunk.

I am not using newpascal, because it seems to be just as bad as relying on trunk - and for political reasons.


Hopefully, that mORMot framework will allow me to try out different approaches, from simple, in-memory, file-based, to SQLite (statically linked), to talking to a server via JSON.

I am used to be using ORM, so I think I will grow to like it.
« Last Edit: February 20, 2017, 05:58:05 pm by jacmoe »
more signal - less noise

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: Database for small GTD Todo application
« Reply #21 on: February 20, 2017, 05:49:53 pm »
I've grown generally pretty skeptical of RAD development as defined by Delphi and Lazarus. RAD often just leads to bad design, where the non-UI code is all mixed into the form code files.
It is indeed possible to write very bad code.
That doesn't mean that it's not possible to do things better.
I tend to make good use of units, classes, interfaces - so that the form code stays clean.

The other advantage to a Web version is that it would mean you wouldn't necessarily have to do all desktop and mobile platforms, since users of unsupported platforms would at least have a Web-based fallback to use.
I am hoping to combine web and desktop into one application.  :)

Using mORMot (mORMotFPC).
« Last Edit: February 20, 2017, 05:59:52 pm by jacmoe »
more signal - less noise

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Database for small GTD Todo application
« Reply #22 on: February 20, 2017, 08:49:57 pm »
I tend to make good use of units, classes, interfaces - so that the form code stays clean.

Well, not exactly. Separating non-UI from UI code means that the non-UI units, in general, do not have any dependencies on any Lazarus units. They only depend on FPC RTL and package units and similar units that also depend only on that, for example Web Service Toolkit (http://wiki.freepascal.org/Web_Service_Toolkit). The UI units are lean and do not contain any "business code" or code that you want to use cross-platform.

I am hoping to combine web and desktop into one application.  :)

Hmm, that statement does not make any sense to me. Maybe you could describe in a couple of sentences how you understand "cloud aware". I don't think we're talking about the same thing at all.

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: Database for small GTD Todo application
« Reply #23 on: February 20, 2017, 10:26:21 pm »
Well, not exactly. Separating non-UI from UI code means that the non-UI units, in general, do not have any dependencies on any Lazarus units. They only depend on FPC RTL and package units and similar units that also depend only on that, for example Web Service Toolkit (http://wiki.freepascal.org/Web_Service_Toolkit). The UI units are lean and do not contain any "business code" or code that you want to use cross-platform.
I do understand what you mean.

And I have been using that approach before, in C++, where the UI code was completely separate from the base.
That was advantageous, because it allowed us to easily port from MFC to wxWidgets to Qt.
While at the same time maintaining the ability for the application to run on Linux/Windows/Mac.

There are complexities and problems with that approach, however.
Especially if you are not going to use anything other than Qt.
In which case it would make much more sense to not have to go through the base layer and our custom property macros, when Qt has all of that already (and much more elegant).

However, I usually separate UI and logic, and take care to not pollute my units with too many dependencies.

When the time comes, I am sure that it will be possible to factor out common code, and factor out UI-less common code as well.

For now, though, it is too early to be doing any of that.
Except the clean code bit.

I am hoping to combine web and desktop into one application.  :)

Hmm, that statement does not make any sense to me. Maybe you could describe in a couple of sentences how you understand "cloud aware". I don't think we're talking about the same thing at all.
It sounded much better yesterday, when I wrote it, just before getting to bed.
Now, I am sure what it means either.  :D

I guess I meant that I want the application to be self-sufficient.
« Last Edit: February 20, 2017, 10:48:46 pm by jacmoe »
more signal - less noise

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Database for small GTD Todo application
« Reply #24 on: February 20, 2017, 10:57:33 pm »
There are complexities and problems with that approach, however.
Especially if you are not going to use anything other than Qt.
In which case it would make much more sense to not have to go through the base layer and our custom property macros, when Qt has all of that already (and much more elegant).

Well, wxWidgets and Qt like you to subclass the wxWidgets and Qt classes, everything from the main application class down to the string class. The downside of that is that if you pull your non-UI C++ code out of the main GUI app and put it in a console app or dynamic library, you still have to include some rather large wxWidgets and Qt DLLs, even though you're not using the GUI parts. I've always though that was a pretty dreadful approach. (wxWidgets 3.1 DLLs: 10.6 MB with 32-bit Windows; QT 4 DLLs: 44 MB with 32-bit Windows.)

Incidentally, wxWidgets historically has been pretty awful on Mac. My experience is that it's hard for two apps that use wxWidgets to co-exist together on a Mac. Hence on Mac you'll only find wxWidgets apps that started out on Windows, for example, and then brought over to Mac, bad ideas and all. I suppose C++ developers deserve wxWidgets.

Qt behaves better on Mac and looks pretty good superficially, although the apps still have that I've-just-been-ported feel to them in many cases. For example, they're never document-based, even though Mac apps normally are document-based. Even Xcode is document-based, meaning you can open up multiple projects at the same time.

You won't find any wxWidgets users here. And Qt is pretty much confined to Linux with Lazarus.

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: Database for small GTD Todo application
« Reply #25 on: February 20, 2017, 11:43:46 pm »
I didn't like wxWidgets (still don't), so I ported the application to Qt, and the rest of the team loved it, so it became the official GUI client.  ;D

The reason for wxWidgets was because it was (still is, I guess) very close to MFC, so it was easier to get a cross platform ready gui client up and running.
wxWidgets, unfortunately, does not behave and look the same on each platform, and it also had bad Windows 7 support (IIRC), so we needed something that performed well, looked great (on all platforms) and - most importantly: behaved consistently on all platforms.

The reason why some people still prefer wxWidgets is that you can statically link it in, alleviating the need to ship a ton of DLLs.
Qt has LGPL without any static linking exception, so you need an expensive license to be able to deploy statically linked apps.
Qt is neat, though: a great designer, well written library, and one thing that I especially appreciate is the fact that you can use styles (CSS like) so that your application looks great.

Lazarus, is going to be great.
Because Object Pascal is much more suited than C++ IMO.
Real properties, no macro voodoo.
more signal - less noise

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Database for small GTD Todo application
« Reply #26 on: February 21, 2017, 07:29:06 pm »
The reason why some people still prefer wxWidgets is that you can statically link it in, alleviating the need to ship a ton of DLLs.

A wxWidgets app that I've been using for several years has over 70 dynamic libraries linked against the wXWidgets libraries, so statically linking wxWidgets code into all of them probably isn't very practical.

Note that the last time I compiled wxWidgets on my Mac, it took about 30 minutes. But maybe that's normal for C++; it probably wouldn't be considered acceptable for Pascal, though.

The entire process for building SAGA and its dependencies took several hours as I recall. I wrote up some instructions so others could avoid much of the pain of building with C++:

https://sourceforge.net/p/saga-gis/wiki/Compiling%20SAGA%20on%20Mac%20OS%20X/


jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: Database for small GTD Todo application
« Reply #27 on: February 21, 2017, 08:46:17 pm »
Ironically, Lazarus stopped being cooperative today and disallowed me to use mORMot with the following message:
Quote
mORMot.pas(59681,33) Error: Class or Object types "TSetWeakZeroClass" and "TSQLRecordProperties" are not related
more signal - less noise

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: Database for small GTD Todo application
« Reply #28 on: February 21, 2017, 08:54:45 pm »
You have to disable "Verify method calls" when debugging !
Remove option -CR, or uncheck in Lazarus.

jacmoe

  • Full Member
  • ***
  • Posts: 249
    • Jacmoe's Cyber SoapBox
Re: Database for small GTD Todo application
« Reply #29 on: February 21, 2017, 08:56:34 pm »
Excellent!  ;D ;D That did the trick.  :D

I probably should get familiar with the project options - compiler / linker settings.
more signal - less noise

 

TinyPortal © 2005-2018