Java app for finding common ancestors between two people

[Eric E]

When it comes to Genealogy I'm at the shallow end of the pool.  However, I've always wished for the ability to take who curious folks and find their nearest common relative. 

I want to connect to FamilySearch and progressively download data of any two (deceased persons and eventually dig deep enough that a common link can be found.

I've stumbled into some Java libraries but they clearly state that they don't provide any networking code for connecting or authenticating to the FamilySearch site

The following libraries are available for use in consuming and producing FamilySearch Platform API. They provide objects that reflect the structure of the APIs. They do not provide networking code.

I'm comfortable with java as a language, and xml as well, but json and http (most anything web) is still rather alien to me.

I'm looking mostly for direction as I research the feasibility of this project and perhaps somone could point me to some samples where basic queries are made using these libraries.

Any help is appreciated.

Eric

[Ryan Heaton]

Hi Eric.

Welcome.

So are you asking for Java help? Or help with the APIs? Or both?

--
 
---
You received this message because you are subscribed to the Google Groups "rootsdev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rootsdev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Eric E]

I'm comfortable overall with java as a language (desktop apps at the least).

The FamilySearch API is different.  I'm seeking guidance with integration into a java app.  The examples I find on their site seems targeted only for web app integration.  After I registered my application with them I also need to provide a forwarding link.  This step has me stumped as I intend to first develop my app as a desktop application and then alter port to an android app.  Every instance of my application would need to be able to authenticate but a single forwarding address doesn't seem to allow for this.

Recommendations?

[Ryan Heaton]

Sorry for the late reply.

The examples I find on their site seems targeted only for web app integration.

How so? It’s all about HTTP, which is common to both web apps and desktops, no?

After I registered my application with them I also need to provide a forwarding link.

Forwarding link? Do you mean the redirect URI? Are you trying to use the OAuth2 authorization grant flow? Because your application, being a mobile app, seems more amenable to the username/password flow, no?

By the way, I think these kinds of questions are best directed over at the FSDN. I think you’ll find a faster response time.

-Ryan

[Thomas Wetmore]

It is important for programmers just starting out to understand the differences between model, view and control code. It applies in spades to the common ancestor program.

The pure model code for finding common ancestors is trivial:

Set commonAncestors (Person a, Person b)

{

initialize set A with person a;

initialize set B with person b;

while (intersection(A, B) is empty) {

A = union(A, parents(A));

B = union(B, parents(B));

}

return intersection(A, B);

}

Yes, the model code for this problem is this simple. This is called model code because it is based solely on data structures and quasi-mathematical operations on those data structures. The programming language I provide in the LifeLines system can be programmed to implement this program nearly exactly as shown here. If anyone would like to see complete LifeLines code to solve the common ancestor problem let me know.

The view code is code in GUI applications that displays windows and views on the screen. Control code is responsible for using the data in the model to build the windows and views.

The code to drive the API to FamilySearch is an example of control code. It should never be mixed with model or view code. In this very simple problem, that API code should only exist in one place. Let's find that place. Say the implementation of "parents (Set set)" is the following:

Set parents (Set A)

{

Set parentsSet = new Set;

for (Person p in A) {

parentsSet = union(parentsSet, parents(p));

}

return parentsSet;

}

This is model code also -- pure data structures and quasi-mathematical (actually wholly mathematical in this case) operations.

But we have now reached the level where we need control code, in order to implement the "parents(Person p)" function. (There are two functions called "parents" here, one that takes a Set as a parameter, which is model code, the other that takes a Person as parameter, which is control code -- sorry for the minor confusion):

Set parents (Person p)

{

create FamilySearch API request to return the parents of Person p;

send the request;

create a set of 0, 1, or 2 persons based on the results of the request;

return the set;

}

With this approach all API-control code is relegated to small, trivial modules that perform single, self-contained operations, as required either by model or view code.

If you learn early to structure your code along these three functional lines you will be able to mix and match software for many situations. Note, for example, that the pure model code above could care less about how parents are actually found. By simply replacing the single, control-level function "parents (Person p)" you can make this program work with, for example, local flat files or databases on your local machine, other on-line services that use other APIs, and so on. Alternatively, by changing only the view code (leaving the model code and control code intact), you could convert this program into a command line program, or a GUI application that uses an entirely different graphical user interface.