Wednesday, February 22, 2012


Work is now completed on version 0.6 of GEDCOM-DDL. This is a transformation of the platform independent GEDCOM-UML model, into a database model along with SQL DDL for creation of a SQLite 3 database. This new model is cast in database terminology so it shows tables instead of classes and keys instead of associations. The versions of GEDCOM-DDL and GEDCOM-UML are both 0.6, because I hope to keep the two models in-sync.

Earlier, I posted an analysis of the file size limitations of ezGED Viewer. Now that I have a database schema for storing GEDCOM file contents, I hope to overcome the input GEDCOM file size limits. The size of a SQLite database file will only be limited by the file system in which it is stored. For the FAT32 file system, used on common SD cards, this limit is 4 gigabytes -1.

Friday, February 3, 2012


More progress has been made with the GEDCOM-UML, requiring a version bump to 0.6. The main improvements are:

  • fields with explicit lengths now use the char[n] type (where n is the array size) rather than String
  • documentation has been added to all classes and class members 
  • "tag context" entries have been added to all members to provide  references back to the GEDCOM tag sequence which contributes the member's value

There is still room for more improvement, such as adding some additional types for dates and ages, and enumerations for languages, pedigree linkage types and status, as well as LDS ordinance status values. These are currently represented as char arrays.

Work is far enough along, that I will be turning my attention to the corresponding physical data model for a database schema. Stay tuned ...

Friday, January 27, 2012

GDMUML Resurrected

Some 10 years ago I was working on a software model derived from the GENTECH Genealogical Data Model. I set up the GDMUML (Genealogical Data Models in the Unified Modeling Language) website to publish that work.

I have recently "spruced-up" GDMUML's existing web pages and have begun adding new content. The first addition is GEDCOM-UML. This is a UML model for the contents of a GEDCOM file. It includes elements from both versions 5.5 and 5.5.1, so that the differences can be more clearly seen. The model attempts to accurately reflect the specifications rather than current usage by genealogy applications.

The model is arbitrarily pegged at version 0.5 because there is more work to be done. For example, initially all class members were typed as String. I'm now adding the explicit field lengths by changing the type to char array. Documentation of the classes and class members also remains to be done. Also, each member is getting a "tag context" entry which references back to the GEDCOM tag sequence which contributes the member's value.

There are several motivations for doing this. Since GEDCOM is the defacto standard for genealogical data interchange, we are probably going to have to live with it for some time to come. A clear blueprint for its current design should help with the design of future extensions. For existing applications that support GEDCOM import/export, having a reference design should help in validating conformance. And last, but not least, a normalized UML model can be exported as a database schema: GEDCOM-DDL.


Monday, January 16, 2012

Setting ezGED preferences

Like other android apps, ezGED Viewer has some application settings that control aspects of the program's behavior. To reach these settings, use the menu button to access the Options Menu containing the Settings and About items, as shown below:

Then click the Settings button to reach ezGED's Preferences:

There are currently two File Preferences:
  • Create cache files
    If this preference is checked, then when a GEDCOM file is parsed the first time, the internal representation of the GEDCOM's structure is stored to a binary cache file. On subsequent loads of the identical GEDCOM, the cache file is loaded instead, saving having to reparse the file. Any changes to the GEDCOM file will cause the file to be reparsed. Cache files can be removed using the file manager's Clear cache file and Empty cache directory context menu commands (see Using ezGED's file manager).
  • Enable file auto-load
    If this preference is checked, then when is ezGED is launched, a preferred file will automatically be loaded, bypassing the file manager. This is convenient if you are working with a single file and don't want to repeat the same file manager navigation steps each time. The preferred file is set using the file manager's Set auto-load file context menu command (see Using ezGED's file manager).


Tuesday, January 10, 2012

ezGED's file size limits

I have anticipated writing this post since the first day ezGED Viewer was released. Eventually someone will try a 20 megabyte GEDCOM file and be disappointed with the result. That day has now arrived.

This has been a known limitation of the 1.0 version of the software. The maximum GEDCOM file size is essentially bound by the amount of memory available to store the file's in-memory representation. Each android application gets a "heap" of memory to work with. A lot of this memory will already be used for GUI resources, what remains can be used for data storage. Typical android 2.x smartphones are allocated 24 megabytes of application heap, while 3.x tablets are allocated 48 megabytes.

To measure ezGED's capacity limits, the app's fan value has been determined when running on a smartphone and a tablet. The fan value is a measure of the number of ancestral generations an application can handle. It is a rough measure of the capability of an application and it can be easily determined using a standard set of GEDCOM files created by Tamura Jones' GEDFAN test tool version

Here are the test results for ezGED v1.0.1, using a LG Optimus V smartphone and Acer Iconia Tab A100 tablet:
FAN#IndividualsFileNameFileSizeSmartphone 1.6-2.3 (24mb heap)Tablet 3.x (48mb heap)
1416,383FAN14.GED2,913,929Force close at 67%OK
1532,767FAN15.GED6,073,397Force close at 31%Force close at 58%
1665,535FAN16.GED12,416,621Force close at 15%Force close at 28%

Fan values range from 1 to 24, but the larger values are not displayed because they are currently outside the range that ezGED can accept. As you see in the table, the smartphone can not load FAN14.GED. The parser progress bar will get to 67% completion and then the app will close. The tablet does a little better, since it can load FAN14.GED. However, when the tablet loads FAN15.GED, it parses 58% of the file when the app closes. We might peg ezGED's fan values at 13 for smartphone and 14 for tablet, but those are a tad optimistic since performance of the app drops off when pushed to the limit. For comparison, here is a link to fan values for some MS-Windows desktop applications: Some GEDCOM Fan Values.

The "FAN" files are quite simple consisting of individuals, families, and lineage-links for the most part. There are no notes, sources, or events. Real GEDCOM files contain a richer variety of content, so for an equivalent number of individuals, the file size would be larger.

ezGED's file size limitation is clearly an area that needs some rework. There are two things we hope to improve in future versions:
  • Provide an appropriate message when the application is going to run out of memory and gracefully terminate or abort the file load.
  • Improve the fan number by using SQLite storage rather than keeping everything in memory.

Sunday, January 8, 2012

Using ezGED's file manager (updated for 1.0.1)

Getting back to work here after the holidays. There is still some unfinished business with the product documentation. I'll begin with a first installment on the file manager ...

The first view you see when you launch ezGED Viewer, is a file manager. This acts as a "file picker" to allow you to navigate through the file system to the ".ged" file you wish to open. The screen shot below shows the contents of the directory /mnt/sdcard (the caption under the action bar always displays the current directory).

This view can show three types of entries.

The green arrow at the top of the view, moves up one directory level in the file system, when it is clicked.

The folders, such as "Android", "DCIM", etc. represent subdirectories that if clicked, cause the current directory to move down one level, to the clicked directory.

The only files displayed will be GEDCOM files with a ".ged" extension. These are represented by tree icons. When one of these is clicked, the GEDCOM file will be opened and processed to graphically display its contents. The file size in bytes and directory are listed under the file name.

In the upper right corner of the action bar there is a "refresh" icon. When this is clicked the contents of the view are regenerated. This is useful if files are copied to your device after ezGED has already been launched.

Context Menus (Updated for 1.0.1)
Context menus pop up when you make a "long press" on a file or folder.
The context menu for the file FAN10.GED looks like this.

The options here are:
Open - clicking this will open FAN10.GED.
Set auto-load file (new v1.0.1) - clicking this option will store the path of FAN10.GED as the auto-load file; if the Setting:Enable file auto-load is enabled, then when ezGED is first launched, this file will be automatically loaded, bypassing the file selection step.
Clear cache file - if the Setting:Create cache files is enabled, then when a ".ged" file is first opened and processed, ezGED's internal representation of the GEDCOM is stored in a ".cache" file under the directory /mnt/sdcard/ezged; if the original GEDCOM file is not changed, then on subsequent opens the ".cache" file is used. Clicking on this option will delete the corresponding ".cache" file so that when FAN10.GED, is opened again it receives fresh processing.
Empty cache directory - clicking this option deletes all ".cache" files from /mnt/sdcard/ezged.

The context menu for /mnt/sdcard/download looks like this.

The options here are:
Empty cache directory - clicking this option deletes all ".cache" files from /mnt/sdcard/ezged.
Set home directory - clicking this option sets the selected directory (/mnt/sdcard/download) as the initial directory the next time the ezGED file manager is launched.

Wednesday, January 4, 2012

ezGED Viewer v1.0.1

Happy New Year!
ezGED Viewer version 1.0.1 has now been released.

Here is a list of the changes.
Bug fixes:
  • Force Close when searching for an Individual surname
  • Force Close on entering Individual Details view
  • Force Close on filling the Families view
  • Corrected layout bug in the Reports view, where the "Focus name" label drifted away from its underlying drop down menu.
  • In Individual Details views, buttons previously labeled with IDs are now labeled with names.
  • In the Reports view, the drop down menu of focus persons are now sorted by surname, then given name.
New Feature:
  • Added Settings checkbox for "Enable file auto-load"; if this setting is enabled, then a new file manager context menu command, "Set auto-load file", specifies a file to be automatically loaded when ezGED launches.

Popular Posts


Total Pageviews

Follow by Email