[TIMOB-24292] Rewrite Ti.App.Properties to a simpler form

GitHub Issue	n/a
Type	Improvement
Priority	Low
Status	Closed
Resolution	Won't Fix
Resolution Date	2017-02-16T09:43:22.000+0000
Affected Version/s	n/a
Fix Version/s	n/a
Components	Android, iOS, Windows, Windows phone
Labels	bloat
Reporter	Creative
Assignee	Hans Knöchel
Created	2017-01-11T12:36:56.000+0000
Updated	2018-08-02T22:20:01.000+0000

Description

Ti.App.Properties currently has a load of bloat functions which do not add anything but confusion. I suggest using a plain function like: Ti.App.Properties.set('myKey', mixedValue); Ti.App.Properties.get('myKey'); (will then return either an object/array/string/number, depending on what you've set). And discard all functions like setList, setObject, setString, getList, getObject, getString. Also instead of having Ti.App.Properties.removeAllProperties(), we should aim for a concise naming like Ti.App.Properties.clear(). We are already in the Properties namespace so no need to repeat it in any of it's functions.

Comments

Creative 2017-02-15

Simple but effective hack for your own project:

   Alloy.Globals.Properties.set = function(key, val) {
       return Ti.App.Properties.setString(key, JSON.stringify(val));
   }
   
   Alloy.Globals.Properties.get = function(key, default) {
       var val = Ti.App.Properties.getString(key);
       if(val === undefined) {
           return default;
       }
       return JSON.parse(val);
   }

Obviously this has a much better place in the SDK itself, but this does the job, and works correctly on objects, strings, numbers and booleans.

Hans Knöchel 2017-02-16

The Ti.App.Properties namespace is meant to handle types specifically, that's why the getString, getInt, getBoolean, etc. were introduced. There are no plans to change this behavior, since it would bring no functional benefit for the users, but would require a major code-rewrite to all platforms, as well as for the developers using our API's.
Creative 2017-02-16

It would bring functional benefit to the programmer. However I can see it being an issue since this likely has to do with the way it is being saved on the native side. The current setup does bring confusion to the situation though since one can do *Ti.App.Properties.getBoolean('foobar')* and *Ti.App.Properties.getString('foobar')*. I currently have no clue what happens in this case, if you save the same variable name to different types.
Eric Merriman 2018-08-02

Closing old "Won't fix" tickets. If you disagree, please reopen.

JSON Source