For our data collection project, we'll be working with community
health workers (CHWs) in Ethiopia and I'm looking for some help/advice
on the best way to cope with using/storing alternate date formats.
Ethiopia has it's own calendar system - using 13 months and new year
starts on either Sept 11th or 12th (depending on whether it's a leap
year or not, much more on wikipedia about the Ethiopian
calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) - and
this system is the normal calendaring system in Ethiopia. Some of the
CHWs we're working with have difficulty using the Gregorian calendar
as it's not what they are used to. As we'll be collecting information
regarding appointment dates, dates of birth etc, it's important that
we can use a date system that is familiar and understandable to the
CHWs.
On the ODK Collect end, the CHWs will be entering dates in the
Ethiopian calendar - which can include dates (dd/mm/yyyy format) such
as 30/2/2003, or 3/13/2002, which would be invalid dates in the
Gregorian calendar, so we can't just use the normal database date
field with an offset.
On the other end of the system, we'll be generating reports based on
the input data, for example to give a list of who is due for a follow
up appointment in the next 7 days, so we'll need to do processing of
the dates stored in the ODK Aggregate database.
To save possible confusion over date formats I was hoping that in the
database we could store dates either as a unix timestamp or julian
days - as then it's straightforward to manipulate (eg, add 7 days),
compare and convert these dates/times into other formats for display
(eg Gregorian or Ethiopian - however we like).
I've thought about 3 possible ways we could deal with this and I'd be
really interested to hear anyone else's thoughts on which may be good/
bad or if there are other options available to us:
Adapt ODK Collect so the date is converted to unix timestamp before
it is sent from the phone
Adapt ODK Aggregate to the date is converted when the form arrives
at the server, but before the info is saved into the database
Store the Ethiopian date in the ODK Aggregate database as-is (text
string or 3 separate integer fields) then regularly output this to
another table doing the date conversion at this point and using this
new table to generate the reports (there's no problem with a short
delay before the data is available for the reports - few hours, or
even day would be fine).
At the moment my preference is for option (3) - I'd like to keep the
programming/development to a minimum and would like to avoid making
customisations to ODKAggreate or ODKCollect which may make it
difficult for us to upgrade. I'm also not sure how easy/hard it would
be to implement (1) or (2).
You mentioned you'd prefer option 3: "Store the Ethiopian date in the ODK
Aggregate database as-is (text string or 3 separate integer fields) then
regularly output this to another table doing the date conversion at this
point".
Ethiopian Date: Tuesday, 2 30, 2003
Gregorian Date: Monday, November 8, 2010
Regards,
Mike
···
On Wed, Aug 17, 2011 at 10:11 AM, Alex Little wrote:
Hi all,
For our data collection project, we'll be working with community
health workers (CHWs) in Ethiopia and I'm looking for some help/advice
on the best way to cope with using/storing alternate date formats.
Ethiopia has it's own calendar system - using 13 months and new year
starts on either Sept 11th or 12th (depending on whether it's a leap
year or not, much more on wikipedia about the Ethiopian
calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) - and
this system is the normal calendaring system in Ethiopia. Some of the
CHWs we're working with have difficulty using the Gregorian calendar
as it's not what they are used to. As we'll be collecting information
regarding appointment dates, dates of birth etc, it's important that
we can use a date system that is familiar and understandable to the
CHWs.
On the ODK Collect end, the CHWs will be entering dates in the
Ethiopian calendar - which can include dates (dd/mm/yyyy format) such
as 30/2/2003, or 3/13/2002, which would be invalid dates in the
Gregorian calendar, so we can't just use the normal database date
field with an offset.
On the other end of the system, we'll be generating reports based on
the input data, for example to give a list of who is due for a follow
up appointment in the next 7 days, so we'll need to do processing of
the dates stored in the ODK Aggregate database.
To save possible confusion over date formats I was hoping that in the
database we could store dates either as a unix timestamp or julian
days - as then it's straightforward to manipulate (eg, add 7 days),
compare and convert these dates/times into other formats for display
(eg Gregorian or Ethiopian - however we like).
I've thought about 3 possible ways we could deal with this and I'd be
really interested to hear anyone else's thoughts on which may be good/
bad or if there are other options available to us:
Adapt ODK Collect so the date is converted to unix timestamp before
it is sent from the phone
Adapt ODK Aggregate to the date is converted when the form arrives
at the server, but before the info is saved into the database
Store the Ethiopian date in the ODK Aggregate database as-is (text
string or 3 separate integer fields) then regularly output this to
another table doing the date conversion at this point and using this
new table to generate the reports (there's no problem with a short
delay before the data is available for the reports - few hours, or
even day would be fine).
At the moment my preference is for option (3) - I'd like to keep the
programming/development to a minimum and would like to avoid making
customisations to ODKAggreate or ODKCollect which may make it
difficult for us to upgrade. I'm also not sure how easy/hard it would
be to implement (1) or (2).
assuming you have ethiopian date/datetime widgets already created, i'd
recommend you make these modifications in collect 1.1.7. collect the
ethiopian date, convert to utc, and submit that. you'd only have to
change three very small files.
collect 1.1.7 has the jodatime library already included. right now we
write out the local gregorian time with timezone. you can, as michael
has described, easily convert ethiopian dates to utc before you send
it.
···
On Wed, Aug 17, 2011 at 07:53, Michael Willekes wrote:
> Alex,
>
> You mentioned you'd prefer option 3: "Store the Ethiopian date in the ODK
> Aggregate database as-is (text string or 3 separate integer fields) then
> regularly output this to another table doing the date conversion at this
> point".
>
> Straightforward to do as a post-processing step using the Java library Joda
> Time:
>
> // Create Ethiopian Chronology
> Chronology chron_eth =
> EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
>
> // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
> DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0, chron_eth);
>
> // Convert to Gregorian Date/Time
> DateTime dt_greg = dt_eth.withChronology(GregorianChronology.getInstance());
>
> System.out.println("Ethiopian Date: " +
> DateTimeFormat.fullDate().print(dt_eth));
> System.out.println("Gregorian Date: " +
> DateTimeFormat.fullDate().print(dt_greg));
>
> This outputs:
>
> Ethiopian Date: Tuesday, 2 30, 2003
> Gregorian Date: Monday, November 8, 2010
>
> Regards,
> Mike
>
>
> On Wed, Aug 17, 2011 at 10:11 AM, Alex Little wrote:
>>
>> Hi all,
>>
>> For our data collection project, we'll be working with community
>> health workers (CHWs) in Ethiopia and I'm looking for some help/advice
>> on the best way to cope with using/storing alternate date formats.
>>
>> Ethiopia has it's own calendar system - using 13 months and new year
>> starts on either Sept 11th or 12th (depending on whether it's a leap
>> year or not, much more on wikipedia about the Ethiopian
>> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) - and
>> this system is the normal calendaring system in Ethiopia. Some of the
>> CHWs we're working with have difficulty using the Gregorian calendar
>> as it's not what they are used to. As we'll be collecting information
>> regarding appointment dates, dates of birth etc, it's important that
>> we can use a date system that is familiar and understandable to the
>> CHWs.
>>
>> On the ODK Collect end, the CHWs will be entering dates in the
>> Ethiopian calendar - which can include dates (dd/mm/yyyy format) such
>> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
>> Gregorian calendar, so we can't just use the normal database date
>> field with an offset.
>>
>> On the other end of the system, we'll be generating reports based on
>> the input data, for example to give a list of who is due for a follow
>> up appointment in the next 7 days, so we'll need to do processing of
>> the dates stored in the ODK Aggregate database.
>>
>> To save possible confusion over date formats I was hoping that in the
>> database we could store dates either as a unix timestamp or julian
>> days - as then it's straightforward to manipulate (eg, add 7 days),
>> compare and convert these dates/times into other formats for display
>> (eg Gregorian or Ethiopian - however we like).
>>
>> I've thought about 3 possible ways we could deal with this and I'd be
>> really interested to hear anyone else's thoughts on which may be good/
>> bad or if there are other options available to us:
>>
>> 1) Adapt ODK Collect so the date is converted to unix timestamp before
>> it is sent from the phone
>> 2) Adapt ODK Aggregate to the date is converted when the form arrives
>> at the server, but before the info is saved into the database
>> 3) Store the Ethiopian date in the ODK Aggregate database as-is (text
>> string or 3 separate integer fields) then regularly output this to
>> another table doing the date conversion at this point and using this
>> new table to generate the reports (there's no problem with a short
>> delay before the data is available for the reports - few hours, or
>> even day would be fine).
>>
>> At the moment my preference is for option (3) - I'd like to keep the
>> programming/development to a minimum and would like to avoid making
>> customisations to ODKAggreate or ODKCollect which may make it
>> difficult for us to upgrade. I'm also not sure how easy/hard it would
>> be to implement (1) or (2).
>>
>> Any help/advice/comments much appreciated :-)
>>
>> Cheers,
>> Alex
>>
>> --
>> Post: opendatakit@googlegroups.com
>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
Thanks Michael & Yaw. I didn't know about the jodaTime library and I
was expecting the conversion of the date on the ODKCollect client to
be a little harder than it seems it may be.
Will have a look as how I can create a widget and build the ODKCollect
client with the widget enabled.
Cheers,
Alex
···
On Aug 17, 4:05 pm, Yaw Anokwa wrote:
> assuming you have ethiopian date/datetime widgets already created, i'd
> recommend you make these modifications in collect 1.1.7. collect the
> ethiopian date, convert to utc, and submit that. you'd only have to
> change three very small files.
>
> collect 1.1.7 has the jodatime library already included. right now we
> write out the local gregorian time with timezone. you can, as michael
> has described, easily convert ethiopian dates to utc before you send
> it.
>
>
>
> On Wed, Aug 17, 2011 at 07:53, Michael Willekes wrote:
> > Alex,
>
> > You mentioned you'd prefer option 3: "Store the Ethiopian date in the ODK
> > Aggregate database as-is (text string or 3 separate integer fields) then
> > regularly output this to another table doing the date conversion at this
> > point".
>
> > Straightforward to do as a post-processing step using the Java library Joda
> > Time:
>
> > // Create Ethiopian Chronology
> > Chronology chron_eth =
> > EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
>
> > // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
> > DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0, chron_eth);
>
> > // Convert to Gregorian Date/Time
> > DateTime dt_greg = dt_eth.withChronology(GregorianChronology.getInstance());
>
> > System.out.println("Ethiopian Date: " +
> > DateTimeFormat.fullDate().print(dt_eth));
> > System.out.println("Gregorian Date: " +
> > DateTimeFormat.fullDate().print(dt_greg));
>
> > This outputs:
>
> > Ethiopian Date: Tuesday, 2 30, 2003
> > Gregorian Date: Monday, November 8, 2010
>
> > Regards,
> > Mike
>
> > On Wed, Aug 17, 2011 at 10:11 AM, Alex Little wrote:
>
> >> Hi all,
>
> >> For our data collection project, we'll be working with community
> >> health workers (CHWs) in Ethiopia and I'm looking for some help/advice
> >> on the best way to cope with using/storing alternate date formats.
>
> >> Ethiopia has it's own calendar system - using 13 months and new year
> >> starts on either Sept 11th or 12th (depending on whether it's a leap
> >> year or not, much more on wikipedia about the Ethiopian
> >> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) - and
> >> this system is the normal calendaring system in Ethiopia. Some of the
> >> CHWs we're working with have difficulty using the Gregorian calendar
> >> as it's not what they are used to. As we'll be collecting information
> >> regarding appointment dates, dates of birth etc, it's important that
> >> we can use a date system that is familiar and understandable to the
> >> CHWs.
>
> >> On the ODK Collect end, the CHWs will be entering dates in the
> >> Ethiopian calendar - which can include dates (dd/mm/yyyy format) such
> >> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
> >> Gregorian calendar, so we can't just use the normal database date
> >> field with an offset.
>
> >> On the other end of the system, we'll be generating reports based on
> >> the input data, for example to give a list of who is due for a follow
> >> up appointment in the next 7 days, so we'll need to do processing of
> >> the dates stored in the ODK Aggregate database.
>
> >> To save possible confusion over date formats I was hoping that in the
> >> database we could store dates either as a unix timestamp or julian
> >> days - as then it's straightforward to manipulate (eg, add 7 days),
> >> compare and convert these dates/times into other formats for display
> >> (eg Gregorian or Ethiopian - however we like).
>
> >> I've thought about 3 possible ways we could deal with this and I'd be
> >> really interested to hear anyone else's thoughts on which may be good/
> >> bad or if there are other options available to us:
>
> >> 1) Adapt ODK Collect so the date is converted to unix timestamp before
> >> it is sent from the phone
> >> 2) Adapt ODK Aggregate to the date is converted when the form arrives
> >> at the server, but before the info is saved into the database
> >> 3) Store the Ethiopian date in the ODK Aggregate database as-is (text
> >> string or 3 separate integer fields) then regularly output this to
> >> another table doing the date conversion at this point and using this
> >> new table to generate the reports (there's no problem with a short
> >> delay before the data is available for the reports - few hours, or
> >> even day would be fine).
>
> >> At the moment my preference is for option (3) - I'd like to keep the
> >> programming/development to a minimum and would like to avoid making
> >> customisations to ODKAggreate or ODKCollect which may make it
> >> difficult for us to upgrade. I'm also not sure how easy/hard it would
> >> be to implement (1) or (2).
>
> >> Any help/advice/comments much appreciated :-)
>
> >> Cheers,
> >> Alex
>
> >> --
> >> Post: opendatakit@googlegroups.com
> >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> >> Options:http://groups.google.com/group/opendatakit?hl=en
>
> > --
> > Post: opendatakit@googlegroups.com
> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > Options:http://groups.google.com/group/opendatakit?hl=en
Just been having a look at this (creating the widget), what I don't
quite get is (after I've created my new EthiopicDateWidget class):
what else I need to change in the ODKCollect code to get this
recognised as a valid form widget - is it just to add to the
WidgetFactory class - and to the JavaRosa constants too? Yaw, you
mentioned there where 3 files that need changing, assuming the two
I've mentioned are correct - which is the other?
what I would need to enter as the type attribute in the form xml to
get my ODKCollect to display the right widget.
Any help much appreciated.
Cheers,
Alex
···
On Aug 17, 5:16 pm, Alex Little wrote:
> Thanks Michael & Yaw. I didn't know about the jodaTime library and I
> was expecting the conversion of the date on the ODKCollect client to
> be a little harder than it seems it may be.
>
> Will have a look as how I can create a widget and build the ODKCollect
> client with the widget enabled.
>
> Cheers,
> Alex
>
> On Aug 17, 4:05 pm, Yaw Anokwa wrote:
>
>
>
> > assuming you have ethiopian date/datetime widgets already created, i'd
> > recommend you make these modifications in collect 1.1.7. collect the
> > ethiopian date, convert to utc, and submit that. you'd only have to
> > change three very small files.
>
> > collect 1.1.7 has the jodatime library already included. right now we
> > write out the local gregorian time with timezone. you can, as michael
> > has described, easily convert ethiopian dates to utc before you send
> > it.
>
> > On Wed, Aug 17, 2011 at 07:53, Michael Willekes wrote:
> > > Alex,
>
> > > You mentioned you'd prefer option 3: "Store the Ethiopian date in the ODK
> > > Aggregate database as-is (text string or 3 separate integer fields) then
> > > regularly output this to another table doing the date conversion at this
> > > point".
>
> > > Straightforward to do as a post-processing step using the Java library Joda
> > > Time:
>
> > > // Create Ethiopian Chronology
> > > Chronology chron_eth =
> > > EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
>
> > > // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
> > > DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0, chron_eth);
>
> > > // Convert to Gregorian Date/Time
> > > DateTime dt_greg = dt_eth.withChronology(GregorianChronology.getInstance());
>
> > > System.out.println("Ethiopian Date: " +
> > > DateTimeFormat.fullDate().print(dt_eth));
> > > System.out.println("Gregorian Date: " +
> > > DateTimeFormat.fullDate().print(dt_greg));
>
> > > This outputs:
>
> > > Ethiopian Date: Tuesday, 2 30, 2003
> > > Gregorian Date: Monday, November 8, 2010
>
> > > Regards,
> > > Mike
>
> > > On Wed, Aug 17, 2011 at 10:11 AM, Alex Little wrote:
>
> > >> Hi all,
>
> > >> For our data collection project, we'll be working with community
> > >> health workers (CHWs) in Ethiopia and I'm looking for some help/advice
> > >> on the best way to cope with using/storing alternate date formats.
>
> > >> Ethiopia has it's own calendar system - using 13 months and new year
> > >> starts on either Sept 11th or 12th (depending on whether it's a leap
> > >> year or not, much more on wikipedia about the Ethiopian
> > >> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) - and
> > >> this system is the normal calendaring system in Ethiopia. Some of the
> > >> CHWs we're working with have difficulty using the Gregorian calendar
> > >> as it's not what they are used to. As we'll be collecting information
> > >> regarding appointment dates, dates of birth etc, it's important that
> > >> we can use a date system that is familiar and understandable to the
> > >> CHWs.
>
> > >> On the ODK Collect end, the CHWs will be entering dates in the
> > >> Ethiopian calendar - which can include dates (dd/mm/yyyy format) such
> > >> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
> > >> Gregorian calendar, so we can't just use the normal database date
> > >> field with an offset.
>
> > >> On the other end of the system, we'll be generating reports based on
> > >> the input data, for example to give a list of who is due for a follow
> > >> up appointment in the next 7 days, so we'll need to do processing of
> > >> the dates stored in the ODK Aggregate database.
>
> > >> To save possible confusion over date formats I was hoping that in the
> > >> database we could store dates either as a unix timestamp or julian
> > >> days - as then it's straightforward to manipulate (eg, add 7 days),
> > >> compare and convert these dates/times into other formats for display
> > >> (eg Gregorian or Ethiopian - however we like).
>
> > >> I've thought about 3 possible ways we could deal with this and I'd be
> > >> really interested to hear anyone else's thoughts on which may be good/
> > >> bad or if there are other options available to us:
>
> > >> 1) Adapt ODK Collect so the date is converted to unix timestamp before
> > >> it is sent from the phone
> > >> 2) Adapt ODK Aggregate to the date is converted when the form arrives
> > >> at the server, but before the info is saved into the database
> > >> 3) Store the Ethiopian date in the ODK Aggregate database as-is (text
> > >> string or 3 separate integer fields) then regularly output this to
> > >> another table doing the date conversion at this point and using this
> > >> new table to generate the reports (there's no problem with a short
> > >> delay before the data is available for the reports - few hours, or
> > >> even day would be fine).
>
> > >> At the moment my preference is for option (3) - I'd like to keep the
> > >> programming/development to a minimum and would like to avoid making
> > >> customisations to ODKAggreate or ODKCollect which may make it
> > >> difficult for us to upgrade. I'm also not sure how easy/hard it would
> > >> be to implement (1) or (2).
>
> > >> Any help/advice/comments much appreciated :-)
>
> > >> Cheers,
> > >> Alex
>
> > >> --
> > >> Post: opendatakit@googlegroups.com
> > >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > >> Options:http://groups.google.com/group/opendatakit?hl=en
>
> > > --
> > > Post: opendatakit@googlegroups.com
> > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > > Options:http://groups.google.com/group/opendatakit?hl=en
since you'll have to roll your own collect anyway, i'd just substitute
your widget for the standard date widget and leave the form as is. if
you are using 1.1.7, you'll have to change date and datetime (assuming
you want date time) widgets. you'll also have to change the widget
factory to call your widget instead of the default widget.
···
On Wed, Aug 17, 2011 at 11:34, Alex Little wrote:
> Just been having a look at this (creating the widget), what I don't
> quite get is (after I've created my new EthiopicDateWidget class):
>
> 1) what else I need to change in the ODKCollect code to get this
> recognised as a valid form widget - is it just to add to the
> WidgetFactory class - and to the JavaRosa constants too? Yaw, you
> mentioned there where 3 files that need changing, assuming the two
> I've mentioned are correct - which is the other?
> 2) what I would need to enter as the type attribute in the form xml to
> get my ODKCollect to display the right widget.
>
> Any help much appreciated.
> Cheers,
> Alex
>
> On Aug 17, 5:16 pm, Alex Little wrote:
>> Thanks Michael & Yaw. I didn't know about the jodaTime library and I
>> was expecting the conversion of the date on the ODKCollect client to
>> be a little harder than it seems it may be.
>>
>> Will have a look as how I can create a widget and build the ODKCollect
>> client with the widget enabled.
>>
>> Cheers,
>> Alex
>>
>> On Aug 17, 4:05 pm, Yaw Anokwa wrote:
>>
>>
>>
>> > assuming you have ethiopian date/datetime widgets already created, i'd
>> > recommend you make these modifications in collect 1.1.7. collect the
>> > ethiopian date, convert to utc, and submit that. you'd only have to
>> > change three very small files.
>>
>> > collect 1.1.7 has the jodatime library already included. right now we
>> > write out the local gregorian time with timezone. you can, as michael
>> > has described, easily convert ethiopian dates to utc before you send
>> > it.
>>
>> > On Wed, Aug 17, 2011 at 07:53, Michael Willekes wrote:
>> > > Alex,
>>
>> > > You mentioned you'd prefer option 3: "Store the Ethiopian date in the ODK
>> > > Aggregate database as-is (text string or 3 separate integer fields) then
>> > > regularly output this to another table doing the date conversion at this
>> > > point".
>>
>> > > Straightforward to do as a post-processing step using the Java library Joda
>> > > Time:
>>
>> > > // Create Ethiopian Chronology
>> > > Chronology chron_eth =
>> > > EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
>>
>> > > // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
>> > > DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0, chron_eth);
>>
>> > > // Convert to Gregorian Date/Time
>> > > DateTime dt_greg = dt_eth.withChronology(GregorianChronology.getInstance());
>>
>> > > System.out.println("Ethiopian Date: " +
>> > > DateTimeFormat.fullDate().print(dt_eth));
>> > > System.out.println("Gregorian Date: " +
>> > > DateTimeFormat.fullDate().print(dt_greg));
>>
>> > > This outputs:
>>
>> > > Ethiopian Date: Tuesday, 2 30, 2003
>> > > Gregorian Date: Monday, November 8, 2010
>>
>> > > Regards,
>> > > Mike
>>
>> > > On Wed, Aug 17, 2011 at 10:11 AM, Alex Little wrote:
>>
>> > >> Hi all,
>>
>> > >> For our data collection project, we'll be working with community
>> > >> health workers (CHWs) in Ethiopia and I'm looking for some help/advice
>> > >> on the best way to cope with using/storing alternate date formats.
>>
>> > >> Ethiopia has it's own calendar system - using 13 months and new year
>> > >> starts on either Sept 11th or 12th (depending on whether it's a leap
>> > >> year or not, much more on wikipedia about the Ethiopian
>> > >> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) - and
>> > >> this system is the normal calendaring system in Ethiopia. Some of the
>> > >> CHWs we're working with have difficulty using the Gregorian calendar
>> > >> as it's not what they are used to. As we'll be collecting information
>> > >> regarding appointment dates, dates of birth etc, it's important that
>> > >> we can use a date system that is familiar and understandable to the
>> > >> CHWs.
>>
>> > >> On the ODK Collect end, the CHWs will be entering dates in the
>> > >> Ethiopian calendar - which can include dates (dd/mm/yyyy format) such
>> > >> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
>> > >> Gregorian calendar, so we can't just use the normal database date
>> > >> field with an offset.
>>
>> > >> On the other end of the system, we'll be generating reports based on
>> > >> the input data, for example to give a list of who is due for a follow
>> > >> up appointment in the next 7 days, so we'll need to do processing of
>> > >> the dates stored in the ODK Aggregate database.
>>
>> > >> To save possible confusion over date formats I was hoping that in the
>> > >> database we could store dates either as a unix timestamp or julian
>> > >> days - as then it's straightforward to manipulate (eg, add 7 days),
>> > >> compare and convert these dates/times into other formats for display
>> > >> (eg Gregorian or Ethiopian - however we like).
>>
>> > >> I've thought about 3 possible ways we could deal with this and I'd be
>> > >> really interested to hear anyone else's thoughts on which may be good/
>> > >> bad or if there are other options available to us:
>>
>> > >> 1) Adapt ODK Collect so the date is converted to unix timestamp before
>> > >> it is sent from the phone
>> > >> 2) Adapt ODK Aggregate to the date is converted when the form arrives
>> > >> at the server, but before the info is saved into the database
>> > >> 3) Store the Ethiopian date in the ODK Aggregate database as-is (text
>> > >> string or 3 separate integer fields) then regularly output this to
>> > >> another table doing the date conversion at this point and using this
>> > >> new table to generate the reports (there's no problem with a short
>> > >> delay before the data is available for the reports - few hours, or
>> > >> even day would be fine).
>>
>> > >> At the moment my preference is for option (3) - I'd like to keep the
>> > >> programming/development to a minimum and would like to avoid making
>> > >> customisations to ODKAggreate or ODKCollect which may make it
>> > >> difficult for us to upgrade. I'm also not sure how easy/hard it would
>> > >> be to implement (1) or (2).
>>
>> > >> Any help/advice/comments much appreciated :-)
>>
>> > >> Cheers,
>> > >> Alex
>>
>> > >> --
>> > >> Post: opendatakit@googlegroups.com
>> > >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> > >> Options:http://groups.google.com/group/opendatakit?hl=en
>>
>> > > --
>> > > Post: opendatakit@googlegroups.com
>> > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> > > Options:http://groups.google.com/group/opendatakit?hl=en
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
I would prefer to keep the option of using the Gregorian date, so
would prefer to create a new widget rather than adapt the existing
date widget - even if it's a little more work.
Alex
···
On Aug 17, 7:46 pm, Yaw Anokwa wrote:
> since you'll have to roll your own collect anyway, i'd just substitute
> your widget for the standard date widget and leave the form as is. if
> you are using 1.1.7, you'll have to change date and datetime (assuming
> you want date time) widgets. you'll also have to change the widget
> factory to call your widget instead of the default widget.
>
>
>
> On Wed, Aug 17, 2011 at 11:34, Alex Little wrote:
> > Just been having a look at this (creating the widget), what I don't
> > quite get is (after I've created my new EthiopicDateWidget class):
>
> > 1) what else I need to change in the ODKCollect code to get this
> > recognised as a valid form widget - is it just to add to the
> > WidgetFactory class - and to the JavaRosa constants too? Yaw, you
> > mentioned there where 3 files that need changing, assuming the two
> > I've mentioned are correct - which is the other?
> > 2) what I would need to enter as the type attribute in the form xml to
> > get my ODKCollect to display the right widget.
>
> > Any help much appreciated.
> > Cheers,
> > Alex
>
> > On Aug 17, 5:16 pm, Alex Little wrote:
> >> Thanks Michael & Yaw. I didn't know about the jodaTime library and I
> >> was expecting the conversion of the date on the ODKCollect client to
> >> be a little harder than it seems it may be.
>
> >> Will have a look as how I can create a widget and build the ODKCollect
> >> client with the widget enabled.
>
> >> Cheers,
> >> Alex
>
> >> On Aug 17, 4:05 pm, Yaw Anokwa wrote:
>
> >> > assuming you have ethiopian date/datetime widgets already created, i'd
> >> > recommend you make these modifications in collect 1.1.7. collect the
> >> > ethiopian date, convert to utc, and submit that. you'd only have to
> >> > change three very small files.
>
> >> > collect 1.1.7 has the jodatime library already included. right now we
> >> > write out the local gregorian time with timezone. you can, as michael
> >> > has described, easily convert ethiopian dates to utc before you send
> >> > it.
>
> >> > On Wed, Aug 17, 2011 at 07:53, Michael Willekes wrote:
> >> > > Alex,
>
> >> > > You mentioned you'd prefer option 3: "Store the Ethiopian date in the ODK
> >> > > Aggregate database as-is (text string or 3 separate integer fields) then
> >> > > regularly output this to another table doing the date conversion at this
> >> > > point".
>
> >> > > Straightforward to do as a post-processing step using the Java library Joda
> >> > > Time:
>
> >> > > // Create Ethiopian Chronology
> >> > > Chronology chron_eth =
> >> > > EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
>
> >> > > // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
> >> > > DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0, chron_eth);
>
> >> > > // Convert to Gregorian Date/Time
> >> > > DateTime dt_greg = dt_eth.withChronology(GregorianChronology.getInstance());
>
> >> > > System.out.println("Ethiopian Date: " +
> >> > > DateTimeFormat.fullDate().print(dt_eth));
> >> > > System.out.println("Gregorian Date: " +
> >> > > DateTimeFormat.fullDate().print(dt_greg));
>
> >> > > This outputs:
>
> >> > > Ethiopian Date: Tuesday, 2 30, 2003
> >> > > Gregorian Date: Monday, November 8, 2010
>
> >> > > Regards,
> >> > > Mike
>
> >> > > On Wed, Aug 17, 2011 at 10:11 AM, Alex Little wrote:
>
> >> > >> Hi all,
>
> >> > >> For our data collection project, we'll be working with community
> >> > >> health workers (CHWs) in Ethiopia and I'm looking for some help/advice
> >> > >> on the best way to cope with using/storing alternate date formats.
>
> >> > >> Ethiopia has it's own calendar system - using 13 months and new year
> >> > >> starts on either Sept 11th or 12th (depending on whether it's a leap
> >> > >> year or not, much more on wikipedia about the Ethiopian
> >> > >> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) - and
> >> > >> this system is the normal calendaring system in Ethiopia. Some of the
> >> > >> CHWs we're working with have difficulty using the Gregorian calendar
> >> > >> as it's not what they are used to. As we'll be collecting information
> >> > >> regarding appointment dates, dates of birth etc, it's important that
> >> > >> we can use a date system that is familiar and understandable to the
> >> > >> CHWs.
>
> >> > >> On the ODK Collect end, the CHWs will be entering dates in the
> >> > >> Ethiopian calendar - which can include dates (dd/mm/yyyy format) such
> >> > >> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
> >> > >> Gregorian calendar, so we can't just use the normal database date
> >> > >> field with an offset.
>
> >> > >> On the other end of the system, we'll be generating reports based on
> >> > >> the input data, for example to give a list of who is due for a follow
> >> > >> up appointment in the next 7 days, so we'll need to do processing of
> >> > >> the dates stored in the ODK Aggregate database.
>
> >> > >> To save possible confusion over date formats I was hoping that in the
> >> > >> database we could store dates either as a unix timestamp or julian
> >> > >> days - as then it's straightforward to manipulate (eg, add 7 days),
> >> > >> compare and convert these dates/times into other formats for display
> >> > >> (eg Gregorian or Ethiopian - however we like).
>
> >> > >> I've thought about 3 possible ways we could deal with this and I'd be
> >> > >> really interested to hear anyone else's thoughts on which may be good/
> >> > >> bad or if there are other options available to us:
>
> >> > >> 1) Adapt ODK Collect so the date is converted to unix timestamp before
> >> > >> it is sent from the phone
> >> > >> 2) Adapt ODK Aggregate to the date is converted when the form arrives
> >> > >> at the server, but before the info is saved into the database
> >> > >> 3) Store the Ethiopian date in the ODK Aggregate database as-is (text
> >> > >> string or 3 separate integer fields) then regularly output this to
> >> > >> another table doing the date conversion at this point and using this
> >> > >> new table to generate the reports (there's no problem with a short
> >> > >> delay before the data is available for the reports - few hours, or
> >> > >> even day would be fine).
>
> >> > >> At the moment my preference is for option (3) - I'd like to keep the
> >> > >> programming/development to a minimum and would like to avoid making
> >> > >> customisations to ODKAggreate or ODKCollect which may make it
> >> > >> difficult for us to upgrade. I'm also not sure how easy/hard it would
> >> > >> be to implement (1) or (2).
>
> >> > >> Any help/advice/comments much appreciated :-)
>
> >> > >> Cheers,
> >> > >> Alex
>
> >> > >> --
> >> > >> Post: opendatakit@googlegroups.com
> >> > >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> >> > >> Options:http://groups.google.com/group/opendatakit?hl=en
>
> >> > > --
> >> > > Post: opendatakit@googlegroups.com
> >> > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> >> > > Options:http://groups.google.com/group/opendatakit?hl=en
>
> > --
> > Post: opendatakit@googlegroups.com
> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > Options:http://groups.google.com/group/opendatakit?hl=en
Since it would return a Date back into JavaRosa, you would want to use the
appearance attribute to choose to use this new date widget.
So in the form you'd have something like
....
And in WidgetFactory.java, you would use the appearance value to choose your
widget over the DateTime widget.
Mitch
···
On Wed, Aug 17, 2011 at 12:05 PM, Alex Little wrote:
Thanks Yaw,
I would prefer to keep the option of using the Gregorian date, so
would prefer to create a new widget rather than adapt the existing
date widget - even if it's a little more work.
since you'll have to roll your own collect anyway, i'd just substitute
your widget for the standard date widget and leave the form as is. if
you are using 1.1.7, you'll have to change date and datetime (assuming
you want date time) widgets. you'll also have to change the widget
factory to call your widget instead of the default widget.
Just been having a look at this (creating the widget), what I don't
quite get is (after I've created my new EthiopicDateWidget class):
what else I need to change in the ODKCollect code to get this
recognised as a valid form widget - is it just to add to the
WidgetFactory class - and to the JavaRosa constants too? Yaw, you
mentioned there where 3 files that need changing, assuming the two
I've mentioned are correct - which is the other?
what I would need to enter as the type attribute in the form xml to
get my ODKCollect to display the right widget.
Thanks Michael & Yaw. I didn't know about the jodaTime library and I
was expecting the conversion of the date on the ODKCollect client to
be a little harder than it seems it may be.
Will have a look as how I can create a widget and build the ODKCollect
client with the widget enabled.
assuming you have ethiopian date/datetime widgets already created,
i'd
recommend you make these modifications in collect 1.1.7. collect the
ethiopian date, convert to utc, and submit that. you'd only have to
change three very small files.
collect 1.1.7 has the jodatime library already included. right now
we
write out the local gregorian time with timezone. you can, as
michael
has described, easily convert ethiopian dates to utc before you send
it.
You mentioned you'd prefer option 3: "Store the Ethiopian date in
the ODK
Aggregate database as-is (text string or 3 separate integer
fields) then
regularly output this to another table doing the date conversion
at this
point".
Straightforward to do as a post-processing step using the Java
library Joda
Time:
For our data collection project, we'll be working with community
health workers (CHWs) in Ethiopia and I'm looking for some
help/advice
on the best way to cope with using/storing alternate date
formats.
Ethiopia has it's own calendar system - using 13 months and new
year
starts on either Sept 11th or 12th (depending on whether it's a
leap
year or not, much more on wikipedia about the Ethiopian
calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) -
and
this system is the normal calendaring system in Ethiopia. Some of
the
CHWs we're working with have difficulty using the Gregorian
calendar
as it's not what they are used to. As we'll be collecting
information
regarding appointment dates, dates of birth etc, it's important
that
we can use a date system that is familiar and understandable to
the
CHWs.
On the ODK Collect end, the CHWs will be entering dates in the
Ethiopian calendar - which can include dates (dd/mm/yyyy format)
such
as 30/2/2003, or 3/13/2002, which would be invalid dates in the
Gregorian calendar, so we can't just use the normal database date
field with an offset.
On the other end of the system, we'll be generating reports based
on
the input data, for example to give a list of who is due for a
follow
up appointment in the next 7 days, so we'll need to do processing
of
the dates stored in the ODK Aggregate database.
To save possible confusion over date formats I was hoping that in
the
database we could store dates either as a unix timestamp or
julian
days - as then it's straightforward to manipulate (eg, add 7
days),
compare and convert these dates/times into other formats for
display
(eg Gregorian or Ethiopian - however we like).
I've thought about 3 possible ways we could deal with this and
I'd be
really interested to hear anyone else's thoughts on which may be
good/
bad or if there are other options available to us:
Adapt ODK Collect so the date is converted to unix timestamp
before
it is sent from the phone
Adapt ODK Aggregate to the date is converted when the form
arrives
at the server, but before the info is saved into the database
Store the Ethiopian date in the ODK Aggregate database as-is
(text
string or 3 separate integer fields) then regularly output this
to
another table doing the date conversion at this point and using
this
new table to generate the reports (there's no problem with a
short
delay before the data is available for the reports - few hours,
or
even day would be fine).
At the moment my preference is for option (3) - I'd like to keep
the
programming/development to a minimum and would like to avoid
making
customisations to ODKAggreate or ODKCollect which may make it
difficult for us to upgrade. I'm also not sure how easy/hard it
would
be to implement (1) or (2).
Thanks Mitch - I had been trying to figure out how to specify what the
javarosa Constants.DATATYPE_ETHIOPIC value should be, but using the
appearance attribute makes sense.
So I updated the WidgetFactory to have:
case Constants.DATATYPE_DATE:
if(fep.getAppearanceHint() == "ethiopicDate"){
questionWidget = new EthiopicDateWidget(context,
fep);
} else {
questionWidget = new DateWidget(context, fep);
}
break;
and will test this out.
Thanks for everyone's quick replies! I'm a newbie to doing android
development, and it's been a while since I've done any java
development, but seem to be getting there (slowly!)
Alex
···
On Aug 17, 8:20 pm, Mitch Sundt wrote:
> Since it would return a Date back into JavaRosa, you would want to use the
> appearance attribute to choose to use this new date widget.
>
> So in the form you'd have something like
>
>
> ....
>
>
> And in WidgetFactory.java, you would use the appearance value to choose your
> widget over the DateTime widget.
>
> Mitch
>
>
>
>
>
> On Wed, Aug 17, 2011 at 12:05 PM, Alex Little wrote:
> > Thanks Yaw,
>
> > I would prefer to keep the option of using the Gregorian date, so
> > would prefer to create a new widget rather than adapt the existing
> > date widget - even if it's a little more work.
>
> > Alex
>
> > On Aug 17, 7:46 pm, Yaw Anokwa wrote:
> > > since you'll have to roll your own collect anyway, i'd just substitute
> > > your widget for the standard date widget and leave the form as is. if
> > > you are using 1.1.7, you'll have to change date and datetime (assuming
> > > you want date time) widgets. you'll also have to change the widget
> > > factory to call your widget instead of the default widget.
>
> > > On Wed, Aug 17, 2011 at 11:34, Alex Little wrote:
> > > > Just been having a look at this (creating the widget), what I don't
> > > > quite get is (after I've created my new EthiopicDateWidget class):
>
> > > > 1) what else I need to change in the ODKCollect code to get this
> > > > recognised as a valid form widget - is it just to add to the
> > > > WidgetFactory class - and to the JavaRosa constants too? Yaw, you
> > > > mentioned there where 3 files that need changing, assuming the two
> > > > I've mentioned are correct - which is the other?
> > > > 2) what I would need to enter as the type attribute in the form xml to
> > > > get my ODKCollect to display the right widget.
>
> > > > Any help much appreciated.
> > > > Cheers,
> > > > Alex
>
> > > > On Aug 17, 5:16 pm, Alex Little wrote:
> > > >> Thanks Michael & Yaw. I didn't know about the jodaTime library and I
> > > >> was expecting the conversion of the date on the ODKCollect client to
> > > >> be a little harder than it seems it may be.
>
> > > >> Will have a look as how I can create a widget and build the ODKCollect
> > > >> client with the widget enabled.
>
> > > >> Cheers,
> > > >> Alex
>
> > > >> On Aug 17, 4:05 pm, Yaw Anokwa wrote:
>
> > > >> > assuming you have ethiopian date/datetime widgets already created,
> > i'd
> > > >> > recommend you make these modifications in collect 1.1.7. collect the
> > > >> > ethiopian date, convert to utc, and submit that. you'd only have to
> > > >> > change three very small files.
>
> > > >> > collect 1.1.7 has the jodatime library already included. right now
> > we
> > > >> > write out the local gregorian time with timezone. you can, as
> > michael
> > > >> > has described, easily convert ethiopian dates to utc before you send
> > > >> > it.
>
> > > >> > On Wed, Aug 17, 2011 at 07:53, Michael Willekes < mikewille...@gmail.com> wrote:
> > > >> > > Alex,
>
> > > >> > > You mentioned you'd prefer option 3: "Store the Ethiopian date in
> > the ODK
> > > >> > > Aggregate database as-is (text string or 3 separate integer
> > fields) then
> > > >> > > regularly output this to another table doing the date conversion
> > at this
> > > >> > > point".
>
> > > >> > > Straightforward to do as a post-processing step using the Java
> > library Joda
> > > >> > > Time:
>
> > > >> > > // Create Ethiopian Chronology
> > > >> > > Chronology chron_eth =
>
> > EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
>
> > > >> > > // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
> > > >> > > DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0,
> > chron_eth);
>
> > > >> > > // Convert to Gregorian Date/Time
> > > >> > > DateTime dt_greg =
> > dt_eth.withChronology(GregorianChronology.getInstance());
>
> > > >> > > System.out.println("Ethiopian Date: " +
> > > >> > > DateTimeFormat.fullDate().print(dt_eth));
> > > >> > > System.out.println("Gregorian Date: " +
> > > >> > > DateTimeFormat.fullDate().print(dt_greg));
>
> > > >> > > This outputs:
>
> > > >> > > Ethiopian Date: Tuesday, 2 30, 2003
> > > >> > > Gregorian Date: Monday, November 8, 2010
>
> > > >> > > Regards,
> > > >> > > Mike
>
> > > >> > > On Wed, Aug 17, 2011 at 10:11 AM, Alex Little < a...@alexlittle.net> wrote:
>
> > > >> > >> Hi all,
>
> > > >> > >> For our data collection project, we'll be working with community
> > > >> > >> health workers (CHWs) in Ethiopia and I'm looking for some
> > help/advice
> > > >> > >> on the best way to cope with using/storing alternate date
> > formats.
>
> > > >> > >> Ethiopia has it's own calendar system - using 13 months and new
> > year
> > > >> > >> starts on either Sept 11th or 12th (depending on whether it's a
> > leap
> > > >> > >> year or not, much more on wikipedia about the Ethiopian
> > > >> > >> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) -
> > and
> > > >> > >> this system is the normal calendaring system in Ethiopia. Some of
> > the
> > > >> > >> CHWs we're working with have difficulty using the Gregorian
> > calendar
> > > >> > >> as it's not what they are used to. As we'll be collecting
> > information
> > > >> > >> regarding appointment dates, dates of birth etc, it's important
> > that
> > > >> > >> we can use a date system that is familiar and understandable to
> > the
> > > >> > >> CHWs.
>
> > > >> > >> On the ODK Collect end, the CHWs will be entering dates in the
> > > >> > >> Ethiopian calendar - which can include dates (dd/mm/yyyy format)
> > such
> > > >> > >> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
> > > >> > >> Gregorian calendar, so we can't just use the normal database date
> > > >> > >> field with an offset.
>
> > > >> > >> On the other end of the system, we'll be generating reports based
> > on
> > > >> > >> the input data, for example to give a list of who is due for a
> > follow
> > > >> > >> up appointment in the next 7 days, so we'll need to do processing
> > of
> > > >> > >> the dates stored in the ODK Aggregate database.
>
> > > >> > >> To save possible confusion over date formats I was hoping that in
> > the
> > > >> > >> database we could store dates either as a unix timestamp or
> > julian
> > > >> > >> days - as then it's straightforward to manipulate (eg, add 7
> > days),
> > > >> > >> compare and convert these dates/times into other formats for
> > display
> > > >> > >> (eg Gregorian or Ethiopian - however we like).
>
> > > >> > >> I've thought about 3 possible ways we could deal with this and
> > I'd be
> > > >> > >> really interested to hear anyone else's thoughts on which may be
> > good/
> > > >> > >> bad or if there are other options available to us:
>
> > > >> > >> 1) Adapt ODK Collect so the date is converted to unix timestamp
> > before
> > > >> > >> it is sent from the phone
> > > >> > >> 2) Adapt ODK Aggregate to the date is converted when the form
> > arrives
> > > >> > >> at the server, but before the info is saved into the database
> > > >> > >> 3) Store the Ethiopian date in the ODK Aggregate database as-is
> > (text
> > > >> > >> string or 3 separate integer fields) then regularly output this
> > to
> > > >> > >> another table doing the date conversion at this point and using
> > this
> > > >> > >> new table to generate the reports (there's no problem with a
> > short
> > > >> > >> delay before the data is available for the reports - few hours,
> > or
> > > >> > >> even day would be fine).
>
> > > >> > >> At the moment my preference is for option (3) - I'd like to keep
> > the
> > > >> > >> programming/development to a minimum and would like to avoid
> > making
> > > >> > >> customisations to ODKAggreate or ODKCollect which may make it
> > > >> > >> difficult for us to upgrade. I'm also not sure how easy/hard it
> > would
> > > >> > >> be to implement (1) or (2).
>
> > > >> > >> Any help/advice/comments much appreciated :-)
>
> > > >> > >> Cheers,
> > > >> > >> Alex
>
> > > >> > >> --
> > > >> > >> Post: opendatakit@googlegroups.com
> > > >> > >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > > >> > >> Options:http://groups.google.com/group/opendatakit?hl=en
>
> > > >> > > --
> > > >> > > Post: opendatakit@googlegroups.com
> > > >> > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > > >> > > Options:http://groups.google.com/group/opendatakit?hl=en
>
> > > > --
> > > > Post: opendatakit@googlegroups.com
> > > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > > > Options:http://groups.google.com/group/opendatakit?hl=en
>
> > --
> > Post: opendatakit@googlegroups.com
> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > Options:http://groups.google.com/group/opendatakit?hl=en
>
> --
> Mitch Sundt
> Software Engineerhttp://www.OpenDataKit.org
> University of Washington
> mitchellsu...@gmail.com
Oops... just worked out the if statement condition should be:
if(fep.getQuestion().getAppearanceAttr().equals("ethiopicDate"))
Instead of what I wrote below...
A
···
On Aug 17, 9:29 pm, Alex Little wrote:
> Thanks Mitch - I had been trying to figure out how to specify what the
> javarosa Constants.DATATYPE_ETHIOPIC value should be, but using the
> appearance attribute makes sense.
>
> So I updated the WidgetFactory to have:
> case Constants.DATATYPE_DATE:
> if(fep.getAppearanceHint() == "ethiopicDate"){
> questionWidget = new EthiopicDateWidget(context,
> fep);
> } else {
> questionWidget = new DateWidget(context, fep);
> }
> break;
>
> and will test this out.
>
> Thanks for everyone's quick replies! I'm a newbie to doing android
> development, and it's been a while since I've done any java
> development, but seem to be getting there (slowly!)
>
> Alex
>
> On Aug 17, 8:20 pm, Mitch Sundt wrote:
>
>
>
> > Since it would return a Date back into JavaRosa, you would want to use the
> > appearance attribute to choose to use this new date widget.
>
> > So in the form you'd have something like
>
> >
> > ....
> >
>
> > And in WidgetFactory.java, you would use the appearance value to choose your
> > widget over the DateTime widget.
>
> > Mitch
>
> > On Wed, Aug 17, 2011 at 12:05 PM, Alex Little wrote:
> > > Thanks Yaw,
>
> > > I would prefer to keep the option of using the Gregorian date, so
> > > would prefer to create a new widget rather than adapt the existing
> > > date widget - even if it's a little more work.
>
> > > Alex
>
> > > On Aug 17, 7:46 pm, Yaw Anokwa wrote:
> > > > since you'll have to roll your own collect anyway, i'd just substitute
> > > > your widget for the standard date widget and leave the form as is. if
> > > > you are using 1.1.7, you'll have to change date and datetime (assuming
> > > > you want date time) widgets. you'll also have to change the widget
> > > > factory to call your widget instead of the default widget.
>
> > > > On Wed, Aug 17, 2011 at 11:34, Alex Little wrote:
> > > > > Just been having a look at this (creating the widget), what I don't
> > > > > quite get is (after I've created my new EthiopicDateWidget class):
>
> > > > > 1) what else I need to change in the ODKCollect code to get this
> > > > > recognised as a valid form widget - is it just to add to the
> > > > > WidgetFactory class - and to the JavaRosa constants too? Yaw, you
> > > > > mentioned there where 3 files that need changing, assuming the two
> > > > > I've mentioned are correct - which is the other?
> > > > > 2) what I would need to enter as the type attribute in the form xml to
> > > > > get my ODKCollect to display the right widget.
>
> > > > > Any help much appreciated.
> > > > > Cheers,
> > > > > Alex
>
> > > > > On Aug 17, 5:16 pm, Alex Little wrote:
> > > > >> Thanks Michael & Yaw. I didn't know about the jodaTime library and I
> > > > >> was expecting the conversion of the date on the ODKCollect client to
> > > > >> be a little harder than it seems it may be.
>
> > > > >> Will have a look as how I can create a widget and build the ODKCollect
> > > > >> client with the widget enabled.
>
> > > > >> Cheers,
> > > > >> Alex
>
> > > > >> On Aug 17, 4:05 pm, Yaw Anokwa wrote:
>
> > > > >> > assuming you have ethiopian date/datetime widgets already created,
> > > i'd
> > > > >> > recommend you make these modifications in collect 1.1.7. collect the
> > > > >> > ethiopian date, convert to utc, and submit that. you'd only have to
> > > > >> > change three very small files.
>
> > > > >> > collect 1.1.7 has the jodatime library already included. right now
> > > we
> > > > >> > write out the local gregorian time with timezone. you can, as
> > > michael
> > > > >> > has described, easily convert ethiopian dates to utc before you send
> > > > >> > it.
>
> > > > >> > On Wed, Aug 17, 2011 at 07:53, Michael Willekes < mikewille...@gmail.com> wrote:
> > > > >> > > Alex,
>
> > > > >> > > You mentioned you'd prefer option 3: "Store the Ethiopian date in
> > > the ODK
> > > > >> > > Aggregate database as-is (text string or 3 separate integer
> > > fields) then
> > > > >> > > regularly output this to another table doing the date conversion
> > > at this
> > > > >> > > point".
>
> > > > >> > > Straightforward to do as a post-processing step using the Java
> > > library Joda
> > > > >> > > Time:
>
> > > > >> > > // Create Ethiopian Chronology
> > > > >> > > Chronology chron_eth =
>
> > > EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
>
> > > > >> > > // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
> > > > >> > > DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0,
> > > chron_eth);
>
> > > > >> > > // Convert to Gregorian Date/Time
> > > > >> > > DateTime dt_greg =
> > > dt_eth.withChronology(GregorianChronology.getInstance());
>
> > > > >> > > System.out.println("Ethiopian Date: " +
> > > > >> > > DateTimeFormat.fullDate().print(dt_eth));
> > > > >> > > System.out.println("Gregorian Date: " +
> > > > >> > > DateTimeFormat.fullDate().print(dt_greg));
>
> > > > >> > > This outputs:
>
> > > > >> > > Ethiopian Date: Tuesday, 2 30, 2003
> > > > >> > > Gregorian Date: Monday, November 8, 2010
>
> > > > >> > > Regards,
> > > > >> > > Mike
>
> > > > >> > > On Wed, Aug 17, 2011 at 10:11 AM, Alex Little < a...@alexlittle.net> wrote:
>
> > > > >> > >> Hi all,
>
> > > > >> > >> For our data collection project, we'll be working with community
> > > > >> > >> health workers (CHWs) in Ethiopia and I'm looking for some
> > > help/advice
> > > > >> > >> on the best way to cope with using/storing alternate date
> > > formats.
>
> > > > >> > >> Ethiopia has it's own calendar system - using 13 months and new
> > > year
> > > > >> > >> starts on either Sept 11th or 12th (depending on whether it's a
> > > leap
> > > > >> > >> year or not, much more on wikipedia about the Ethiopian
> > > > >> > >> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) -
> > > and
> > > > >> > >> this system is the normal calendaring system in Ethiopia. Some of
> > > the
> > > > >> > >> CHWs we're working with have difficulty using the Gregorian
> > > calendar
> > > > >> > >> as it's not what they are used to. As we'll be collecting
> > > information
> > > > >> > >> regarding appointment dates, dates of birth etc, it's important
> > > that
> > > > >> > >> we can use a date system that is familiar and understandable to
> > > the
> > > > >> > >> CHWs.
>
> > > > >> > >> On the ODK Collect end, the CHWs will be entering dates in the
> > > > >> > >> Ethiopian calendar - which can include dates (dd/mm/yyyy format)
> > > such
> > > > >> > >> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
> > > > >> > >> Gregorian calendar, so we can't just use the normal database date
> > > > >> > >> field with an offset.
>
> > > > >> > >> On the other end of the system, we'll be generating reports based
> > > on
> > > > >> > >> the input data, for example to give a list of who is due for a
> > > follow
> > > > >> > >> up appointment in the next 7 days, so we'll need to do processing
> > > of
> > > > >> > >> the dates stored in the ODK Aggregate database.
>
> > > > >> > >> To save possible confusion over date formats I was hoping that in
> > > the
> > > > >> > >> database we could store dates either as a unix timestamp or
> > > julian
> > > > >> > >> days - as then it's straightforward to manipulate (eg, add 7
> > > days),
> > > > >> > >> compare and convert these dates/times into other formats for
> > > display
> > > > >> > >> (eg Gregorian or Ethiopian - however we like).
>
> > > > >> > >> I've thought about 3 possible ways we could deal with this and
> > > I'd be
> > > > >> > >> really interested to hear anyone else's thoughts on which may be
> > > good/
> > > > >> > >> bad or if there are other options available to us:
>
> > > > >> > >> 1) Adapt ODK Collect so the date is converted to unix timestamp
> > > before
> > > > >> > >> it is sent from the phone
> > > > >> > >> 2) Adapt ODK Aggregate to the date is converted when the form
> > > arrives
> > > > >> > >> at the server, but before the info is saved into the database
> > > > >> > >> 3) Store the Ethiopian date in the ODK Aggregate database as-is
> > > (text
> > > > >> > >> string or 3 separate integer fields) then regularly output this
> > > to
> > > > >> > >> another table doing the date conversion at this point and using
> > > this
> > > > >> > >> new table to generate the reports (there's no problem with a
> > > short
> > > > >> > >> delay before the data is available for the reports - few hours,
> > > or
> > > > >> > >> even day would be fine).
>
> > > > >> > >> At the moment my preference is for option (3) - I'd like to keep
> > > the
> > > > >> > >> programming/development to a minimum and would like to avoid
> > > making
> > > > >> > >> customisations to ODKAggreate or ODKCollect which may make it
> > > > >> > >> difficult for us to upgrade. I'm also not sure how easy/hard it
> > > would
> > > > >> > >> be to implement (1) or (2).
>
> > > > >> > >> Any help/advice/comments much appreciated :-)
>
> > > > >> > >> Cheers,
> > > > >> > >> Alex
>
> > > > >> > >> --
> > > > >> > >> Post: opendatakit@googlegroups.com
> > > > >> > >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > > > >> > >> Options:http://groups.google.com/group/opendatakit?hl=en
>
> > > > >> > > --
> > > > >> > > Post: opendatakit@googlegroups.com
> > > > >> > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > > > >> > > Options:http://groups.google.com/group/opendatakit?hl=en
>
> > > > > --
> > > > > Post: opendatakit@googlegroups.com
> > > > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > > > > Options:http://groups.google.com/group/opendatakit?hl=en
>
> > > --
> > > Post: opendatakit@googlegroups.com
> > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> > > Options:http://groups.google.com/group/opendatakit?hl=en
>
> > --
>
> ...
>
> read more »
I've started to develop the new widget class for the Ethiopic
calendar, but I'm finding that it's very slow to load when I'm using
it in a form, when you swipe to move on to a question using the new
widget, it can take 15-30 seconds or more to load the question. Other
question types will load in a reasonable time, so pretty sure it;s
something to do with how I've coded the widget rather than my phone/
emulator being slow. It's so slow that you think the application has
frozen - though I don;t get any errors logged.
it's the first time I've done any android development, so not sure if
it;s something to do with how I'm using the tablelayout/buttons/
listeners or something else.
it's still under development, so I haven't yet added all the
functions, listeners and date saving/checking - but it's developed
enough to see it's slow!
Any advice/suggestions on how I can get the widget to load more
quickly much appreciated,
Cheers,
Alex
···
On Aug 17, 9:53 pm, Alex Little wrote:
> Oops... just worked out the if statement condition should be:
> if(fep.getQuestion().getAppearanceAttr().equals("ethiopicDate"))
>
> Instead of what I wrote below...
> A
>
> On Aug 17, 9:29 pm, Alex Little wrote:
>
>
>
> > Thanks Mitch - I had been trying to figure out how to specify what the
> > javarosa Constants.DATATYPE_ETHIOPIC value should be, but using the
> > appearance attribute makes sense.
>
> > So I updated the WidgetFactory to have:
> > case Constants.DATATYPE_DATE:
> > if(fep.getAppearanceHint() == "ethiopicDate"){
> > questionWidget = new EthiopicDateWidget(context,
> > fep);
> > } else {
> > questionWidget = new DateWidget(context, fep);
> > }
> > break;
>
> > and will test this out.
>
> > Thanks for everyone's quick replies! I'm a newbie to doing android
> > development, and it's been a while since I've done any java
> > development, but seem to be getting there (slowly!)
>
> > Alex
>
> > On Aug 17, 8:20 pm, Mitch Sundt wrote:
>
> > > Since it would return a Date back into JavaRosa, you would want to use the
> > > appearance attribute to choose to use this new date widget.
>
> > > So in the form you'd have something like
>
> > >
> > > ....
> > >
>
> > > And in WidgetFactory.java, you would use the appearance value to choose your
> > > widget over the DateTime widget.
>
> > > Mitch
>
> > > On Wed, Aug 17, 2011 at 12:05 PM, Alex Little wrote:
> > > > Thanks Yaw,
>
> > > > I would prefer to keep the option of using the Gregorian date, so
> > > > would prefer to create a new widget rather than adapt the existing
> > > > date widget - even if it's a little more work.
>
> > > > Alex
>
> > > > On Aug 17, 7:46 pm, Yaw Anokwa wrote:
> > > > > since you'll have to roll your own collect anyway, i'd just substitute
> > > > > your widget for the standard date widget and leave the form as is. if
> > > > > you are using 1.1.7, you'll have to change date and datetime (assuming
> > > > > you want date time) widgets. you'll also have to change the widget
> > > > > factory to call your widget instead of the default widget.
>
> > > > > On Wed, Aug 17, 2011 at 11:34, Alex Little wrote:
> > > > > > Just been having a look at this (creating the widget), what I don't
> > > > > > quite get is (after I've created my new EthiopicDateWidget class):
>
> > > > > > 1) what else I need to change in the ODKCollect code to get this
> > > > > > recognised as a valid form widget - is it just to add to the
> > > > > > WidgetFactory class - and to the JavaRosa constants too? Yaw, you
> > > > > > mentioned there where 3 files that need changing, assuming the two
> > > > > > I've mentioned are correct - which is the other?
> > > > > > 2) what I would need to enter as the type attribute in the form xml to
> > > > > > get my ODKCollect to display the right widget.
>
> > > > > > Any help much appreciated.
> > > > > > Cheers,
> > > > > > Alex
>
> > > > > > On Aug 17, 5:16 pm, Alex Little wrote:
> > > > > >> Thanks Michael & Yaw. I didn't know about the jodaTime library and I
> > > > > >> was expecting the conversion of the date on the ODKCollect client to
> > > > > >> be a little harder than it seems it may be.
>
> > > > > >> Will have a look as how I can create a widget and build the ODKCollect
> > > > > >> client with the widget enabled.
>
> > > > > >> Cheers,
> > > > > >> Alex
>
> > > > > >> On Aug 17, 4:05 pm, Yaw Anokwa wrote:
>
> > > > > >> > assuming you have ethiopian date/datetime widgets already created,
> > > > i'd
> > > > > >> > recommend you make these modifications in collect 1.1.7. collect the
> > > > > >> > ethiopian date, convert to utc, and submit that. you'd only have to
> > > > > >> > change three very small files.
>
> > > > > >> > collect 1.1.7 has the jodatime library already included. right now
> > > > we
> > > > > >> > write out the local gregorian time with timezone. you can, as
> > > > michael
> > > > > >> > has described, easily convert ethiopian dates to utc before you send
> > > > > >> > it.
>
> > > > > >> > On Wed, Aug 17, 2011 at 07:53, Michael Willekes < mikewille...@gmail.com> wrote:
> > > > > >> > > Alex,
>
> > > > > >> > > You mentioned you'd prefer option 3: "Store the Ethiopian date in
> > > > the ODK
> > > > > >> > > Aggregate database as-is (text string or 3 separate integer
> > > > fields) then
> > > > > >> > > regularly output this to another table doing the date conversion
> > > > at this
> > > > > >> > > point".
>
> > > > > >> > > Straightforward to do as a post-processing step using the Java
> > > > library Joda
> > > > > >> > > Time:
>
> > > > > >> > > // Create Ethiopian Chronology
> > > > > >> > > Chronology chron_eth =
>
> > > > EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
>
> > > > > >> > > // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
> > > > > >> > > DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0,
> > > > chron_eth);
>
> > > > > >> > > // Convert to Gregorian Date/Time
> > > > > >> > > DateTime dt_greg =
> > > > dt_eth.withChronology(GregorianChronology.getInstance());
>
> > > > > >> > > System.out.println("Ethiopian Date: " +
> > > > > >> > > DateTimeFormat.fullDate().print(dt_eth));
> > > > > >> > > System.out.println("Gregorian Date: " +
> > > > > >> > > DateTimeFormat.fullDate().print(dt_greg));
>
> > > > > >> > > This outputs:
>
> > > > > >> > > Ethiopian Date: Tuesday, 2 30, 2003
> > > > > >> > > Gregorian Date: Monday, November 8, 2010
>
> > > > > >> > > Regards,
> > > > > >> > > Mike
>
> > > > > >> > > On Wed, Aug 17, 2011 at 10:11 AM, Alex Little < a...@alexlittle.net> wrote:
>
> > > > > >> > >> Hi all,
>
> > > > > >> > >> For our data collection project, we'll be working with community
> > > > > >> > >> health workers (CHWs) in Ethiopia and I'm looking for some
> > > > help/advice
> > > > > >> > >> on the best way to cope with using/storing alternate date
> > > > formats.
>
> > > > > >> > >> Ethiopia has it's own calendar system - using 13 months and new
> > > > year
> > > > > >> > >> starts on either Sept 11th or 12th (depending on whether it's a
> > > > leap
> > > > > >> > >> year or not, much more on wikipedia about the Ethiopian
> > > > > >> > >> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) -
> > > > and
> > > > > >> > >> this system is the normal calendaring system in Ethiopia. Some of
> > > > the
> > > > > >> > >> CHWs we're working with have difficulty using the Gregorian
> > > > calendar
> > > > > >> > >> as it's not what they are used to. As we'll be collecting
> > > > information
> > > > > >> > >> regarding appointment dates, dates of birth etc, it's important
> > > > that
> > > > > >> > >> we can use a date system that is familiar and understandable to
> > > > the
> > > > > >> > >> CHWs.
>
> > > > > >> > >> On the ODK Collect end, the CHWs will be entering dates in the
> > > > > >> > >> Ethiopian calendar - which can include dates (dd/mm/yyyy format)
> > > > such
> > > > > >> > >> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
> > > > > >> > >> Gregorian calendar, so we can't just use the normal database date
> > > > > >> > >> field with an offset.
>
> > > > > >> > >> On the other end of the system, we'll be generating reports based
> > > > on
> > > > > >> > >> the input data, for example to give a list of who is due for a
> > > > follow
> > > > > >> > >> up appointment in the next 7 days, so we'll need to do processing
> > > > of
> > > > > >> > >> the dates stored in the ODK Aggregate database.
>
> > > > > >> > >> To save possible confusion over date formats I was hoping that in
> > > > the
> > > > > >> > >> database we could store dates either as a unix timestamp or
> > > > julian
> > > > > >> > >> days - as then it's straightforward to manipulate (eg, add 7
> > > > days),
> > > > > >> > >> compare and convert these dates/times into other formats for
> > > > display
> > > > > >> > >> (eg Gregorian or Ethiopian - however we like).
>
> > > > > >> > >> I've thought about 3 possible ways we could deal with this and
> > > > I'd be
> > > > > >> > >> really interested to hear anyone else's thoughts on which may be
> > > > good/
> > > > > >> > >> bad or if there are other options available to us:
>
> > > > > >> > >> 1) Adapt ODK Collect so the date is converted to unix timestamp
> > > > before
> > > > > >> > >> it is sent from the phone
> > > > > >> > >> 2) Adapt ODK Aggregate to the date is converted when the form
> > > > arrives
> > > > > >> > >> at the server, but before the info is saved into the database
> > > > > >> > >> 3) Store the Ethiopian date in the ODK Aggregate database as-is
> > > > (text
> > > > > >> > >> string or 3 separate integer fields) then regularly output this
> > > > to
> > > > > >> > >> another table doing the date conversion at this point and using
> > > > this
> > > > > >> > >> new table to generate the reports (there's no problem with a
> > > > short
> > > > > >> > >> delay before the data is available for the reports - few hours,
> > > > or
> > > > > >> > >> even day would be fine).
>
> > > > > >> > >> At the moment my preference is for option (3) - I'd like to keep
> > > > the
> > > > > >> > >> programming/development to a minimum and would like to avoid
> > > > making
> > > > > >> > >> customisations to ODKAggreate or ODKCollect which may make it
> > > > > >> > >> difficult for us to upgrade. I'm also not sure how easy/hard it
> > > > would
> > > > > >> > >> be to implement (1) or (2).
>
> > > > > >> > >> Any help/advice/comments much appreciated :-)
>
> > > > > >> > >> Cheers,
> > > > > >> > >> Alex
>
> > > > > >> > >> --
>
> ...
>
> read more »
···
> Hi all,
>
> I've started to develop the new widget class for the Ethiopic
> calendar, but I'm finding that it's very slow to load when I'm using
> it in a form, when you swipe to move on to a question using the new
> widget, it can take 15-30 seconds or more to load the question. Other
> question types will load in a reasonable time, so pretty sure it;s
> something to do with how I've coded the widget rather than my phone/
> emulator being slow. It's so slow that you think the application has
> frozen - though I don;t get any errors logged.
>
> it's the first time I've done any android development, so not sure if
> it;s something to do with how I'm using the tablelayout/buttons/
> listeners or something else.
>
> I've put the code up at: http://alexlittle.net/blog/downloads/EthiopicDateWidget.java
> - it's still under development, so I haven't yet added all the
> functions, listeners and date saving/checking - but it's developed
> enough to see it's slow!
>
> Also, here's my edited WidgetFactory class http://alexlittle.net/blog/downloads/WidgetFactory.java
>
> and an example form which uses the widget:
> http://alexlittle.net/blog/downloads/EthiopicDateWidget.java
>
>
> Any advice/suggestions on how I can get the widget to load more
> quickly much appreciated,
>
> Cheers,
> Alex
> On Aug 17, 9:53 pm, Alex Little wrote:
> > Oops... just worked out the if statement condition should be:
> > if(fep.getQuestion().getAppearanceAttr().equals("ethiopicDate"))
> >
> > Instead of what I wrote below...
> > A
> >
> > On Aug 17, 9:29 pm, Alex Little wrote:
> >
> >
> >
> > > Thanks Mitch - I had been trying to figure out how to specify what the
> > > javarosa Constants.DATATYPE_ETHIOPIC value should be, but using the
> > > appearance attribute makes sense.
> >
> > > So I updated the WidgetFactory to have:
> > > case Constants.DATATYPE_DATE:
> > > if(fep.getAppearanceHint() == "ethiopicDate"){
> > > questionWidget = new EthiopicDateWidget(context,
> > > fep);
> > > } else {
> > > questionWidget = new DateWidget(context, fep);
> > > }
> > > break;
> >
> > > and will test this out.
> >
> > > Thanks for everyone's quick replies! I'm a newbie to doing android
> > > development, and it's been a while since I've done any java
> > > development, but seem to be getting there (slowly!)
> >
> > > Alex
> >
> > > On Aug 17, 8:20 pm, Mitch Sundt wrote:
> >
> > > > Since it would return a Date back into JavaRosa, you would want to use the
> > > > appearance attribute to choose to use this new date widget.
> >
> > > > So in the form you'd have something like
> >
> > > >
> > > > ....
> > > >
> >
> > > > And in WidgetFactory.java, you would use the appearance value to choose your
> > > > widget over the DateTime widget.
> >
> > > > Mitch
> >
> > > > On Wed, Aug 17, 2011 at 12:05 PM, Alex Little wrote:
> > > > > Thanks Yaw,
> >
> > > > > I would prefer to keep the option of using the Gregorian date, so
> > > > > would prefer to create a new widget rather than adapt the existing
> > > > > date widget - even if it's a little more work.
> >
> > > > > Alex
> >
> > > > > On Aug 17, 7:46 pm, Yaw Anokwa wrote:
> > > > > > since you'll have to roll your own collect anyway, i'd just substitute
> > > > > > your widget for the standard date widget and leave the form as is. if
> > > > > > you are using 1.1.7, you'll have to change date and datetime (assuming
> > > > > > you want date time) widgets. you'll also have to change the widget
> > > > > > factory to call your widget instead of the default widget.
> >
> > > > > > On Wed, Aug 17, 2011 at 11:34, Alex Little wrote:
> > > > > > > Just been having a look at this (creating the widget), what I don't
> > > > > > > quite get is (after I've created my new EthiopicDateWidget class):
> >
> > > > > > > 1) what else I need to change in the ODKCollect code to get this
> > > > > > > recognised as a valid form widget - is it just to add to the
> > > > > > > WidgetFactory class - and to the JavaRosa constants too? Yaw, you
> > > > > > > mentioned there where 3 files that need changing, assuming the two
> > > > > > > I've mentioned are correct - which is the other?
> > > > > > > 2) what I would need to enter as the type attribute in the form xml to
> > > > > > > get my ODKCollect to display the right widget.
> >
> > > > > > > Any help much appreciated.
> > > > > > > Cheers,
> > > > > > > Alex
> >
> > > > > > > On Aug 17, 5:16 pm, Alex Little wrote:
> > > > > > >> Thanks Michael & Yaw. I didn't know about the jodaTime library and I
> > > > > > >> was expecting the conversion of the date on the ODKCollect client to
> > > > > > >> be a little harder than it seems it may be.
> >
> > > > > > >> Will have a look as how I can create a widget and build the ODKCollect
> > > > > > >> client with the widget enabled.
> >
> > > > > > >> Cheers,
> > > > > > >> Alex
> >
> > > > > > >> On Aug 17, 4:05 pm, Yaw Anokwa wrote:
> >
> > > > > > >> > assuming you have ethiopian date/datetime widgets already created,
> > > > > i'd
> > > > > > >> > recommend you make these modifications in collect 1.1.7. collect the
> > > > > > >> > ethiopian date, convert to utc, and submit that. you'd only have to
> > > > > > >> > change three very small files.
> >
> > > > > > >> > collect 1.1.7 has the jodatime library already included. right now
> > > > > we
> > > > > > >> > write out the local gregorian time with timezone. you can, as
> > > > > michael
> > > > > > >> > has described, easily convert ethiopian dates to utc before you send
> > > > > > >> > it.
> >
> > > > > > >> > On Wed, Aug 17, 2011 at 07:53, Michael Willekes < mikewille...@gmail.com> wrote:
> > > > > > >> > > Alex,
> >
> > > > > > >> > > You mentioned you'd prefer option 3: "Store the Ethiopian date in
> > > > > the ODK
> > > > > > >> > > Aggregate database as-is (text string or 3 separate integer
> > > > > fields) then
> > > > > > >> > > regularly output this to another table doing the date conversion
> > > > > at this
> > > > > > >> > > point".
> >
> > > > > > >> > > Straightforward to do as a post-processing step using the Java
> > > > > library Joda
> > > > > > >> > > Time:
> >
> > > > > > >> > > // Create Ethiopian Chronology
> > > > > > >> > > Chronology chron_eth =
> >
> > > > > EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
> >
> > > > > > >> > > // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
> > > > > > >> > > DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0,
> > > > > chron_eth);
> >
> > > > > > >> > > // Convert to Gregorian Date/Time
> > > > > > >> > > DateTime dt_greg =
> > > > > dt_eth.withChronology(GregorianChronology.getInstance());
> >
> > > > > > >> > > System.out.println("Ethiopian Date: " +
> > > > > > >> > > DateTimeFormat.fullDate().print(dt_eth));
> > > > > > >> > > System.out.println("Gregorian Date: " +
> > > > > > >> > > DateTimeFormat.fullDate().print(dt_greg));
> >
> > > > > > >> > > This outputs:
> >
> > > > > > >> > > Ethiopian Date: Tuesday, 2 30, 2003
> > > > > > >> > > Gregorian Date: Monday, November 8, 2010
> >
> > > > > > >> > > Regards,
> > > > > > >> > > Mike
> >
> > > > > > >> > > On Wed, Aug 17, 2011 at 10:11 AM, Alex Little < a...@alexlittle.net> wrote:
> >
> > > > > > >> > >> Hi all,
> >
> > > > > > >> > >> For our data collection project, we'll be working with community
> > > > > > >> > >> health workers (CHWs) in Ethiopia and I'm looking for some
> > > > > help/advice
> > > > > > >> > >> on the best way to cope with using/storing alternate date
> > > > > formats.
> >
> > > > > > >> > >> Ethiopia has it's own calendar system - using 13 months and new
> > > > > year
> > > > > > >> > >> starts on either Sept 11th or 12th (depending on whether it's a
> > > > > leap
> > > > > > >> > >> year or not, much more on wikipedia about the Ethiopian
> > > > > > >> > >> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) -
> > > > > and
> > > > > > >> > >> this system is the normal calendaring system in Ethiopia. Some of
> > > > > the
> > > > > > >> > >> CHWs we're working with have difficulty using the Gregorian
> > > > > calendar
> > > > > > >> > >> as it's not what they are used to. As we'll be collecting
> > > > > information
> > > > > > >> > >> regarding appointment dates, dates of birth etc, it's important
> > > > > that
> > > > > > >> > >> we can use a date system that is familiar and understandable to
> > > > > the
> > > > > > >> > >> CHWs.
> >
> > > > > > >> > >> On the ODK Collect end, the CHWs will be entering dates in the
> > > > > > >> > >> Ethiopian calendar - which can include dates (dd/mm/yyyy format)
> > > > > such
> > > > > > >> > >> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
> > > > > > >> > >> Gregorian calendar, so we can't just use the normal database date
> > > > > > >> > >> field with an offset.
> >
> > > > > > >> > >> On the other end of the system, we'll be generating reports based
> > > > > on
> > > > > > >> > >> the input data, for example to give a list of who is due for a
> > > > > follow
> > > > > > >> > >> up appointment in the next 7 days, so we'll need to do processing
> > > > > of
> > > > > > >> > >> the dates stored in the ODK Aggregate database.
> >
> > > > > > >> > >> To save possible confusion over date formats I was hoping that in
> > > > > the
> > > > > > >> > >> database we could store dates either as a unix timestamp or
> > > > > julian
> > > > > > >> > >> days - as then it's straightforward to manipulate (eg, add 7
> > > > > days),
> > > > > > >> > >> compare and convert these dates/times into other formats for
> > > > > display
> > > > > > >> > >> (eg Gregorian or Ethiopian - however we like).
> >
> > > > > > >> > >> I've thought about 3 possible ways we could deal with this and
> > > > > I'd be
> > > > > > >> > >> really interested to hear anyone else's thoughts on which may be
> > > > > good/
> > > > > > >> > >> bad or if there are other options available to us:
> >
> > > > > > >> > >> 1) Adapt ODK Collect so the date is converted to unix timestamp
> > > > > before
> > > > > > >> > >> it is sent from the phone
> > > > > > >> > >> 2) Adapt ODK Aggregate to the date is converted when the form
> > > > > arrives
> > > > > > >> > >> at the server, but before the info is saved into the database
> > > > > > >> > >> 3) Store the Ethiopian date in the ODK Aggregate database as-is
> > > > > (text
> > > > > > >> > >> string or 3 separate integer fields) then regularly output this
> > > > > to
> > > > > > >> > >> another table doing the date conversion at this point and using
> > > > > this
> > > > > > >> > >> new table to generate the reports (there's no problem with a
> > > > > short
> > > > > > >> > >> delay before the data is available for the reports - few hours,
> > > > > or
> > > > > > >> > >> even day would be fine).
> >
> > > > > > >> > >> At the moment my preference is for option (3) - I'd like to keep
> > > > > the
> > > > > > >> > >> programming/development to a minimum and would like to avoid
> > > > > making
> > > > > > >> > >> customisations to ODKAggreate or ODKCollect which may make it
> > > > > > >> > >> difficult for us to upgrade. I'm also not sure how easy/hard it
> > > > > would
> > > > > > >> > >> be to implement (1) or (2).
> >
> > > > > > >> > >> Any help/advice/comments much appreciated :-)
> >
> > > > > > >> > >> Cheers,
> > > > > > >> > >> Alex
> >
> > > > > > >> > >> --
> >
> > ...
> >
> > read more »
great progress so far! it's going to be a lot easier for others to
help if you do a proper clone (either on google code or bitbucket).
based on a very quick glance, i think it's the table layout that are
slowing things down. try a linear layout with a few number pickers
(see https://github.com/mrn/numberpicker to get one).
yaw
···
On Thu, Aug 18, 2011 at 03:07, Alex Little wrote:
> Sorry link to example form is: http://alexlittle.net/blog/downloads/EthioDateTest.xml
>
> A
>
> Alex Little wrote:
>> Hi all,
>>
>> I've started to develop the new widget class for the Ethiopic
>> calendar, but I'm finding that it's very slow to load when I'm using
>> it in a form, when you swipe to move on to a question using the new
>> widget, it can take 15-30 seconds or more to load the question. Other
>> question types will load in a reasonable time, so pretty sure it;s
>> something to do with how I've coded the widget rather than my phone/
>> emulator being slow. It's so slow that you think the application has
>> frozen - though I don;t get any errors logged.
>>
>> it's the first time I've done any android development, so not sure if
>> it;s something to do with how I'm using the tablelayout/buttons/
>> listeners or something else.
>>
>> I've put the code up at: http://alexlittle.net/blog/downloads/EthiopicDateWidget.java
>> - it's still under development, so I haven't yet added all the
>> functions, listeners and date saving/checking - but it's developed
>> enough to see it's slow!
>>
>> Also, here's my edited WidgetFactory class http://alexlittle.net/blog/downloads/WidgetFactory.java
>>
>> and an example form which uses the widget:
>> http://alexlittle.net/blog/downloads/EthiopicDateWidget.java
>>
>>
>> Any advice/suggestions on how I can get the widget to load more
>> quickly much appreciated,
>>
>> Cheers,
>> Alex
>> On Aug 17, 9:53 pm, Alex Little wrote:
>> > Oops... just worked out the if statement condition should be:
>> > if(fep.getQuestion().getAppearanceAttr().equals("ethiopicDate"))
>> >
>> > Instead of what I wrote below...
>> > A
>> >
>> > On Aug 17, 9:29 pm, Alex Little wrote:
>> >
>> >
>> >
>> > > Thanks Mitch - I had been trying to figure out how to specify what the
>> > > javarosa Constants.DATATYPE_ETHIOPIC value should be, but using the
>> > > appearance attribute makes sense.
>> >
>> > > So I updated the WidgetFactory to have:
>> > > case Constants.DATATYPE_DATE:
>> > > if(fep.getAppearanceHint() == "ethiopicDate"){
>> > > questionWidget = new EthiopicDateWidget(context,
>> > > fep);
>> > > } else {
>> > > questionWidget = new DateWidget(context, fep);
>> > > }
>> > > break;
>> >
>> > > and will test this out.
>> >
>> > > Thanks for everyone's quick replies! I'm a newbie to doing android
>> > > development, and it's been a while since I've done any java
>> > > development, but seem to be getting there (slowly!)
>> >
>> > > Alex
>> >
>> > > On Aug 17, 8:20 pm, Mitch Sundt wrote:
>> >
>> > > > Since it would return a Date back into JavaRosa, you would want to use the
>> > > > appearance attribute to choose to use this new date widget.
>> >
>> > > > So in the form you'd have something like
>> >
>> > > >
>> > > > ....
>> > > >
>> >
>> > > > And in WidgetFactory.java, you would use the appearance value to choose your
>> > > > widget over the DateTime widget.
>> >
>> > > > Mitch
>> >
>> > > > On Wed, Aug 17, 2011 at 12:05 PM, Alex Little wrote:
>> > > > > Thanks Yaw,
>> >
>> > > > > I would prefer to keep the option of using the Gregorian date, so
>> > > > > would prefer to create a new widget rather than adapt the existing
>> > > > > date widget - even if it's a little more work.
>> >
>> > > > > Alex
>> >
>> > > > > On Aug 17, 7:46 pm, Yaw Anokwa wrote:
>> > > > > > since you'll have to roll your own collect anyway, i'd just substitute
>> > > > > > your widget for the standard date widget and leave the form as is. if
>> > > > > > you are using 1.1.7, you'll have to change date and datetime (assuming
>> > > > > > you want date time) widgets. you'll also have to change the widget
>> > > > > > factory to call your widget instead of the default widget.
>> >
>> > > > > > On Wed, Aug 17, 2011 at 11:34, Alex Little wrote:
>> > > > > > > Just been having a look at this (creating the widget), what I don't
>> > > > > > > quite get is (after I've created my new EthiopicDateWidget class):
>> >
>> > > > > > > 1) what else I need to change in the ODKCollect code to get this
>> > > > > > > recognised as a valid form widget - is it just to add to the
>> > > > > > > WidgetFactory class - and to the JavaRosa constants too? Yaw, you
>> > > > > > > mentioned there where 3 files that need changing, assuming the two
>> > > > > > > I've mentioned are correct - which is the other?
>> > > > > > > 2) what I would need to enter as the type attribute in the form xml to
>> > > > > > > get my ODKCollect to display the right widget.
>> >
>> > > > > > > Any help much appreciated.
>> > > > > > > Cheers,
>> > > > > > > Alex
>> >
>> > > > > > > On Aug 17, 5:16 pm, Alex Little wrote:
>> > > > > > >> Thanks Michael & Yaw. I didn't know about the jodaTime library and I
>> > > > > > >> was expecting the conversion of the date on the ODKCollect client to
>> > > > > > >> be a little harder than it seems it may be.
>> >
>> > > > > > >> Will have a look as how I can create a widget and build the ODKCollect
>> > > > > > >> client with the widget enabled.
>> >
>> > > > > > >> Cheers,
>> > > > > > >> Alex
>> >
>> > > > > > >> On Aug 17, 4:05 pm, Yaw Anokwa wrote:
>> >
>> > > > > > >> > assuming you have ethiopian date/datetime widgets already created,
>> > > > > i'd
>> > > > > > >> > recommend you make these modifications in collect 1.1.7. collect the
>> > > > > > >> > ethiopian date, convert to utc, and submit that. you'd only have to
>> > > > > > >> > change three very small files.
>> >
>> > > > > > >> > collect 1.1.7 has the jodatime library already included. right now
>> > > > > we
>> > > > > > >> > write out the local gregorian time with timezone. you can, as
>> > > > > michael
>> > > > > > >> > has described, easily convert ethiopian dates to utc before you send
>> > > > > > >> > it.
>> >
>> > > > > > >> > On Wed, Aug 17, 2011 at 07:53, Michael Willekes < mikewille...@gmail.com> wrote:
>> > > > > > >> > > Alex,
>> >
>> > > > > > >> > > You mentioned you'd prefer option 3: "Store the Ethiopian date in
>> > > > > the ODK
>> > > > > > >> > > Aggregate database as-is (text string or 3 separate integer
>> > > > > fields) then
>> > > > > > >> > > regularly output this to another table doing the date conversion
>> > > > > at this
>> > > > > > >> > > point".
>> >
>> > > > > > >> > > Straightforward to do as a post-processing step using the Java
>> > > > > library Joda
>> > > > > > >> > > Time:
>> >
>> > > > > > >> > > // Create Ethiopian Chronology
>> > > > > > >> > > Chronology chron_eth =
>> >
>> > > > > EthiopicChronology.getInstance(DateTimeZone.forID("Africa/Addis_Ababa"));
>> >
>> > > > > > >> > > // Create Ethiopian Date/Time (Y, M, D, H, M, S, mS)
>> > > > > > >> > > DateTime dt_eth = new DateTime(2003, 2, 30, 0, 0, 0, 0,
>> > > > > chron_eth);
>> >
>> > > > > > >> > > // Convert to Gregorian Date/Time
>> > > > > > >> > > DateTime dt_greg =
>> > > > > dt_eth.withChronology(GregorianChronology.getInstance());
>> >
>> > > > > > >> > > System.out.println("Ethiopian Date: " +
>> > > > > > >> > > DateTimeFormat.fullDate().print(dt_eth));
>> > > > > > >> > > System.out.println("Gregorian Date: " +
>> > > > > > >> > > DateTimeFormat.fullDate().print(dt_greg));
>> >
>> > > > > > >> > > This outputs:
>> >
>> > > > > > >> > > Ethiopian Date: Tuesday, 2 30, 2003
>> > > > > > >> > > Gregorian Date: Monday, November 8, 2010
>> >
>> > > > > > >> > > Regards,
>> > > > > > >> > > Mike
>> >
>> > > > > > >> > > On Wed, Aug 17, 2011 at 10:11 AM, Alex Little < a...@alexlittle.net> wrote:
>> >
>> > > > > > >> > >> Hi all,
>> >
>> > > > > > >> > >> For our data collection project, we'll be working with community
>> > > > > > >> > >> health workers (CHWs) in Ethiopia and I'm looking for some
>> > > > > help/advice
>> > > > > > >> > >> on the best way to cope with using/storing alternate date
>> > > > > formats.
>> >
>> > > > > > >> > >> Ethiopia has it's own calendar system - using 13 months and new
>> > > > > year
>> > > > > > >> > >> starts on either Sept 11th or 12th (depending on whether it's a
>> > > > > leap
>> > > > > > >> > >> year or not, much more on wikipedia about the Ethiopian
>> > > > > > >> > >> calendar....http://en.wikipedia.org/wiki/Ethiopian_calendar) -
>> > > > > and
>> > > > > > >> > >> this system is the normal calendaring system in Ethiopia. Some of
>> > > > > the
>> > > > > > >> > >> CHWs we're working with have difficulty using the Gregorian
>> > > > > calendar
>> > > > > > >> > >> as it's not what they are used to. As we'll be collecting
>> > > > > information
>> > > > > > >> > >> regarding appointment dates, dates of birth etc, it's important
>> > > > > that
>> > > > > > >> > >> we can use a date system that is familiar and understandable to
>> > > > > the
>> > > > > > >> > >> CHWs.
>> >
>> > > > > > >> > >> On the ODK Collect end, the CHWs will be entering dates in the
>> > > > > > >> > >> Ethiopian calendar - which can include dates (dd/mm/yyyy format)
>> > > > > such
>> > > > > > >> > >> as 30/2/2003, or 3/13/2002, which would be invalid dates in the
>> > > > > > >> > >> Gregorian calendar, so we can't just use the normal database date
>> > > > > > >> > >> field with an offset.
>> >
>> > > > > > >> > >> On the other end of the system, we'll be generating reports based
>> > > > > on
>> > > > > > >> > >> the input data, for example to give a list of who is due for a
>> > > > > follow
>> > > > > > >> > >> up appointment in the next 7 days, so we'll need to do processing
>> > > > > of
>> > > > > > >> > >> the dates stored in the ODK Aggregate database.
>> >
>> > > > > > >> > >> To save possible confusion over date formats I was hoping that in
>> > > > > the
>> > > > > > >> > >> database we could store dates either as a unix timestamp or
>> > > > > julian
>> > > > > > >> > >> days - as then it's straightforward to manipulate (eg, add 7
>> > > > > days),
>> > > > > > >> > >> compare and convert these dates/times into other formats for
>> > > > > display
>> > > > > > >> > >> (eg Gregorian or Ethiopian - however we like).
>> >
>> > > > > > >> > >> I've thought about 3 possible ways we could deal with this and
>> > > > > I'd be
>> > > > > > >> > >> really interested to hear anyone else's thoughts on which may be
>> > > > > good/
>> > > > > > >> > >> bad or if there are other options available to us:
>> >
>> > > > > > >> > >> 1) Adapt ODK Collect so the date is converted to unix timestamp
>> > > > > before
>> > > > > > >> > >> it is sent from the phone
>> > > > > > >> > >> 2) Adapt ODK Aggregate to the date is converted when the form
>> > > > > arrives
>> > > > > > >> > >> at the server, but before the info is saved into the database
>> > > > > > >> > >> 3) Store the Ethiopian date in the ODK Aggregate database as-is
>> > > > > (text
>> > > > > > >> > >> string or 3 separate integer fields) then regularly output this
>> > > > > to
>> > > > > > >> > >> another table doing the date conversion at this point and using
>> > > > > this
>> > > > > > >> > >> new table to generate the reports (there's no problem with a
>> > > > > short
>> > > > > > >> > >> delay before the data is available for the reports - few hours,
>> > > > > or
>> > > > > > >> > >> even day would be fine).
>> >
>> > > > > > >> > >> At the moment my preference is for option (3) - I'd like to keep
>> > > > > the
>> > > > > > >> > >> programming/development to a minimum and would like to avoid
>> > > > > making
>> > > > > > >> > >> customisations to ODKAggreate or ODKCollect which may make it
>> > > > > > >> > >> difficult for us to upgrade. I'm also not sure how easy/hard it
>> > > > > would
>> > > > > > >> > >> be to implement (1) or (2).
>> >
>> > > > > > >> > >> Any help/advice/comments much appreciated :-)
>> >
>> > > > > > >> > >> Cheers,
>> > > > > > >> > >> Alex
>> >
>> > > > > > >> > >> --
>> >
>> > ...
>> >
>> > read more »
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
Will test out with the linear layout - I've already been playing with
moving the widget layout into an xml file rather than all the fields/
buttons being created programmatically - so this should make it much
easier to test out different layouts.
Cheers for the help/advice
Alex
···
On Aug 19, 12:18 am, Yaw Anokwa wrote:
> alex,
>
> great progress so far! it's going to be a lot easier for others to
> help if you do a proper clone (either on google code or bitbucket).
>
> based on a very quick glance, i think it's the table layout that are
> slowing things down. try a linear layout with a few number pickers
> (seehttps://github.com/mrn/numberpickerto get one).
>
> yaw
>
>
>
>
