First version of a library that reads data from NS. #207

tzachi-dar · 2015-12-09T00:07:17Z

Any comments are welcomed.

AdrianLxM · 2015-12-09T00:51:08Z

app/src/main/java/com/eveningoutpost/dexdrip/Services/INsRestApi.java

+    );
+
+    @GET("/api/v1/entries.json?find[type][$eq]=cal")
+    Call<List<NightscoutBg>> getCal(


Should a "cal" be mapped to a "NightscoutBg"?

Probably not, should be probably called getBg.

paolorotolo · 2015-12-09T17:05:46Z

Also it seems you need to add compile 'com.squareup.okhttp:logging-interceptor:2.6.0' in build.gradle to compile. HttpLoggingInterceptor is in fact required by NsRestApiReader.

tzachi-dar · 2015-12-09T17:20:57Z

This is correct. I have done this in my private branch, will need to do it in master as well.
PaoloRotolo does the api look fine for you? after all it only allows one to get the latest readings.

paolorotolo · 2015-12-09T17:46:48Z

Yes, looks good! Can you actually make NsRestApiReader extend AsyncTask? In this way it will not block the main thread while reading from NS.

AdrianLxM · 2015-12-09T18:09:04Z

Can you actually make NsRestApiReader extend AsyncTask? In this way it will not block the main thread while reading from NS.

In the end, the library will start it's own service that will wake up every 5 minutes and will retrieve the latest data. It will then call back the app registered with the library.
If it just calls a notify event or actually pushes the data is yet to be specified.

tzachi-dar · 2015-12-09T18:59:38Z

It seems to me that the library should be reading the data from NS.
Assuming that one wants to read the data every 5 minutes is not a must. One might want to read it once a day and others might read it on other occasions.
You can see in WixelReader.timeForNextRead() that the logic for the next reading is not simple, and also differ from wifi readers to parrot and so on.

Does the approach of 5 functions that I have proposed looks fine?

AdrianLxM · 2015-12-09T19:14:35Z

The timing, when to trigger new Data should be part of the Library.
The Libre-Reader e.g. will not deliver the data every x minutes, but just when the User establishes an NFC connection.

I can write a proposal for an interface for that in the next couple of days.

tzachi-dar · 2015-12-09T20:50:06Z

Seems to me that if we want to have a java library that reads from
nightscout it should be passive and not triger calls.
The part that reads from hw sources or websites should be part of xdrip.
But fill free to create another proposal so that i can see what you mean.
בתאריך 9 בדצמ 2015 21:14,‏ "AdrianLxM" [email protected] כתב:

The timing, when to trigger new Data should be part of the Library.
The Libre-Reader e.g. will not deliver the data every x minutes, but just
when the User establishes an NFC connection.

I can write a proposal for an interface for that in the next couple of
days.

—
Reply to this email directly or view it on GitHub
#207 (comment)
.

paolorotolo · 2015-12-09T22:51:15Z

We can always implement both. Some passive methods and a service you can activate with an API.

mgranberry · 2016-01-06T04:20:52Z

app/src/main/java/com/eveningoutpost/dexdrip/Services/NsRestApiReader.java

+        // set your desired log level
+        logging.setLevel(HttpLoggingInterceptor.Level.BODY);
+
+        OkHttpClient httpClient = new OkHttpClient();  


This needs to be fed a cache to save data on mobile networks, and OkHttpClients are fairly expensive to create and will corrupt their state if multiple different OkHttpClients are using the same cache directory at the same time. We should probably create a singleton or store one already configured in the xdrip object.

For big requests this can save megabytes.

In another app I use combined gt/lte selectors and perform multiple queries in parallel using the .enqueue() method for day/hour chunks to maximize the chance that values are in the cache but still allow changes to make it through and it works very well.

Please explain:
Are you talking about caching connections? or are we talking about caching entries?

Using the same connection is very interesting. As for caching entries, this does not seem important since I read them by order, and I never read more than one entry more than once.

Handling gaps and backfills are where that approach fails. If you ever decide to add treatments for some reason it would also benefit from a modest cache.

Reusing an OkHttpClient will cause new requests to use a shared connection pool for any new requests. I believe it maintains 6 connections by default. There is a greater benefit when using HTTP/2.0 or SSL and doing multiple back-to-back requests. This code probably isn't likely to benefit much, but the REST uploader certainly would. Some things like redirects to HTTPS will benefit from reused clients and from a persistent cache.

What should the cache hold? Should it hold objects that are received from
the remote server?
If yes, how does it know if they were changed or not?

Thanks
Tzachi

On Wed, Jan 6, 2016 at 4:33 PM, Matthias Granberry <[email protected]

wrote:

In
app/src/main/java/com/eveningoutpost/dexdrip/Services/NsRestApiReader.java
#207 (comment)
:

double xDrip_sensor_confidence;

double xDrip_raw_timestamp;

}

private final static String TAG = NsRestApiReader.class.getName();

private INsRestApi CreateNsMethods(String baseUrl) {

Retrofit retrofit;

HttpLoggingInterceptor logging = new HttpLoggingInterceptor();

// set your desired log level

logging.setLevel(HttpLoggingInterceptor.Level.BODY);

OkHttpClient httpClient = new OkHttpClient();

Handling gaps and backfills are where that approach fails. If you ever
decide to add treatments for some reason it would also benefit from a
modest cache.

Reusing an OkHttpClient will cause new requests to use a shared connection
pool for any new requests. I believe it maintains 6 connections by default.
There is a greater benefit when using HTTP/2.0 or SSL and doing multiple
back-to-back requests. This code probably isn't likely to benefit much, but
the REST uploader certainly would. Some things like redirects to HTTPS will
benefit from reused clients and from a persistent cache.

—
Reply to this email directly or view it on GitHub
https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/pull/207/files#r48962549
.

one more question, how will the uploader benefit from items cache? I can
see how he can benefit from caching connections, but for objects we only
upload each object once.

Thanks
Tzachi

On Wed, Jan 6, 2016 at 4:40 PM, Tzachi Dar [email protected] wrote:

What should the cache hold? Should it hold objects that are received from
the remote server?
If yes, how does it know if they were changed or not?

Thanks
Tzachi

On Wed, Jan 6, 2016 at 4:33 PM, Matthias Granberry <
[email protected]> wrote:

In
app/src/main/java/com/eveningoutpost/dexdrip/Services/NsRestApiReader.java
#207 (comment)
:

double xDrip_sensor_confidence;

double xDrip_raw_timestamp;

}

private final static String TAG = NsRestApiReader.class.getName();

private INsRestApi CreateNsMethods(String baseUrl) {

Retrofit retrofit;

HttpLoggingInterceptor logging = new HttpLoggingInterceptor();

// set your desired log level

logging.setLevel(HttpLoggingInterceptor.Level.BODY);

OkHttpClient httpClient = new OkHttpClient();

Handling gaps and backfills are where that approach fails. If you ever
decide to add treatments for some reason it would also benefit from a
modest cache.

Reusing an OkHttpClient will cause new requests to use a shared
connection pool for any new requests. I believe it maintains 6 connections
by default. There is a greater benefit when using HTTP/2.0 or SSL and doing
multiple back-to-back requests. This code probably isn't likely to benefit
much, but the REST uploader certainly would. Some things like redirects to
HTTPS will benefit from reused clients and from a persistent cache.

—
Reply to this email directly or view it on GitHub
https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/pull/207/files#r48962549
.

I was referring to an HTTP cache. The server generates an etag header containing a checksum of the data that it calculates that it will send. The client then sends a request to the server with an If-None-Match header containing a set of etags that it believes may match the response coming from the server. When the server receives a request it will generate the response and compare it to the etags in the request If-None-Match header. If any match, the server responds with a 304 not modified response instead of sending the actual data. The client presents the cached copy as though it came over the network.

The uploader will only benefit from cached redirects and reused connections. The response cache won't be a benefit for most upload requests.

An Android app can configure the OkHttp cache like this:
okHttpClient.setCache(new Cache(context.getCacheDir()), 1024 * 1024 * 50))

50m may be overkill. 2M contains about 6m of my personal records.

mgranberry · 2016-01-06T04:34:49Z

BTW I have a WIP Nightscout client here: https://github.com/mgranberry/YADLA/tree/master/alrightypump-cloud/src/main/kotlin/com/kludgenics/alrightypump/cloud/nightscout

Read/write of entries to/from nightscout works great. Writing treatments works, but reading treatments needs a little work to handle the fact that they aren't very well-structured and may map onto more than one record type.

First version of a library that reads data from NS.

6f5f843

AdrianLxM reviewed Dec 9, 2015
View reviewed changes

mgranberry reviewed Jan 6, 2016
View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First version of a library that reads data from NS. #207

First version of a library that reads data from NS. #207

tzachi-dar commented Dec 9, 2015

AdrianLxM Dec 9, 2015

tzachi-dar Dec 9, 2015

paolorotolo commented Dec 9, 2015

tzachi-dar commented Dec 9, 2015

paolorotolo commented Dec 9, 2015

AdrianLxM commented Dec 9, 2015

tzachi-dar commented Dec 9, 2015

AdrianLxM commented Dec 9, 2015

tzachi-dar commented Dec 9, 2015

paolorotolo commented Dec 9, 2015

mgranberry Jan 6, 2016

tzachi-dar Jan 6, 2016

mgranberry Jan 6, 2016

tzachi-dar Jan 6, 2016

tzachi-dar Jan 6, 2016

mgranberry Jan 6, 2016

mgranberry commented Jan 6, 2016

First version of a library that reads data from NS. #207

Are you sure you want to change the base?

First version of a library that reads data from NS. #207

Conversation

tzachi-dar commented Dec 9, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paolorotolo commented Dec 9, 2015

tzachi-dar commented Dec 9, 2015

paolorotolo commented Dec 9, 2015

AdrianLxM commented Dec 9, 2015

tzachi-dar commented Dec 9, 2015

AdrianLxM commented Dec 9, 2015

tzachi-dar commented Dec 9, 2015

paolorotolo commented Dec 9, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mgranberry commented Jan 6, 2016