>
> ​I've got Kb:s in my LDB now and no problem so far.​ - ​I couple of years
>> ago I stumbled somewhere over a code of a simple local database, but I
>> can't find it anymore.
>>
>>
>> Less than a Mb you should be fine.
>>
>
> ​Great! - I had been wondering/worring about what would happen with the
> LBD ​growing and when the customer would be reaching the limit. I *can *check
> that it won't grow bigger than ex. 1Mb and then start sending the rest to
> the server to be stored, no problem, but it would be too easy, too dull and
> wouldn't react to devices that are getting bigger, more intelligent and
> faster for each year. - *What if I would check how long a time it takes
> to read/write a file in the LDB?* It should be possible? Measuring the
> responce time in 1/1000 secs??
>

AFAIR localStorage is limited to 5mb per domain name. subdomain excluded.
localStorage is said to be slow, but i never had too much problems with it.
Never try to deal with Mb of datas in it btw...


>
>
>> Mozilla LocalForage ?
>>
>
> ​Don't know. I'll look into it... maybe... if I haven't already found the
> solution.:)
>

It used to be a solution years ago. Splitting datas into multiple cookies
if localStorage wasn't supported for ex.
Not sure it's still revenant nowadays, localStorage is pretty well
supported.



> ​
>
>>
>> The install prompt is a new spec only available on Google Chrome. It uses
>>> a web manifest json file to do it. Then all the rest that makes a
>>> “progressive webapp” (PWA) is a set of new html5 features like service
>>> workers, push api, ...
>>> For Safari (iOS), standalone mode still exists, but you have to
>>> implement this “add to homescreen” prompt yourself.
>>>
>>
>> ​We need to find a better way - *really *easy for the user.
>>
>>
>> Chrome’s Web Manifest is the easiest way to go then. You need https for
>> that btw.
>>
>
> ​GREAT! (Yea, I found out about the neeed of SSL the hard way.)​
>


Let's Encrypt gives them for free anyway.
Hosting companies like OVH even set them by default on their shared hosting
plans btw.



> Scramblers? Are you looking for a way to minimize your JS/CSS file size or
>>> to really encrypt them?
>>>
>>
>> ​Encryption. Encyption of especially the code but also the database.
>>
>>
>> Code & data encryption is two very different things. First should rely to
>> some serverside mechanisms.
>>
>
> ​Yes, of course, code and data encryption are different things. - ​
>
> ​Google used to have http://crypto-js.googlecode.com/svn/tags/3.1.2/build/
> rollups/aes.js which I used for encrypting the LDB. I think I can find/do
> something similar and hide it (the key) as well as possible in my code.​
>

> What about Google Closure Compiler (https://developers.google.
> com/closure/compiler/?csw=1). *Any experience of that*?
>

Nope.
On first look, this looks like more as a JS Minifier than a real
obfuscator.
Which is fine, but i'm not sure this is really what you are looking for.



>
>
>> Second is something you should code. Basic way is to encrypt & decrypt
>> based on user´s credentials. This means at some point you need a login
>> screen.
>>
>
> ​*User's credentials?* - Do you mean username and password (and 40
> alfanumeric user Id which is for internal use only)​?
> *Login screen?* - Yes, I use a login screen. And the user's email address
> is also verified, since he/she with a click is able to send a report to
> his/her email address.
>


Key should be set by the user on login.
Never stored in your code. If you store the decryption key in the code,
then don't bother encrypt data.

ex: https://remi-grumeau.com/lab/cryptojs.html



>
>> Note that both will come with some performance cost.
>>
>
> ​Great you mention that. I however use the server very little. Insteda I
> use almost completely the local device.
>

I was referring to client side (local) performance :) (and at some point,
battery usage).



>
> ​I use GET when I'm checking the code and afterwards I use POST.​
>

GET comes with url encoding issues you won't have with POST. POST can also
integrate file binary (file upload) GET cannot.



>
> Thanks a million!
>
> Rune
>


You're welcome!
That's what those list are there for :)


Remi

On Sat, Jan 6, 2018 at 2:47 PM, Rune Back <[email protected]> wrote:

> Remi!
>
>> ​I've got Kb:s in my LDB now and no problem so far.​ - ​I couple of years
>> ago I stumbled somewhere over a code of a simple local database, but I
>> can't find it anymore.
>>
>>
>> Less than a Mb you should be fine.
>>
>
> ​Great! - I had been wondering/worring about what would happen with the
> LBD ​growing and when the customer would be reaching the limit. I *can *check
> that it won't grow bigger than ex. 1Mb and then start sending the rest to
> the server to be stored, no problem, but it would be too easy, too dull and
> wouldn't react to devices that are getting bigger, more intelligent and
> faster for each year. - *What if I would check how long a time it takes
> to read/write a file in the LDB?* It should be possible? Measuring the
> responce time in 1/1000 secs??
>
>
>
>> Mozilla LocalForage ?
>>
>
> ​Don't know. I'll look into it... maybe... if I haven't already found the
> solution.:)
> ​
>
>>
>> The install prompt is a new spec only available on Google Chrome. It uses
>>> a web manifest json file to do it. Then all the rest that makes a
>>> “progressive webapp” (PWA) is a set of new html5 features like service
>>> workers, push api, ...
>>> For Safari (iOS), standalone mode still exists, but you have to
>>> implement this “add to homescreen” prompt yourself.
>>>
>>
>> ​We need to find a better way - *really *easy for the user.
>>
>>
>> Chrome’s Web Manifest is the easiest way to go then. You need https for
>> that btw.
>>
>
> ​GREAT! (Yea, I found out about the neeed of SSL the hard way.)​
>
>
>
>> Scramblers? Are you looking for a way to minimize your JS/CSS file size
>>> or to really encrypt them?
>>>
>>
>> ​Encryption. Encyption of especially the code but also the database.
>>
>>
>> Code & data encryption is two very different things. First should rely to
>> some serverside mechanisms.
>>
>
> ​Yes, of course, code and data encryption are different things. - ​
>
> ​Google used to have http://crypto-js.googlecode.com/svn/tags/3.1.2/build/
> rollups/aes.js which I used for encrypting the LDB. I think I can find/do
> something similar and hide it (the key) as well as possible in my code.​
>
> What about Google Closure Compiler (https://developers.google.
> com/closure/compiler/?csw=1). *Any experience of that*?
>
>
>
>> Second is something you should code. Basic way is to encrypt & decrypt
>> based on user´s credentials. This means at some point you need a login
>> screen.
>>
>
> ​*User's credentials?* - Do you mean username and password (and 40
> alfanumeric user Id which is for internal use only)​?
> *Login screen?* - Yes, I use a login screen. And the user's email address
> is also verified, since he/she with a click is able to send a report to
> his/her email address.
>
>
>
>> Note that both will come with some performance cost.
>>
>
> ​Great you mention that. I however use the server very little. Insteda I
> use almost completely the local device.
>
>
>
>>
>> ​
>>
>>> What about eval() ? It’s pretty unpopular those days but surely doing
>>> the job.
>>> Or you can just call localStorage as an array.
>>>
>>> function init_ldb(fname){
>>>   return (fname!=“”)?localStorage[fname].toString():null;
>>> }
>>>
>>> But then, “fname” must match your localStorage object name (customers,
>>> products, jobs,...)
>>>
>>
>> ​Hmmmm... interesting...great! I'll try that.
>>
>> I handle the LDBs a strings, and then split them with ("fileEnd" in the
>> communication with the server) "postEnd" and "fieldEnd". Getting them back
>> into one string for each data file is a peace of cake.
>>
>>
>> Not sure i get it but if this works for you, fine :)
>>
>
> ​*fileEnd*, *postEnd *and *fieldEnd *are special charachters of your own
> choice, but you need to ensure that the user can't insert them even by
> mistake.
> ​​
>
>> Another question.
>> I use GET or POST in the communication between the app and the server. It
>> happens that the server points out that my URL is too long (I don't
>> remember if it is using GET or POST or both). This happens particularly
>> when I have a report (it may consist of several pages) in my app​ and want
>> to send it (via the server) to my email box. (As soon as I get the info to
>> the server I have a
>> ​ ​
>> simple
>> php script that takes care of the emailing.)
>>
>>
>> Any suggestions?
>>
>>
>> No limitations on POST except server side conf. Mostly 2mb by default
>> btw.
>> You should definitely use POST anytime.
>>
>> A GET request will hit the 2kb limitation, with other issues like special
>> chars encoding, req cache & others...
>>
>
> ​I use GET when I'm checking the code and afterwards I use POST.​
>
> Thanks a million!
>
> Rune
>
> --
> You received this message because you are subscribed to the Google Groups
> "iPhoneWebDev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/iphonewebdev.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"iPhoneWebDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/iphonewebdev.
For more options, visit https://groups.google.com/d/optout.

Reply via email to