Re: [Ward Tools] Re: Ward Tools transition to LDS Tools
16 views
Skip to first unread message
Andy Wilbourn
Dec 8, 2010, 1:50:11 PM12/8/10
to ward-to...@googlegroups.com, stephan...@gmail.com
Stephan,
There is a different distribution for the development side of things. The address you sent to is more community support.
I think the LDS Tools for the iPhone is a pretty good product and since it works with the new web API stuff yours would be more the place to go.
We have wondered what the status of HT/VT is to make available, as that seems to be one thing we have you don't (based on the export of MLS data).
So at my intent here is to put you on the right group and give a quick feedback. I have been focused on the Blackberry Edition, have created a converter in Java for the MLS to the database format (SQLite) that is used for Android. We adopted LDSql from Ross Evans, http://www.ldsql.com/. We had hoped to use it for multiple platforms (iPhone, Blackberry, Android and Windows Mobile), but there were limitations or really need to have someone rewrite the apps that were based on the current Palm database format (PDB files). I did not use it for Blackberry as only OS 5 and higher support SQLite by default, so I ended up creating classes to hold the data.
I for one have used this project to pick up new skills, so I would not say my Blackberry code base is the best. As well for the desktop converter I created, that was my first production type of app I wrote in Java. I normally program in C# for my stuff I do in my day job, but don't do that as much anymore as I am now a Business Intelligence developer using Cognos and Microsoft Analysis Services products for OLAP cubes.
-Andy
On Wed, Dec 8, 2010 at 11:56 AM, Stephan Heilner <stephan...@gmail.com> wrote:
My name is Stephan Heilner. I'm the lead on the LDS Tools iOS project
here at the LDS Church. I'm really excited to have you guys on
board! What we're hoping to do is combine the two projects into one.
We have alot of decisions to make before we get started on this
though.
We first decision we need to make, is whether it makes more sense to
use the existing WardTools code base, the LDS Tools code base, or to
start fresh. My opinion is that the WardTools code base is probably
the most stable and robust, but I'm not very familiar with it. I'm
hoping that those of you who are very familiar with the WardTools will
speak up and offer your opinions on this.
If we do move forward with the WardTools code base, we'll need to
change how it imports data. I'll get us access to the data and
reports through JSON web services, so we don't have to do the whole
MLS export/ convert/ import process anymore. This should make it
easier for users and easier for us to maintain. The other benefit is
that it allows us to make sure that ONLY the people who are authorized
to have the data get access to it.
We also need to look at how to add the features we have in LDS Tools
to the WardTools project. Many of our users aren't leaders and won't
have access to leadership reports.
What are your thoughts?
Stephan
On Nov 21, 9:19 am, Calvin Gaisford <calvi...@gmail.com> wrote:
> Hello Ward Tools users,
>
> I'm sending this email on behalf of all of the Ward Tools development
> community. We hope you'll find this news enlightening and encouraging
> as to the future of the Ward Tools solutions. The following
> announcement is is also posted on the wardtools.org website:
>
> The Ward Tools project recently donated its code and intellectual
> property to The Church of Jesus Christ of Latter-day Saints. This was
> done to facilitate the distribution of the benefits of Ward Tools to
> as many members as possible.
>
> The Church recently released a new app named LDS Tools. LDS Tools is
> a member focused tool that provides up-to-date listings all of the
> Wards in a member's Stake along with the leaders in the stake and each
> unit.
>
> The Ward Tools development community will be joining the development
> efforts going on at the Church to introduce many of the Ward Tools
> features into LDS Tools. Until those features are available in LDS
> Tools, the Ward Tools products will continue to be maintained for your
> use.
>
> Thank you for your support, and we look forward to your help as we
> make the transition from Ward Tools to LDS Tools.
>
> I'm sure there will be a lot of questions, please be patient as we'll
> attempt to answer all of them using this email group.
>
> -Calvin
--
You received this message because you are subscribed to the Google Groups "Ward Tools" group.
To post to this group, send email to ward...@googlegroups.com.
To unsubscribe from this group, send email to wardtools+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/wardtools?hl=en.
boomerbubba
Dec 8, 2010, 2:43:08 PM12/8/10
to Ward Tools Development
Hi, Stefan. Ross Evans here (aka boomerbubba)
Andy's message shows how the Ward Tools code base is actually several
different sets of code right now:
1) Calvin's traditional Ward Tools products for iPhone, Windows Mobile
and legacy Palm. These products use an older .pdb file format from
Palm that not even Palm supports any more.
2) Steve's Android apps using SQLit (the LDSql schema as an
intelligent back end).
3) Andy's Blackberry app, which has its own architecture.
Until early this year we had the vision of using LDSql as a common
back end for as many platforms as possible, which theoretically would
make much of the logic quite common and portable because most of the
business logic is done within SQLite. The Android app was built on
that foundation, and the idea was that future development for the
iPhone would be converted to that architecture going forward.
That plan was stymied last spring when the Church blocked our access
to a common set of anonymized MLS test data at the stake level. (We
already had such data at the ward MLS level.) So the Android app
lacks stake functionality. Also, because about half the existing
users for iPhone and Windows Mobile are stake leaders, that meant
Calvin could not convert those apps to the common SQLite back end.
Meanwhile, Andy also needed to support stake data for the Blackberry,
and also wanted to suport older Blackberry OSes that did not handle
SQLite.
So one big architectural issue is whether the Church Community project
would try to have a common SQLite back end at all to maximize
portablilty, or not. The dev model used for the rank-and-file LDS
Tools app obviously makes no attempt at a common architecture. Each
platform is developed in a silo with its own independent dev team and
architecture. My personal opinion favors maximizing use of a common
back end, but that does not seem to be the way the LDS Tools project
has proceeded to date. A related issue is whether the expanded LDS
Tools for priesthood leaders (the Ward Tools-like app) would have
anything in common with the rank-and-file apps now being developed as
LDS Tools. Since these more restircted apps have been built in silos,
that might mean the expanded app also has to be built in silos.
--Ross
On Dec 8, 12:50 pm, Andy Wilbourn <awilbo...@gmail.com> wrote:
> Stephan,
> There is a different distribution for the development side of things. The
> address you sent to is more community support.
>
> I think the LDS Tools for the iPhone is a pretty good product and since it
> works with the new web API stuff yours would be more the place to go.
>
> We have wondered what the status of HT/VT is to make available, as that
> seems to be one thing we have you don't (based on the export of MLS data).
>
> So at my intent here is to put you on the right group and give a quick
> feedback. I have been focused on the Blackberry Edition, have created a
> converter in Java for the MLS to the database format (SQLite) that is used
> for Android. We adopted LDSql from Ross Evans,http://www.ldsql.com/. We had
> > wardtools+...@googlegroups.com<wardtools%2Bunsubscribe@googlegroups.com>
> > .
>
> - Show quoted text -
Andy's message shows how the Ward Tools code base is actually several
different sets of code right now:
1) Calvin's traditional Ward Tools products for iPhone, Windows Mobile
and legacy Palm. These products use an older .pdb file format from
Palm that not even Palm supports any more.
2) Steve's Android apps using SQLit (the LDSql schema as an
intelligent back end).
3) Andy's Blackberry app, which has its own architecture.
Until early this year we had the vision of using LDSql as a common
back end for as many platforms as possible, which theoretically would
make much of the logic quite common and portable because most of the
business logic is done within SQLite. The Android app was built on
that foundation, and the idea was that future development for the
iPhone would be converted to that architecture going forward.
That plan was stymied last spring when the Church blocked our access
to a common set of anonymized MLS test data at the stake level. (We
already had such data at the ward MLS level.) So the Android app
lacks stake functionality. Also, because about half the existing
users for iPhone and Windows Mobile are stake leaders, that meant
Calvin could not convert those apps to the common SQLite back end.
Meanwhile, Andy also needed to support stake data for the Blackberry,
and also wanted to suport older Blackberry OSes that did not handle
SQLite.
So one big architectural issue is whether the Church Community project
would try to have a common SQLite back end at all to maximize
portablilty, or not. The dev model used for the rank-and-file LDS
Tools app obviously makes no attempt at a common architecture. Each
platform is developed in a silo with its own independent dev team and
architecture. My personal opinion favors maximizing use of a common
back end, but that does not seem to be the way the LDS Tools project
has proceeded to date. A related issue is whether the expanded LDS
Tools for priesthood leaders (the Ward Tools-like app) would have
anything in common with the rank-and-file apps now being developed as
LDS Tools. Since these more restircted apps have been built in silos,
that might mean the expanded app also has to be built in silos.
--Ross
On Dec 8, 12:50 pm, Andy Wilbourn <awilbo...@gmail.com> wrote:
> Stephan,
> There is a different distribution for the development side of things. The
> address you sent to is more community support.
>
> I think the LDS Tools for the iPhone is a pretty good product and since it
> works with the new web API stuff yours would be more the place to go.
>
> We have wondered what the status of HT/VT is to make available, as that
> seems to be one thing we have you don't (based on the export of MLS data).
>
> So at my intent here is to put you on the right group and give a quick
> feedback. I have been focused on the Blackberry Edition, have created a
> converter in Java for the MLS to the database format (SQLite) that is used
> hoped to use it for multiple platforms (iPhone, Blackberry, Android and
> Windows Mobile), but there were limitations or really need to have someone
> rewrite the apps that were based on the current Palm database format (PDB
> files). I did not use it for Blackberry as only OS 5 and higher support
> SQLite by default, so I ended up creating classes to hold the data.
>
> I for one have used this project to pick up new skills, so I would not say
> my Blackberry code base is the best. As well for the desktop converter I
> created, that was my first production type of app I wrote in Java. I
> normally program in C# for my stuff I do in my day job, but don't do that as
> much anymore as I am now a Business Intelligence developer using Cognos and
> Microsoft Analysis Services products for OLAP cubes.
>
> -Andy
>
> On Wed, Dec 8, 2010 at 11:56 AM, Stephan Heilner
> <stephanheil...@gmail.com>wrote:
> Windows Mobile), but there were limitations or really need to have someone
> rewrite the apps that were based on the current Palm database format (PDB
> files). I did not use it for Blackberry as only OS 5 and higher support
> SQLite by default, so I ended up creating classes to hold the data.
>
> I for one have used this project to pick up new skills, so I would not say
> my Blackberry code base is the best. As well for the desktop converter I
> created, that was my first production type of app I wrote in Java. I
> normally program in C# for my stuff I do in my day job, but don't do that as
> much anymore as I am now a Business Intelligence developer using Cognos and
> Microsoft Analysis Services products for OLAP cubes.
>
> -Andy
>
> On Wed, Dec 8, 2010 at 11:56 AM, Stephan Heilner
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/wardtools?hl=en.- Hide quoted text -
>
> - Show quoted text -
boomerbubba
Dec 8, 2010, 3:20:58 PM12/8/10
to Ward Tools Development
p.s. Sorry I mispelled your name, Stephan. I know another Stefan and
got confused :-)
> > >http://groups.google.com/group/wardtools?hl=en.-Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
got confused :-)
>
> > - Show quoted text -- Hide quoted text -
Andy Wilbourn
Dec 8, 2010, 3:30:53 PM12/8/10
to ward-to...@googlegroups.com
I would also include the Ross have a great deal of knowledge of MLS and is a clerk, unless he recently was released. So he has been a very valuable member to the development team, although he is more focused on the database backend rather than the application programming (Java, Objective-C, or C).
The first version Calvin created has reuse of the code for pulling data from the database. I have also played around with the iPhone version and have access to the Apple developer site, which I am not sure how that will be done going forward as you have to create accounts for the users to allow them to debug on a device. How is that done for LDS Tools? Perhaps you are the only one to code and it has not been a problem, or you other developers have to use the simulator only.
Nate Davis
Dec 8, 2010, 4:24:40 PM12/8/10
to ward-to...@googlegroups.com, Stephan Heilner
Hello Andy,
My name is Nate Davis and I am a community developer for LDS Tools. I can't speak on behalf of everyone, but will give my personal thoughts on where LDS Tools can go in the future.
The 5 or so of us that have been volunteering time with LDS Tools develop with our own personal Apple Developer accounts. We deploy to our iPads, iPhones, and such. We just checkout the code via SVN, and change the bundle identifier to match our accounts, and just never commit that .plist file. Allowing us to modify and make changes and run with it and have everyone test and such. Some people use the simulator, but 4 of us for sure use devices to test. We all use our LDS Accounts to test.
The Directory team at the church are the ones who expose Services for our volunteer team to use. They have been willing to discuss exposing more and more data as they can. They have not exposed Home Teaching and Visiting Data yet. I am thinking they have to work on how they will store the data and such. That has not been on the Send and Receive from MLS. Right now from what I know, Membership records, callings and financial data are the only things transferred and synced from MLS with The Servers at Church HQ. The Home Teaching and Visiting Teaching data is only stored locally. But backed up monthly at the church with the entire MLS data file.
I agree that a standard data access layer should be put into place. I think the directory team has this in place, and Stephan can get us more documentation as to what is available. All apps from the church must use these services, so the blackberry, iPhone, and android apps will have all the same data access. It will just be working hard to ensure all the apps have the same features....
I have loved working with LDS Tools. It has helped me to learn more about iOS and how services work.
As a Ward Clerk, Exec Sec, and now Stake Clerk, I have loved using Ward Tools to get access on my mobile, but as the church changes exports from MLS, I love having the data synced over the air. It will be nice with access levels determined by callings, and allow the church to manage the privacy that needs to be there. That was one thing I didn't love about the MLS export, it included all the sensitive info for everyone to export (with admin rights). It was really a love hate relationship :)
I think we can implement reports, and some stronger classes that might be more portable. That is where I feel the community developers of Ward Tools can really give us some wonderful input and contribute to an amazing resource for all us members.
Those are my thoughts,
Nate
Sent from my iPhone
Nate Davis
Dec 8, 2010, 5:09:02 PM12/8/10
to ward-to...@googlegroups.com, Stephan Heilner
Ross,
In re-reading over your e-mail, I realized what you were saying about the SQL Databases on the local devices. True, for now, these Databases are all individual silos where data from the services is saved on the individual platforms. I will completely agree, that it would be wonderful to have a standard schema for the local SQLDB inside LDS Tools across all platforms. The services will always be the same, and if the Local DBs on the devices are the same, then it should be easier for the different teams on the different platforms to have some amount of unity.
Seeing that we use SQLite for the local data access, it would make sense to use your expertise in bringing the LDSql Schema you have made and see how it can be modified to be the base of the SQL DB on the devices. I would be interested in your thoughts and such on that...
Nate
On Dec 08, 2010, at 02:24 PM, Nate Davis <nate...@me.com> wrote:
> Hello Andy,
>
> My name is Nate Davis and I am a community developer for LDS Tools. I can't speak on behalf of everyone, but will give my personal thoughts on where LDS Tools can go in the future.
>
> The 5 or so of us that have been volunteering time with LDS Tools develop with our own personal Apple Developer accounts. We deploy to our iPads, iPhones, and such. We just checkout the code via SVN, and change the bundle identifier to match our accounts, and just never commit that .plist file Allowing us to modify and make changes and run with it and have everyone test and such. Some people use the simulator, but 4 of us for sure use devices to test. We all use our LDS Accounts to test.
>> > created, that was my first production type of app I wrote in Java I
Stephan Heilner
Dec 8, 2010, 5:57:07 PM12/8/10
to Ward Tools Development
We're open to creating a service that we host internally that loads
all the reports and info for a user into a SQLite database and then
the app just downloads the binary SQLite file, but the one problem
with that ideas is that not all mobile platforms support SQLite.
WebOS for example doesn't allow you to download a SQLite DB and use it
within an application. Windows Phone 7 doesn't support SQLite, etc.
It would work for iOS and Android, so maybe that's a viable option...
Stephan
On Dec 8, 3:09 pm, Nate Davis <nateda...@me.com> wrote:
> Ross,
>
> In re-reading over your e-mail, I realized what you were saying about the SQL Databases on the local devices. True, for now, these Databases are all individual silos where data from the services is saved on the individual platforms. I will completely agree, that it would be wonderful to have a standard schema for the local SQLDB inside LDS Tools across all platforms. The services will always be the same, and if the Local DBs on the devices are the same, then it should be easier for the different teams on the different platforms to have some amount of unity.
>
> Seeing that we use SQLite for the local data access, it would make sense to use your expertise in bringing the LDSql Schema you have made and see how it can be modified to be the base of the SQL DB on the devices. I would be interested in your thoughts and such on that...
>
> Nate
>
> nateda...@me.com
> ...
>
> read more »
all the reports and info for a user into a SQLite database and then
the app just downloads the binary SQLite file, but the one problem
with that ideas is that not all mobile platforms support SQLite.
WebOS for example doesn't allow you to download a SQLite DB and use it
within an application. Windows Phone 7 doesn't support SQLite, etc.
It would work for iOS and Android, so maybe that's a viable option...
Stephan
On Dec 8, 3:09 pm, Nate Davis <nateda...@me.com> wrote:
> Ross,
>
> In re-reading over your e-mail, I realized what you were saying about the SQL Databases on the local devices. True, for now, these Databases are all individual silos where data from the services is saved on the individual platforms. I will completely agree, that it would be wonderful to have a standard schema for the local SQLDB inside LDS Tools across all platforms. The services will always be the same, and if the Local DBs on the devices are the same, then it should be easier for the different teams on the different platforms to have some amount of unity.
>
> Seeing that we use SQLite for the local data access, it would make sense to use your expertise in bringing the LDSql Schema you have made and see how it can be modified to be the base of the SQL DB on the devices. I would be interested in your thoughts and such on that...
>
> Nate
>
>
> On Dec 08, 2010, at 02:24 PM, Nate Davis <nateda...@me.com> wrote:
>
> > Hello Andy,
>
> > My name is Nate Davis and I am a community developer for LDS Tools. I can't speak on behalf of everyone, but will give my personal thoughts on where LDS Tools can go in the future.
>
> > The 5 or so of us that have been volunteering time with LDS Tools develop with our own personal Apple Developer accounts. We deploy to our iPads, iPhones, and such. We just checkout the code via SVN, and change the bundle identifier to match our accounts, and just never commit that .plist file Allowing us to modify and make changes and run with it and have everyone test and such. Some people use the simulator, but 4 of us for sure use devices to test. We all use our LDS Accounts to test.
>
> > The Directory team at the church are the ones who expose Services for our volunteer team to use. They have been willing to discuss exposing more and more data as they can. They have not exposed Home Teaching and Visiting Data yet. I am thinking they have to work on how they will store the data and such. That has not been on the Send and Receive from MLS. Right now from what I know, Membership records, callings and financial data are the only things transferred and synced from MLS with The Servers at Church HQ. The Home Teaching and Visiting Teaching data is only stored locally. But backed up monthly at the church with the entire MLS data file.
>
> > I agree that a standard data access layer should be put into place. I think the directory team has this in place, and Stephan can get us more documentation as to what is available. All apps from the church must use these services, so the blackberry, iPhone, and android apps will have all the same data access. It will just be working hard to ensure all the apps have the same features....
>
> > I have loved working with LDS Tools. It has helped me to learn more about iOS and how services work.
>
> > As a Ward Clerk, Exec Sec, and now Stake Clerk, I have loved using Ward Tools to get access on my mobile, but as the church changes exports from MLS, I love having the data synced over the air. It will be nice with access levels determined by callings, and allow the church to manage the privacy that needs to be there. That was one thing I didn't love about the MLS export, it included all the sensitive info for everyone to export (with admin rights). It was really a love hate relationship :)
>
> > I think we can implement reports, and some stronger classes that might be more portable. That is where I feel the community developers of Ward Tools can really give us some wonderful input and contribute to an amazing resource for all us members.
>
> > Those are my thoughts,
> > Nate
>
> > Sent from my iPhone
>
> On Dec 08, 2010, at 02:24 PM, Nate Davis <nateda...@me.com> wrote:
>
> > Hello Andy,
>
> > My name is Nate Davis and I am a community developer for LDS Tools. I can't speak on behalf of everyone, but will give my personal thoughts on where LDS Tools can go in the future.
>
> > The 5 or so of us that have been volunteering time with LDS Tools develop with our own personal Apple Developer accounts. We deploy to our iPads, iPhones, and such. We just checkout the code via SVN, and change the bundle identifier to match our accounts, and just never commit that .plist file Allowing us to modify and make changes and run with it and have everyone test and such. Some people use the simulator, but 4 of us for sure use devices to test. We all use our LDS Accounts to test.
>
> > The Directory team at the church are the ones who expose Services for our volunteer team to use. They have been willing to discuss exposing more and more data as they can. They have not exposed Home Teaching and Visiting Data yet. I am thinking they have to work on how they will store the data and such. That has not been on the Send and Receive from MLS. Right now from what I know, Membership records, callings and financial data are the only things transferred and synced from MLS with The Servers at Church HQ. The Home Teaching and Visiting Teaching data is only stored locally. But backed up monthly at the church with the entire MLS data file.
>
> > I agree that a standard data access layer should be put into place. I think the directory team has this in place, and Stephan can get us more documentation as to what is available. All apps from the church must use these services, so the blackberry, iPhone, and android apps will have all the same data access. It will just be working hard to ensure all the apps have the same features....
>
> > I have loved working with LDS Tools. It has helped me to learn more about iOS and how services work.
>
> > As a Ward Clerk, Exec Sec, and now Stake Clerk, I have loved using Ward Tools to get access on my mobile, but as the church changes exports from MLS, I love having the data synced over the air. It will be nice with access levels determined by callings, and allow the church to manage the privacy that needs to be there. That was one thing I didn't love about the MLS export, it included all the sensitive info for everyone to export (with admin rights). It was really a love hate relationship :)
>
> > I think we can implement reports, and some stronger classes that might be more portable. That is where I feel the community developers of Ward Tools can really give us some wonderful input and contribute to an amazing resource for all us members.
>
> > Those are my thoughts,
> > Nate
>
> > Sent from my iPhone
>
> > On Dec 8, 2010, at 1:30 PM, Andy Wilbourn <awilbo...@gmail.com> wrote:
>
> >> I would also include the Ross have a great deal of knowledge of MLS and is a clerk, unless he recently was released. So he has been a very valuable member to the development team, although he is more focused on the database backend rather than the application programming (Java, Objective-C, or C).
>
> >> The first version Calvin created has reuse of the code for pulling data from the database. I have also played around with the iPhone version and have access to the Apple developer site, which I am not sure how that will be done going forward as you have to create accounts for the users to allow them to debug on a device. How is that done for LDS Tools? Perhaps you are the only one to code and it has not been a problem, or you other developers have to use the simulator only.
>
>
> >> I would also include the Ross have a great deal of knowledge of MLS and is a clerk, unless he recently was released. So he has been a very valuable member to the development team, although he is more focused on the database backend rather than the application programming (Java, Objective-C, or C).
>
> >> The first version Calvin created has reuse of the code for pulling data from the database. I have also played around with the iPhone version and have access to the Apple developer site, which I am not sure how that will be done going forward as you have to create accounts for the users to allow them to debug on a device. How is that done for LDS Tools? Perhaps you are the only one to code and it has not been a problem, or you other developers have to use the simulator only.
>
>
> read more »
boomerbubba
Dec 8, 2010, 6:09:41 PM12/8/10
to Ward Tools Development
Stephan,
Creating the SQLite binary would just be icing on the cake for those
particular platforms, as I see it!
My less-ambitious assumption has been that while there could be a
common SQLite schema for runtime retrieval on the handhelds, the
transformations from json to SQLite would take place within Java, C or
whatever on the target devices.
More important, I think, is the principle of trying to use a common
SQLite schema at all for retrieval. Most of the retrieval business
logic, including some pretty complex reporting, can be done as SQLite
views that are portable. That complexity far exceeds that of the
simpler LDS Tools apps being released to rank-and-file users today.
There are two downsides that I see:
1) Not all target platforms support SQLite. Those that do are iPhone,
Android, webOs, Blackberry 5.0 and up, and Windows Phone Classic (aka
WIndows Mobile 6.5). Those that don't are Blackberry pre-5.0 and
Windows Phone 7. I suggest that those two comprise the minority
outliers, and there is probably no choice but to build them in
platform-specific silos. (But the majority could be built with most
business logic done right once inside SQLite.)
2) The development of LDS Tools to date has not had any such unifying
architecture, so the transistion could be painful.
--Ross
> ...
>
> read more »- Hide quoted text -
Creating the SQLite binary would just be icing on the cake for those
particular platforms, as I see it!
My less-ambitious assumption has been that while there could be a
common SQLite schema for runtime retrieval on the handhelds, the
transformations from json to SQLite would take place within Java, C or
whatever on the target devices.
More important, I think, is the principle of trying to use a common
SQLite schema at all for retrieval. Most of the retrieval business
logic, including some pretty complex reporting, can be done as SQLite
views that are portable. That complexity far exceeds that of the
simpler LDS Tools apps being released to rank-and-file users today.
There are two downsides that I see:
1) Not all target platforms support SQLite. Those that do are iPhone,
Android, webOs, Blackberry 5.0 and up, and Windows Phone Classic (aka
WIndows Mobile 6.5). Those that don't are Blackberry pre-5.0 and
Windows Phone 7. I suggest that those two comprise the minority
outliers, and there is probably no choice but to build them in
platform-specific silos. (But the majority could be built with most
business logic done right once inside SQLite.)
2) The development of LDS Tools to date has not had any such unifying
architecture, so the transistion could be painful.
--Ross
>
> read more »- Hide quoted text -
Nate Davis
Dec 8, 2010, 6:44:58 PM12/8/10
to ward-to...@googlegroups.com
I was thinking along these lines. Where we would just have a documented
schema that all the platforms would use. I don't feel we should put a
binary out there like that. The flexibility of doing it in the
application logic will be good.
I understand that not all platforms support SQLite, but I think we plan on dropping support with Blackberry 4.x devices and older devices. If we have a documented schema, and we have a platform that doesn't support SQLite, then that schema can be rebuilt into something that is supported. At least they would have some small guide to go with.
The transition to a unified schema might be painful, but worth it in the end. We should contact the other teams and discuss this as it would effect everyone. But, my vote would be we determine a master schema that should be documented and published, and have each project adhere to it.
My thoughts,
Nate
I understand that not all platforms support SQLite, but I think we plan on dropping support with Blackberry 4.x devices and older devices. If we have a documented schema, and we have a platform that doesn't support SQLite, then that schema can be rebuilt into something that is supported. At least they would have some small guide to go with.
The transition to a unified schema might be painful, but worth it in the end. We should contact the other teams and discuss this as it would effect everyone. But, my vote would be we determine a master schema that should be documented and published, and have each project adhere to it.
My thoughts,
Nate
> > > The Directory team at the church are the ones who expose Services for our volunteer team to use. They have been willing to discuss exposing more and more data as they can. They have not exposed Home Teaching and Visiting Data yet. I am thinking they have to work on how they will store the data and such. That has not been on the Send and Receive from MLS. Right now from what I know, Membership records, callings and financial data are the only things transferred and synced from MLS with The Servers at Church HQ. The Home Teaching and Visiting Teaching data is only stored locally But backed up monthly at the church with the entire MLS data file.
boomerbubba
Dec 8, 2010, 8:05:36 PM12/8/10
to Ward Tools Development
The design decision about where to build the SQLite binary is not
mutually exclusive. It can be done both ways. For example, the
Android version of Ward Tools now supports two alternate methods of
loading from the raw MLS export CSVs into a SQLite binary: Copy them
raw onto the phone, or run a PC-based converter. (In both cases, the
guts of the transformation to the final schema happens identicically
within SQLite from staging tables because that's how LDSql works. But
the json-to-SQLite transform could also be done in Java or whatever.)
So either or both methods could be supported at load-time, optimized
by platform. The important unifying principle is the final SQLite
schema, including the runtime views. If that is enforced as common,
it really doesn't matter where the transformation occurs.
This is, at its core, a data-driven app. My bias is that of a DBA/
database app developer, so I tend to think in back-end terms. But it
seems a no-brainer for that business logic to be mostly controlled
within a common back end. There would be a common transformation of
the interim json output into the persistent data stores of the runtime
apps. It also is easier that way for Salt Lake professionals and
their management to approve the logic consistently. (For example,
exactly which sets of members appear in the queries in the Bishop's
Action and Interview List. In LDSql today, those are all queries that
execute identically across platforms.)
--Ross
On Dec 8, 5:44 pm, Nate Davis <nateda...@me.com> wrote:
> I was thinking along these lines. Where we would just have a documented schema that all the platforms would use. I don't feel we should put a binary out there like that. The flexibility of doing it in the application logic will be good.
>
> I understand that not all platforms support SQLite, but I think we plan on dropping support with Blackberry 4.x devices and older devices. If we have a documented schema, and we have a platform that doesn't support SQLite, then that schema can be rebuilt into something that is supported. At least they would have some small guide to go with.
>
> The transition to a unified schema might be painful, but worth it in the end. We should contact the other teams and discuss this as it would effect everyone. But, my vote would be we determine a master schema that should be documented and published, and have each project adhere to it.
>
> My thoughts,
> Nate
>
> > > > > My name is Nate Davis and I am a community developer for LDS Tools I can't speak on behalf of everyone, but will give my personal thoughts on where LDS Tools can go in the future.
>
> > > > > I agree that a standard data access layer should be put into place I think the directory team has this in place, and Stephan can get us more documentation as to what is available. All apps from the church must use these services, so the blackberry, iPhone, and android apps will have all the same data access. It will just be working hard to ensure all the apps have the same features....
> > > > >> Tools app obviously makes no attempt at a common architecture Each
>
> read more »
mutually exclusive. It can be done both ways. For example, the
Android version of Ward Tools now supports two alternate methods of
loading from the raw MLS export CSVs into a SQLite binary: Copy them
raw onto the phone, or run a PC-based converter. (In both cases, the
guts of the transformation to the final schema happens identicically
within SQLite from staging tables because that's how LDSql works. But
the json-to-SQLite transform could also be done in Java or whatever.)
So either or both methods could be supported at load-time, optimized
by platform. The important unifying principle is the final SQLite
schema, including the runtime views. If that is enforced as common,
it really doesn't matter where the transformation occurs.
This is, at its core, a data-driven app. My bias is that of a DBA/
database app developer, so I tend to think in back-end terms. But it
seems a no-brainer for that business logic to be mostly controlled
within a common back end. There would be a common transformation of
the interim json output into the persistent data stores of the runtime
apps. It also is easier that way for Salt Lake professionals and
their management to approve the logic consistently. (For example,
exactly which sets of members appear in the queries in the Bishop's
Action and Interview List. In LDSql today, those are all queries that
execute identically across platforms.)
--Ross
On Dec 8, 5:44 pm, Nate Davis <nateda...@me.com> wrote:
> I was thinking along these lines. Where we would just have a documented schema that all the platforms would use. I don't feel we should put a binary out there like that. The flexibility of doing it in the application logic will be good.
>
> I understand that not all platforms support SQLite, but I think we plan on dropping support with Blackberry 4.x devices and older devices. If we have a documented schema, and we have a platform that doesn't support SQLite, then that schema can be rebuilt into something that is supported. At least they would have some small guide to go with.
>
> The transition to a unified schema might be painful, but worth it in the end. We should contact the other teams and discuss this as it would effect everyone. But, my vote would be we determine a master schema that should be documented and published, and have each project adhere to it.
>
> My thoughts,
> Nate
>
>
> > > > > The 5 or so of us that have been volunteering time with LDS Tools develop with our own personal Apple Developer accounts. We deploy to our iPads, iPhones, and such. We just checkout the code via SVN, and change the bundle identifier to match our accounts, and just never commit that .plist file Allowing us to modify and make changes and run with it and have everyone test and such. Some people use the simulator, but 4 of us for sure use devices to test. We all use our LDS Accounts to test.
>
> > > > > The Directory team at the church are the ones who expose Services for our volunteer team to use. They have been willing to discuss exposing more and more data as they can. They have not exposed Home Teaching and Visiting Data yet. I am thinking they have to work on how they will store the data and such. That has not been on the Send and Receive from MLS. Right now from what I know, Membership records, callings and financial data are the only things transferred and synced from MLS with The Servers at Church HQ. The Home Teaching and Visiting Teaching data is only stored locally. But backed up monthly at the church with the entire MLS data file.
> > > > > The 5 or so of us that have been volunteering time with LDS Tools develop with our own personal Apple Developer accounts. We deploy to our iPads, iPhones, and such. We just checkout the code via SVN, and change the bundle identifier to match our accounts, and just never commit that .plist file Allowing us to modify and make changes and run with it and have everyone test and such. Some people use the simulator, but 4 of us for sure use devices to test. We all use our LDS Accounts to test.
>
>
> > > > > I agree that a standard data access layer should be put into place I think the directory team has this in place, and Stephan can get us more documentation as to what is available. All apps from the church must use these services, so the blackberry, iPhone, and android apps will have all the same data access. It will just be working hard to ensure all the apps have the same features....
> > > > >> platform is developed in a silo with its own independent dev team and
> > > > >> architecture. My personal opinion favors maximizing use of a common
> > > > >> back end, but that does
>
> ...
> > > > >> architecture. My personal opinion favors maximizing use of a common
> > > > >> back end, but that does
>
>
> read more »
Andy Wilbourn
Dec 8, 2010, 9:58:48 PM12/8/10
to ward-to...@googlegroups.com
At the time I only had Blackberry 4.x platforms to test on, but now I have a 5.x to work with. What I did was to persist the classes for the data and if I detected the membership.csv in the folder on the SD card, then would refresh the data. It handled reading the CSV to convert to the structure I created. So membership, HT, VT, and organization are all separate.
I am considering getting a nook color from Barnes and Noble (like a kindle) which is android based. They just released the sdl this week. They will open their store q1 for apps. So it may be another version to consider. There are many android ipad look-a-like devices coming out of China.
Now in terms of Windows Phone 7, there has been a guy who did a proof of concept of sqlite on that platform. http://sviluppomobile.blogspot.com/2010/07/wp7-sqliteclient-preview.html is the lastest news. I have not been able to have enough free time to test it though. It has similar problem as the iPhone where you can't copy files from the pc directly, but would need some service it hits to pull down the data (thinking more of ht/vt csv files or whatever is the solution).
-Andy
boomerbubba
Dec 20, 2010, 12:12:05 PM12/20/10
to Ward Tools Development
Can the ICS developer's shed some light into how secure the API for
the expanded membership service will be, in light of discussion in
this thread at LDS Tech?
http://tech.lds.org/forum/showpost.php?p=53351&postcount=63
Based on what I had heard before, I have always assumed that the API
would be restricted to Community-based apps such as LDS Tools. But it
seems that there is no application-level authentication in the
current service, only user-level authentication. This means that any
app, including a third-party app, could download the membership data
via the API.
This is not so significant today, because the existing LDS Tools app
and the service behind it include only relatively tame data that any
rank-and-file member can view and download by other means -- basically
a unit directory and calendar. But the expanded app we are talking
about will include other data elements that are more confidential and
sensitive -- including the MRN that is being deleted from the MLS
exports on security/privacy grounds. Those security/privacy concerns
also obtain in an API that is not locked down.
So will there be some app-level authentication introduced to allow the
end users to view this data securely?
On Dec 8, 8:58 pm, Andy Wilbourn <awilbo...@gmail.com> wrote:
> At the time I only had Blackberry 4.x platforms to test on, but now I have
> a 5.x to work with. What I did was to persist the classes for the data and
> if I detected the membership.csv in the folder on the SD card, then would
> refresh the data. It handled reading the CSV to convert to the structure I
> created. So membership, HT, VT, and organization are all separate.
>
> I am considering getting a nook color from Barnes and Noble (like a kindle)
> which is android based. They just released the sdl this week. They will open
> their store q1 for apps. So it may be another version to consider. There are
> many android ipad look-a-like devices coming out of China.
>
> Now in terms of Windows Phone 7, there has been a guy who did a proof of
> concept of sqlite on that platform.http://sviluppomobile.blogspot.com/2010/07/wp7-sqliteclient-preview.htmlis
> the lastest news. I have not been able to have enough free time to test it
> though. It has similar problem as the iPhone where you can't copy files from
> the pc directly, but would need some service it hits to pull down the data
> (thinking more of ht/vt csv files or whatever is the solution).
>
> -Andy
>
> ...
>
> read more »
the expanded membership service will be, in light of discussion in
this thread at LDS Tech?
http://tech.lds.org/forum/showpost.php?p=53351&postcount=63
Based on what I had heard before, I have always assumed that the API
would be restricted to Community-based apps such as LDS Tools. But it
seems that there is no application-level authentication in the
current service, only user-level authentication. This means that any
app, including a third-party app, could download the membership data
via the API.
This is not so significant today, because the existing LDS Tools app
and the service behind it include only relatively tame data that any
rank-and-file member can view and download by other means -- basically
a unit directory and calendar. But the expanded app we are talking
about will include other data elements that are more confidential and
sensitive -- including the MRN that is being deleted from the MLS
exports on security/privacy grounds. Those security/privacy concerns
also obtain in an API that is not locked down.
So will there be some app-level authentication introduced to allow the
end users to view this data securely?
On Dec 8, 8:58 pm, Andy Wilbourn <awilbo...@gmail.com> wrote:
> At the time I only had Blackberry 4.x platforms to test on, but now I have
> a 5.x to work with. What I did was to persist the classes for the data and
> if I detected the membership.csv in the folder on the SD card, then would
> refresh the data. It handled reading the CSV to convert to the structure I
> created. So membership, HT, VT, and organization are all separate.
>
> I am considering getting a nook color from Barnes and Noble (like a kindle)
> which is android based. They just released the sdl this week. They will open
> their store q1 for apps. So it may be another version to consider. There are
> many android ipad look-a-like devices coming out of China.
>
> Now in terms of Windows Phone 7, there has been a guy who did a proof of
> concept of sqlite on that platform.http://sviluppomobile.blogspot.com/2010/07/wp7-sqliteclient-preview.htmlis
> the lastest news. I have not been able to have enough free time to test it
> though. It has similar problem as the iPhone where you can't copy files from
> the pc directly, but would need some service it hits to pull down the data
> (thinking more of ht/vt csv files or whatever is the solution).
>
> -Andy
>
> On Wed, Dec 8, 2010 at 6:44 PM, Nate Davis <nateda...@me.com> wrote:
> > I was thinking along these lines. Where we would just have a documented
> > schema that all the platforms would use. I don't feel we should put a binary
> > out there like that. The flexibility of doing it in the application logic
> > will be good.
>
> > I understand that not all platforms support SQLite, but I think we plan on
> > dropping support with Blackberry 4.x devices and older devices. If we have a
> > documented schema, and we have a platform that doesn't support SQLite, then
> > that schema can be rebuilt into something that is supported. At least they
> > would have some small guide to go with.
>
> > The transition to a unified schema might be painful, but worth it in the
> > end. We should contact the other teams and discuss this as it would effect
> > everyone. But, my vote would be we determine a master schema that should be
> > documented and published, and have each project adhere to it.
>
> > My thoughts,
> > Nate
>
> > I was thinking along these lines. Where we would just have a documented
> > schema that all the platforms would use. I don't feel we should put a binary
> > out there like that. The flexibility of doing it in the application logic
> > will be good.
>
> > I understand that not all platforms support SQLite, but I think we plan on
> > dropping support with Blackberry 4.x devices and older devices. If we have a
> > documented schema, and we have a platform that doesn't support SQLite, then
> > that schema can be rebuilt into something that is supported. At least they
> > would have some small guide to go with.
>
> > The transition to a unified schema might be painful, but worth it in the
> > end. We should contact the other teams and discuss this as it would effect
> > everyone. But, my vote would be we determine a master schema that should be
> > documented and published, and have each project adhere to it.
>
> > My thoughts,
> > Nate
>
>
> read more »
Reply all
Reply to author
Forward
0 new messages