Forge.prefs.set & forge.prefs.get


#1

Do these only use string values, or can they accept / return JSON objects (obviously, the get would return Object and not the specific type, if so).

I suspect just strings, right?


#2

I’m fairly certain they are just strings, however the pref get and set are quite slow compared to say an in-mem options like js vars or localstorage / indexedDB.

Is there a reason to store it in prefs vs localStorage or indexedDB?

If you want to store it in prefs then just stringify the object and serialize it on the way out, however I find using localForage ( a shim that allows for localstorage, indexedDB and webSQL ) to be very easy to use


#3

Yep, that’s what I’m doing; it was a question of curiosity mostly.

I missed a parse on a retrieve value, and it gave me some seriously freaky results.

As for why prefs; simplicity. This app is stupid simple, and just need to occasionally store a couple small values.


#4

Ahh ok, if they are small values I would just use localstorage, its simpler actually then using the prefs and is persistent (as long as the total data is under 5 megs)

To store JSON you still need to stringify however and serialize on the out but its fast and works well

Not sure if you are familiar with localstorage but you can do it like so

localStorage.setItem(‘name’,'data;)

And to get the data

localStorage.getItem(‘name’)


#5

Thanks. Appreciate the response.


#6

PS… where’s that documented?


#7

What specifically, localStorage?

localstorage is actually a native JS property so no module to add


#8

Let’s back up. Yes, I know all about localStorage. That’s fine. I was looking for the documentation on trigger.io’s site about prefs only storing strings. Honestly, again, it’s a matter of completeness.

I’ve got a WAY bigger issue I’m chewing on at the moment (see my other topic about asking about a platform bug). Cases where a function parameter, for instance, could be an object or a null, and be completely valid, working with UIWebView seems to trigger infinite retries, and it’s hosing a shit ton of code I had written. I’m basically rewriting my entire app this weekend, because this behavior is new since the last time I worked on this app and updated all the modules and framework versions, etc (somewhere between 18 and 24 months ago).

I’m ready to throw it all in the shit can and start from scratch on native code.

Again.


#9

ahh ok, well with Prefs, I have only ever used it to store JSON as strings so I cant speak on it only storing string data vs say objects or arrays.

A long while back I remember speaking with Antoni about it and I seem to remember him saying its real purpose was to store basic app data, almost like a web.xml for java-apps (my take on it, not his) and it was not really the best for large data storage.

With your platform bug, again I’m not sure I’m understanding the full issue there because you do mention an incorrect function call making your loop go on for ever. That kind of makes sense because if a function is not there or the property of the method is causing your loop to not finish then your iterator never ticks up and runs forever ( could be totally missing what you are trying to do here as well )

Its a bit hard because I’m not sure of the context of the app ( can you share it? ) to see what you are trying to do with it? As you have mentioned your function can accept an ‘object’ or ‘null’ however its not clear what the issue is because you identify that the loop issue was caused by an incorrect spelling of the logging? Sorry just trying to get an overall picture of the core issue here.


#10

Do this…

for( var i=0; i<10; i++ ){
forge.logging.warning( “say a thing” );
}

Run it. Every thing is fine.

Now, to simulate a null object, simply change the line to:
forge.loggin.warning( “say a thing” );

This is a valid simulation of something being null or undefined.

Run it.

I’m getting an endless loop, and either, 1: the singular call should fail and i should still increment, or 2: the JS engine should crash out. Not iterating i is… not something I’d ever expect.


#11

So I went and built with your example and it does crash on IOS (android seems to handle this correctly)

This appears, from what I can tell to be a ‘mobile safari’’ bug because putting

console.logg(‘text’)

runs into the same issue, however, running it on safari (desktop) it works correctly. Meaning its not somthing with Forge but how mobile safari handles ‘undefined’ function calls. It would appear it want to just keep running like it puts hold on the script and never compleats.

You can see the same functionality even outside your loop. If you place just console.logg(‘text’) and run it in the simulator, you will see the page execution time never ends, it just keeps ticking up so I don’t think its a matter of the loop never finishing and more of mobile safari never passing back that the script is done.

I tried to google it a bit to see if there is any known cases of similar issues but I cant seem to find any… Strange behavior indeed.


#12

I’m glad it’s not just me, or something local here. I did all the testing I thought I reasonably could, and came up with similar conclusions. What I couldn’t find a solid way to test though was running similar code in the mobile browser and find a way to debug/monitor it to verify. I wanted to believe it was just a mobile rendering thing and not Forge.

Remember the days when code would just nicely crash and report out to the user? LOL


#13

I would say this is not Forge but mobile safari (yay apple)

For monitoring / debugging you can always use the safari debug with emulator, that will give you a nice console to see run-times / errors and similarly the chrome debug for android ( not sure if you are using them or not but that should allow you to see whats going on at least, and for deep-dive on IOS there is the ‘Console’ app that will show each event / crash report)


#14

It’s a fair belief. I believe it to be incorrect. Or partially incorrect.

I just did up a simple html page with broken JS just like in this demo code, and got the expected results (crash and stop). Using console, Safari on desktop, Safari on iPad Pro 13, and Safari on my XR all crash as one would expect. I expect they’re using WKWebView.

I can make it crash and stop as expected using WKWebView in my app. This is limited to UIWebView.

However… when I use WKWebView in my Trigger app, it renders like a bucket of ass. Even using all the inset code, and setting the inset options, etc., it just looks like ass, and some things don’t render at all.

It’s all using pretty consistent HTML5 stuff without using anything experimental. Even the old code, using the most plain-jain HTML4 and old school CSS renders funky.

I’m at a loss, and I’m seriously ready throw in the towel and do a marathon rewrite of this in Flutter or something. I dunno… this thing was supposed to have been submitted to the app store at the beginning of last week.

Or just do it in WKWebView and hand the whole mess back to the design folks to figure out and leave me entirely out of that part. But we’re a tiny shop. It’s probably better for me to spin wheels than the art & marketing people. I dunno…

I really, really hope @antoinevg can weigh in on this. :\


#15

Actually, I give up. Screw it. I’m using WKWebView, and worrying about visualizations later. I’ve wasted far too much time trying to get stuff running. Between the Java 12 -> 8 insanity, and this new problem, I’m just done. Done. DONE! Fin’. El Completo. Done. I’ve got zero more time to waste.