The Database Update - Part 6

Though it was dreaded, the Permanent Clips/Macros and Edit History windows no longer makes sense as separate windows. The two have been combined into a single "Edit Clips" window.

This change means a few things. It's a good time to fix the issues with these old windows. Copying clips from another instance will be more intuitive. And, it's also going to delay the next Beta.

The Database Update - Part 5

Automation

ArsClip has a few well known execution methods. The most popular, by far, is running from the local hard drive. All other methods of execution serve one purpose: to copy the program anywhere and it will just work.

Windows has plenty of options to ensure data integrity when multiple programs or users all want to use the same shared file. There's nothing useful for programs that are disconnected. It's the same problem that existed when Palm Pilots were popular. Two disconnected programs that try to share data once connected can overwrite each others changes. This is effectively the same issue with cloud syncing.

To have ArsClip work as expected and run from "anywhere", some automation is needed. First, ArsClip will detect when it is run from a USB drive. In this mode, ArsClip will use a single database to for clips. Second, ArsClip will detect when it is run from a remote folder (UNC or mapped drive). Lastly, it will run in compatible mode for a normal local install that may be cloud synced.

The effect is as follows: USB users will see the same data no mater what computer they use. Remote users (cloud/shared folder) will always see device dependent data. ArsClip will use the name of the current computer to individualize clips. Local drive users follows the same rules as the remote users, but effectively will only see the same data. The name of the computer is used to individualize databases.

There is still work to be done to cover the cases when a local install is moved to a USB or when a local install is moved to another computer. For the latter, some user interaction may be required.

The Database Update - Part 4

"Never" was the answer for when I would add an option to share a clipboard. Technically, this answer is the same today. ArsClip does not send clips to other instances over the Internet. ArsClip will be cloud compatible, but it won't directly use the cloud nor will it require and Internet connection.

The new test version does allow for a Global Clipboard via a configuration option, but you have to provide the mechanism for connections. To do this, all instances run from the same folder use a single location to save information about the instance and the changes to the local clipboard. This means that all you need to do is provide a way for other computers to access the ArsClip folder. A network share, VPN, mirroring utility, or cloud folder sync program can perform this task. The ultimate end is to also allow ArsClip Mini to do the same thing, but Android will need to use a cloud App service exclusively as the mechanism for connection.

The Database Update - Part 3

First, a big thank you to to all the beta testers. There are so many cases to test that I miss on my own. For example, I forgot about the date routines on non-US English systems. I also forgot to test running the program on a clean install.

The current test versions do just enough get the existing code to work with the database. Many of the previous design choices made aren't needed and are inefficient. The next changes will be to improve the code to make better use of database.

EDIT: The Plans and Ideas section for ArsClip has been updated.

The Database Update - Part 2

Code that has not been touched in years was reworked/replaced to support database storage. It was a lot of work, but the code is now cleaner and more reliable.

Permanent Clips are now imported in the database. The "everything is a clip" design works well. There are no more special cases to handle. Removed Clips can be deleted without having to erase the entire cache.

There's still more work to be done. For example, the program still relies on Permanent Clips/Macros having a folder, even though the program reads and writes to the database.

Lots of bug, including many old bugs, have been fixed in the latest update. For example, the Removed Clips list in Edit History didn't show new clips as they were added when the form was open.

The Database Update

The current Public Beta test of ArsClip imports all data into a single database file on the first run. After the import, all reads and writes are perform on the database. On most systems, the import is so quick that it won't be noticed.

The Removed Clips tab in Edit History is much faster. Instead of hundreds of reads on small files, one read is performed on an optimized file format. Removed Clips can now easily handle thousands of clips. Also, it will be possible to delete clips from the Removed Clips in a future test version.

Popup Clips still work the same as before. They are stored in memory for speed. In the background, the list is periodically stored to disk. These clips are marked with the name of the machine that ArsClip is running. Each machine has its own list.

This database change is also for cloud compatibility. When the ArsClip folder is synced with a cloud utility, there won't be any conflicts with multiple instances overwriting data. The down-side is that then entire database file must be uploaded, instead of just the new/changed files.

The database used is SQLite3. It is a popular cross-platform specialized format for running on a single machine. It's what Android uses, so it's perfect for later integration. This also means that advanced users can use one of the many open source GUIs to view and edit the database.


The current TODO list for upcoming test versions:
- change Edit History to show Popup Clips from other machines
- change Edit history to allow deletes of Removed Clips
- implement a "shared clipboard" option
- fix bugs

The current IDEAS list:
- investigate if having an option for "on disk" popup clips, instead of in-memory, is a good idea

More Status Stuff

Work has begun on the next ArsClip beta (Windows) for cloud compatibility. Currently, the official program mostly when placed in a folder linked to a cloud storage application. Conflicts arise when the program is run from two locations at the same time. The popup clip history can be overwritten by both programs.

The "quick fix" would be just to create separate folders for popup clips for each instance. All other items and clips would be shared. The real fix requires much more work. The clip data truly belongs in a database. This allows for more flexibility and future expansion; as well as ArsClip Mini data sharing.

ArsClip Mini behind the scenes

Currently, backup has been researched and partially implemented. Google's built in support just isn't working as expected. It backs up the settings just fine, but is not working for the clip database. At this point, the program seems to require integrating with Google Drive and/or Dropbox to work as needed.

The way backup is designed will influence how cloud sharing can work. Some important decisions must be made before starting. The easiest and safest way to design the data would be to keep each device's data separate, but allow browsing of another device's data under the same logon. The cloud service would handle almost all of this work.

The format of the backup data also is an issue. The database used works great for multiple Android devices, but is a huge unknown on Windows and Delphi. Sharing between desktop and Android would be very nice, but the Android user base is still very small. The Windows users would rather have a version of ArsClip that can safely run off of a cloud service.

In any case, a version of ArsClip Mini with automatic backup/restore on install is delayed.