makman2 / mp Goto Github PK

To reduce the x-differences between two points (that can get quite huge with nanosecond precision) allow to multiply with BigDecimal.
For that purpose write a BigDecimalConverter.

The current class allows not related values, but the remote module gives us data frames with equal time differences. Subclass from DataFrame and implement constructor with these parameters. Then also a file writer is possible with more efficient storage handling.

Add these files to .gitignore.

Since the text based settings store actual strings, we need to validate the information.

AsyncTask is the special designed class for this purpose. Especially the asynchrone WifiConnector functions can be replaced with it.
Big advance: AsyncTasks are cancellable! This is needed from the UI.

BigInteger brings the four overloads inside one function:
BigInteger.valueOf(long)
No need to use 4 overloads.

If BigInteger.valueOf() is considered better, remove the BigIntegerConverter module and the associated test.

The order of iteration is not the same as the elements get added. The internal hash sorting seems to be platform dependent (memory stuff etc). Need to extend the test to check just for existence of the added items^^

Create an abstraction layer class that handles complete MPDF management. The user can only create and open files via this interface.

The ChartData.setDrawValues()/DataSet.setDrawValues() function solves the problem.

All resource ID's and layouts lay directly at R.id / R.layout. They should be organized under namespaces too.

Checksums add a layer of security, but to handle them correctly is quite complicated. The data format is quite simple so it is maybe not really worth it.
So in short:

Pro:

• Check if data was corrupted
• Minimal extra file size (in concrete: 8 bytes extra, that's nothing)

Contra:

• Difficult to implement
• Writing data costs more time since checksum calculation takes place
• The format is so simple, no extra security needed.

Nearly all classes lack the capability of copying. There are two options:

1. Use copy constructors.
   • Advantage: Type-safe, no castings needed
2. clone():
   • Advantages: Java conform, works together with other components. Especially every Object has a clone-function.
   • (big) Disadvantage: Annoying implementation, involves many casts and a try-catch. Not really efficient.

Android Studion natively supports resource string translation.

The code file Settings.java contains the key names of the settings used in the PreferenceFragment.
The keys should be defined in a new strings XML file and also their defaults. Settings.java loads the resources at static constructor (or if possible in the same line as the constants get defined) and the PreferenceFragment just addresses the resources.

Implement the GUI.

Some things that are needed:

• The actual plot
• Some buttons/options to adjust viewed data
• Credits

Adjust the filter to retrieve only valid remote modules (in class tuhh.nme.mp.remote.WifiConnector)

The current format allows to place entries with a length of 4GB!!! That is definetly too much and needs to be reduced. Otherwise this would be a possible exploit.
Limitting to a short (64KB) is enough.

Needs a new activity that displays these data.

Need a class that creates the x-axis strings for MPAndroidChart.

Allows to browse saved data.

Implement DataFrame organizing classes and classes that handle data output suited for MPAndroidChart.

Implement classes to receive remote module data.
Which protocol is used and how exactly needs to be determined.

• Add app logo
• Eventually make text bigger
• Write out the authors

This is faster and has a bigger range.
The big plus: The user doesn't need to disconnect from his current WLAN and can continue browsing without reconnection delay.

We need a thread that handles all data request to the module, my plan:

1. The application requests a data bunch via putting its request on a queue. The element on the queue contains the actual request and a callback.
2. The queue is worked through until all requests are done. If all done, let the thread remain in idle state.
3. If the thread needs to process a request, it sends the request to the remote module interface (#3) and waits for response (maybe also asynchronous).
4. When respond arrives, it calls the callback in the registered request with the request result. BUT: The callbacks now are organized in a threading-pool to not blast the system with too many threads. If the module reacts fast and the thread needs to process many requests, it could possibly open too many threads (especially if the callbacks are time-consuming). I would limit the thread count to 2-4.

The good aspect behind this system is that one thread hosts the connection to the remote module. Multiple threads are difficult to realize (but would simplify the callback process).

Many routers send more than one possible WiFi connection (i.e. different frequencies because of different WLAN standards, WLAN repeaters).
Need to catch the broadcast and select the connection with the best signal strength.
If connection is not possible fall back to the least good signal.

The basic idea behind this is to allow automatically generate data from parameters.

For our specific blood pressure example:
Because we receive data-bunches where each data-piece has equal time difference, we don't need to manually save x-data. That would allow also to write a custom file writer that takes advantage of this fact.

In my opinion PressureDataFrame is a way too generic name. Since our application measures explicitly blood pressure we should call the object more appropriate (BloodPressureDataFrame).

If the device malfunctions the fragment could hang up.

So:

• Use a thread to close the connection
• If a normal close() does not finish in a specific amount of time (about 30sec), terminate() it.

This would affect the LiveDataFragment.

Automatically detect and adjust units and x-values on the axis.

The WiFi refresh menu action button shall spin until the refreshed view is shown.

This is a bit complicated since the SDK has problems with AppCompat and uses a dumb system regarding drawable rotations. Just complicated and not helpful at all.

So best way:

• Write our own RotateDrawable, where you can just set the angle (and not some awkward "level" that ranges from 0 - 10000)
• If possible embed it in XML
• Use the new drawable as icon
• Use an animator with linear interpolation that sets the angle
  • Maybe make a completely own Animator class that just needs the new RotateDrawable target. But some properties should be left open, like interpolation etc.

Place a start and stop button into the action menu so the user can manually stop and start again the data fetch.

If we render for example 1000 data points (starting from zero), we get something like:

It would be better to display the x-label "1000" itself at the right edge, but if we adjust code to get 1001 labels (so from 0 until 1000), the plot calculates even more ugly values (and there's still no 1000 at the right edge):

We should try to display the range 0 until 1000 (or any other range, but it shouldn't be cut off like this).