NME SharedObject implementation proposal

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

NME SharedObject implementation proposal

Alex Liebert
Hi,

I'd like to propose an implementation of flash.net.SharedObject for NME.  Useful and a good next step towards parity with Flash.  Hugh if you approve of the design I'm also willing to try taking this on and submit a patch.  I'd identify the MAND requirements as necessary for a v1 release and OPT as nice to have in the future.

Requirements

1.1 Provide nme.net.SharedObject exposing the primary properties and methods: .data, .clear(), .getLocal(), .flush() [MAND]
1.2 Store properties written to the .data object persistently [MAND]
1.3 Adhere to the best practices of the supported OS / submission requirements of related commercial storefronts (Mac App Store, iOS App Store, Android Marketplace, and the general requirements of major download portals for windows) [MAND]
1.4 Have a consistent data format across platforms [MAND]
1.5 Write data immediately upon setting of a property of the .data object, just as Flash does (alternative: only on call to flush()) [OPT]
1.6 Implement connection to an AMF server through the remote methods of flash.net.SharedObject [OPT]

Design

/** Instantiate a SharedObject with an identifier, Req 1.1 */
var myData:SharedObject=SharedObject.getLocal("mydata");

/** Set data, Req 1.1 */
Reflect.setField(myData.data,"score",3000);

/** Save data, Req 1.1, 1.2 */
myData.flush();

trace(Reflect.field(myData.data,"score")); // '3000'

/** Clear data, Req 1.1 */
myData.clear();
trace(Reflect.field(myData.data,"score")); // null

Implementation Details

.getLocal() will look for an existing save state for the application and given ID, if not available, create it and return a SharedObject instance. [req 1.1]

upon flush(), the .data member will be encoded to a string using haxe.Serializer [req 1.4]

data will then be stored by the following methods, by platform: [req 1.3]:

Mac OS X: NSUserDefaults (<a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html#//apple_ref/occ/cl/NSUserDefaults">http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html#//apple_ref/occ/cl/NSUserDefaults)

iOS: NSUserDefaults ( "" )


Windows: CSIDL_COMMON_APPDATA - been awhile since I've done this; last I recall you're supposed to have a folder in there just for your app, but you may not have permission to create it without running as admin on windows vista or 7, so then you need to have created it first with an installer which won't be an option.  Needs further investigation, or if anyone knows more about it share here!

Linux: Not sure the rules here ?


Thanks,

Alex




--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Gamehaxe
Hi,
I am running out of time, but quickly....

I wonder how this can be merged with the yet-undefined "Application Data"  
and "Application Documents" directories.

"Application Data"

Windows:
   App Data folder/Company/package.name/

Linux:
    ~/.package.name/

Android:
    /sdcard/data/Company/package.name

iPhone:
   App/Documents/package.name ???

"Application Documents"
Windows:
    My Documents/Company

Linux:
    ~/Documents/Company ?


Not sure about some of these - just putting it out there.

Then, by default you could put the data in:
   Application Data/data.hxs

Or something like that.  What do you think?

Hugh


> Hi,
>
> I'd like to propose an implementation of flash.net.SharedObject for NME.
>  Useful and a good next step towards parity with Flash.  Hugh if you  
> approve
> of the design I'm also willing to try taking this on and submit a patch.
>  I'd identify the MAND requirements as necessary for a v1 release and  
> OPT as
> nice to have in the future.
>
> *Requirements*
>
> 1.1 Provide nme.net.SharedObject exposing the primary properties and
> methods: .data, .clear(), .getLocal(), .flush() [MAND]
> 1.2 Store properties written to the .data object persistently [MAND]
> 1.3 Adhere to the best practices of the supported OS / submission
> requirements of related commercial storefronts (Mac App Store, iOS App
> Store, Android Marketplace, and the general requirements of major  
> download
> portals for windows) [MAND]
> 1.4 Have a consistent data format across platforms [MAND]
> 1.5 Write data immediately upon setting of a property of the .data  
> object,
> just as Flash does (alternative: only on call to flush()) [OPT]
> 1.6 Implement connection to an AMF server through the remote methods of
> flash.net.SharedObject [OPT]
>
> *Design*
>
> /** Instantiate a SharedObject with an identifier, Req 1.1 */
> var myData:SharedObject=SharedObject.getLocal("mydata");
>
> /** Set data, Req 1.1 */
> Reflect.setField(myData.data,"score",3000);
>
> /** Save data, Req 1.1, 1.2 */
> myData.flush();
>
> trace(Reflect.field(myData.data,"score")); // '3000'
>
> /** Clear data, Req 1.1 */
> myData.clear();
> trace(Reflect.field(myData.data,"score")); // null
>
> *Implementation Details*
>
> .getLocal() will look for an existing save state for the application and
> given ID, if not available, create it and return a SharedObject instance.
> [req 1.1]
>
> upon flush(), the .data member will be encoded to a string using
> haxe.Serializer [req 1.4]
>
> data will then be stored by the following methods, by platform: [req  
> 1.3]:
>
> Mac OS X: NSUserDefaults (
> <a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html#//apple_ref/occ/cl/NSUserDefaults">http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html#//apple_ref/occ/cl/NSUserDefaults
> )
>
> iOS: NSUserDefaults ( "" )
>
> Android: SharedPreferences (
> http://developer.android.com/reference/android/content/SharedPreferences.html
> )
>
> Windows: CSIDL_COMMON_APPDATA - been awhile since I've done this; last I
> recall you're supposed to have a folder in there just for your app, but  
> you
> may not have permission to create it without running as admin on windows
> vista or 7, so then you need to have created it first with an installer
> which won't be an option.  Needs further investigation, or if anyone  
> knows
> more about it share here!
>
> Linux: Not sure the rules here ?
>
>
> Thanks,
>
> Alex

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Alex Liebert
Hi Hugh,

Good point- I think exposing a universal documents and app data
directory is a very good idea; since we're emulating the flash API,
I'd suggest we implement an analog to flash.filesystem.File- which has
static methods to get these paths.
(http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/filesystem/File.html)

Thinking about it from an API standpoint we are best to keep this
separate from what SharedObject uses- but use some of the above where
appropriate inside it's implementation.

I'm currently leaning towards

Windows - use the system applicationdata directory as you suggested
[will be checking later today about permission issues and whether a
non-admin can create subdirectories there in windows Vista/7] for
storing the SharedObject data.  Expose APP DATA and MY DOCUMENTS via a
separate flash.filesystem.File.applicationStorageDirectory and
flash.filesystem.File.documentsDirectory

Linux - Not sure- if apps are able to write consistently to the home
directory that works for me.

Android - not sure about what will happen with /sdcard on phones that
don't have removable storage (not all do.)  Looks like we should
expose android.context.Context.getFilesDir() and getExternalFilesDir()
for App Data / Documents, will research more
(http://developer.android.com/reference/android/content/Context.html#getExternalFilesDir(java.lang.String)
.

I think SharedObject should be thought of as small, cookie like
preferences to mimic the flash behavior, and we should use
android.content.SharedPreferences for it; it seems it would be most
consistent with what a user expects for preference settings.

iPhone - here we can also expose the Application data / documents
directory explicitly through a nme.filesystem.File.  According to the
documentation this would be NSApplicationSupportDirectory and
NSDocumentsDirectory.  The documents directory can be exposed to users
through iTunes, which is desirable for some apps;  then we can use
NSUserDefaults only for SharedObject.


What do you think?

Does it make sense to implement some of flash.filesystem.File's
methods for getting documents and app data directories into nme, then
treat sharedobject on a platform-by-platform basis as above?

Alex



On Mon, Jun 27, 2011 at 9:30 AM, Gamehaxe <[hidden email]> wrote:

> Hi,
> I am running out of time, but quickly....
>
> I wonder how this can be merged with the yet-undefined "Application Data"
> and "Application Documents" directories.
>
> "Application Data"
>
> Windows:
>  App Data folder/Company/package.name/
>
> Linux:
>   ~/.package.name/
>
> Android:
>   /sdcard/data/Company/package.name
>
> iPhone:
>  App/Documents/package.name ???
>
> "Application Documents"
> Windows:
>   My Documents/Company
>
> Linux:
>   ~/Documents/Company ?
>
>
> Not sure about some of these - just putting it out there.
>
> Then, by default you could put the data in:
>  Application Data/data.hxs
>
> Or something like that.  What do you think?
>
> Hugh
>
>
>> Hi,
>>
>> I'd like to propose an implementation of flash.net.SharedObject for NME.
>>  Useful and a good next step towards parity with Flash.  Hugh if you
>> approve
>> of the design I'm also willing to try taking this on and submit a patch.
>>  I'd identify the MAND requirements as necessary for a v1 release and OPT
>> as
>> nice to have in the future.
>>
>> *Requirements*
>>
>> 1.1 Provide nme.net.SharedObject exposing the primary properties and
>> methods: .data, .clear(), .getLocal(), .flush() [MAND]
>> 1.2 Store properties written to the .data object persistently [MAND]
>> 1.3 Adhere to the best practices of the supported OS / submission
>> requirements of related commercial storefronts (Mac App Store, iOS App
>> Store, Android Marketplace, and the general requirements of major download
>> portals for windows) [MAND]
>> 1.4 Have a consistent data format across platforms [MAND]
>> 1.5 Write data immediately upon setting of a property of the .data object,
>> just as Flash does (alternative: only on call to flush()) [OPT]
>> 1.6 Implement connection to an AMF server through the remote methods of
>> flash.net.SharedObject [OPT]
>>
>> *Design*
>>
>> /** Instantiate a SharedObject with an identifier, Req 1.1 */
>> var myData:SharedObject=SharedObject.getLocal("mydata");
>>
>> /** Set data, Req 1.1 */
>> Reflect.setField(myData.data,"score",3000);
>>
>> /** Save data, Req 1.1, 1.2 */
>> myData.flush();
>>
>> trace(Reflect.field(myData.data,"score")); // '3000'
>>
>> /** Clear data, Req 1.1 */
>> myData.clear();
>> trace(Reflect.field(myData.data,"score")); // null
>>
>> *Implementation Details*
>>
>> .getLocal() will look for an existing save state for the application and
>> given ID, if not available, create it and return a SharedObject instance.
>> [req 1.1]
>>
>> upon flush(), the .data member will be encoded to a string using
>> haxe.Serializer [req 1.4]
>>
>> data will then be stored by the following methods, by platform: [req 1.3]:
>>
>> Mac OS X: NSUserDefaults (
>>
>> <a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html#//apple_ref/occ/cl/NSUserDefaults">http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html#//apple_ref/occ/cl/NSUserDefaults
>> )
>>
>> iOS: NSUserDefaults ( "" )
>>
>> Android: SharedPreferences (
>>
>> http://developer.android.com/reference/android/content/SharedPreferences.html
>> )
>>
>> Windows: CSIDL_COMMON_APPDATA - been awhile since I've done this; last I
>> recall you're supposed to have a folder in there just for your app, but
>> you
>> may not have permission to create it without running as admin on windows
>> vista or 7, so then you need to have created it first with an installer
>> which won't be an option.  Needs further investigation, or if anyone knows
>> more about it share here!
>>
>> Linux: Not sure the rules here ?
>>
>>
>> Thanks,
>>
>> Alex
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Gamehaxe
Hi,
Yes it makes a great deal of sense.
Will also have to think about permissions for reading APP DATA.
I am thinking about a NSIS option for windows,
which could chmod a directory if required.

Hugh




> What do you think?
> Does it make sense to implement some of flash.filesystem.File's
> methods for getting documents and app data directories into nme, then
> treat sharedobject on a platform-by-platform basis as above?
> Alex

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Tarwin Stroh-Spijer
I totally agree with using SharedObject as an analogy to the way Cookies are used in browsers. Makes a lot of sense.

I'm not sure if you should completely copy the way Flash's File system works, there might be things we can improve and simply wrap back into Flash, so it's good to think about that. Maybe there's someone here who's had a lot of experience with AIR APIs and can give us some advice on the benefits and caveats of the system?

With SharedObject the advantage is you can simply store objects, serialized of course, and hopefully get them back as such. So it's a little different than cookies. Flash sets a limit to the size of these, changeable by request to the user for security, but I've found that storing super large objects in there can be a lot of work on the system and sometimes not worth it (ie it's quicker to re-load them from the net stupidly).

The problem is still in making it easy to create applications that simply use their own data, AND give users who need it complete control over the system. I think we already have that with the File APIs in Neko / CPP so why not replicate those, then have a LocalStorage (like HTML5) for Application Data stuff, and the SharedObject for cookies (preferences etc)? I think as long as it's obvious in documentation what each is intended for then it shouldn't create too much havock.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
Hi,
Yes it makes a great deal of sense.
Will also have to think about permissions for reading APP DATA.
I am thinking about a NSIS option for windows,
which could chmod a directory if required.

Hugh





What do you think?
Does it make sense to implement some of flash.filesystem.File's
methods for getting documents and app data directories into nme, then
treat sharedobject on a platform-by-platform basis as above?
Alex

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Gamehaxe
Hi,
Yes - I think SharedObject is probably good so you can port you flash
game easily - eg, local high score table.  However, with options like
"Documents", you could consider enhancing you app with something
like multiple saved games that the user can choose to manage with the
normal file system tools (eg, make a backup using windows explorer).
Possibly having "#if nme" to add some extra features.

The Adobe "AIR" API is not really a primary goal of NME as far as I can  
see.
If you need to stray outside the bounds of the web api, then you may as
well go to the NME api, rather than the AIR api.
That said, the adobe APIs are generally well thought-out (and mesh well
with the other classes), and NME could do worse than to mimic them.

Hugh

> I totally agree with using SharedObject as an analogy to the way Cookies  
> are
> used in browsers. Makes a lot of sense.
>
> I'm not sure if you should completely copy the way Flash's File system
> works, there might be things we can improve and simply wrap back into  
> Flash,
> so it's good to think about that. Maybe there's someone here who's had a  
> lot
> of experience with AIR APIs and can give us some advice on the benefits  
> and
> caveats of the system?
>
> With SharedObject the advantage is you can simply store objects,  
> serialized
> of course, and hopefully get them back as such. So it's a little  
> different
> than cookies. Flash sets a limit to the size of these, changeable by  
> request
> to the user for security, but I've found that storing super large  
> objects in
> there can be a lot of work on the system and sometimes not worth it (ie  
> it's
> quicker to re-load them from the net stupidly).
>
> The problem is still in making it easy to create applications that simply
> use their own data, AND give users who need it complete control over the
> system. I think we already have that with the File APIs in Neko / CPP so  
> why
> not replicate those, then have a LocalStorage (like HTML5) for  
> Application
> Data stuff, and the SharedObject for cookies (preferences etc)? I think  
> as
> long as it's obvious in documentation what each is intended for then it
> shouldn't create too much havock.
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: +61 3 8060 5321
> _______________________
>
>
> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>
>> Hi,
>> Yes it makes a great deal of sense.
>> Will also have to think about permissions for reading APP DATA.
>> I am thinking about a NSIS option for windows,
>> which could chmod a directory if required.
>>
>> Hugh
>>
>>
>>
>>
>>
>>  What do you think?
>>> Does it make sense to implement some of flash.filesystem.File's
>>> methods for getting documents and app data directories into nme, then
>>> treat sharedobject on a platform-by-platform basis as above?
>>> Alex
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Alex Liebert
Hey Hugh,

Been a bit slow finishing the work I started on this because things
are busy at the day job- I hope to submit a patch by this weekend.

Did some more research/looked back on some of my older code.  Here's
the deal with the ACL issue:

There's two standard paths to look at, appdata and common appdata.
The common one is shared among all users.  Pro, could have high scores
persist across users on the same computer.  Con- requires acl set on
the directory.
The 'right' answer is usually to have the installer set the ACL at the
install time (say with nsis like you suggested.)  If that does get
baked into nme maybe it should be optional though?
I'd suggest the windows code should:

see if its permitted to write to common app data.  if not, write to
user appdata.  Incidentally I think there's some compatibility stuff
in windows 7 that will try to do things like this anyway, since older
versions were a lot more lax with permissions.

Also I agree that the flash/air api is a fine model for the static
methods to get directory locations, but no good reason to implement
the rest of it (alot more verbose than haxes file io stuff anyway.)

Alex

On Tue, Jun 28, 2011 at 8:48 AM, Gamehaxe <[hidden email]> wrote:

> Hi,
> Yes - I think SharedObject is probably good so you can port you flash
> game easily - eg, local high score table.  However, with options like
> "Documents", you could consider enhancing you app with something
> like multiple saved games that the user can choose to manage with the
> normal file system tools (eg, make a backup using windows explorer).
> Possibly having "#if nme" to add some extra features.
>
> The Adobe "AIR" API is not really a primary goal of NME as far as I can see.
> If you need to stray outside the bounds of the web api, then you may as
> well go to the NME api, rather than the AIR api.
> That said, the adobe APIs are generally well thought-out (and mesh well
> with the other classes), and NME could do worse than to mimic them.
>
> Hugh
>
>> I totally agree with using SharedObject as an analogy to the way Cookies
>> are
>> used in browsers. Makes a lot of sense.
>>
>> I'm not sure if you should completely copy the way Flash's File system
>> works, there might be things we can improve and simply wrap back into
>> Flash,
>> so it's good to think about that. Maybe there's someone here who's had a
>> lot
>> of experience with AIR APIs and can give us some advice on the benefits
>> and
>> caveats of the system?
>>
>> With SharedObject the advantage is you can simply store objects,
>> serialized
>> of course, and hopefully get them back as such. So it's a little different
>> than cookies. Flash sets a limit to the size of these, changeable by
>> request
>> to the user for security, but I've found that storing super large objects
>> in
>> there can be a lot of work on the system and sometimes not worth it (ie
>> it's
>> quicker to re-load them from the net stupidly).
>>
>> The problem is still in making it easy to create applications that simply
>> use their own data, AND give users who need it complete control over the
>> system. I think we already have that with the File APIs in Neko / CPP so
>> why
>> not replicate those, then have a LocalStorage (like HTML5) for Application
>> Data stuff, and the SharedObject for cookies (preferences etc)? I think as
>> long as it's obvious in documentation what each is intended for then it
>> shouldn't create too much havock.
>>
>>
>> Tarwin Stroh-Spijer
>> _______________________
>>
>> Touch My Pixel
>> http://www.touchmypixel.com/
>> phone: +61 3 8060 5321
>> _______________________
>>
>>
>> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>>
>>> Hi,
>>> Yes it makes a great deal of sense.
>>> Will also have to think about permissions for reading APP DATA.
>>> I am thinking about a NSIS option for windows,
>>> which could chmod a directory if required.
>>>
>>> Hugh
>>>
>>>
>>>
>>>
>>>
>>>  What do you think?
>>>>
>>>> Does it make sense to implement some of flash.filesystem.File's
>>>> methods for getting documents and app data directories into nme, then
>>>> treat sharedobject on a platform-by-platform basis as above?
>>>> Alex
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Joshua Harlan Lifton
I'm in the midst of putting together a persistent cookie system
specific to my application on iOS, but I'd gladly switch over to the
proposed SharedObject implementation as soon as it's ready. For iOS,
it looks like the officially sanctioned way to handle persistent
storage is using either NSUserDefaults or CFPreferences:

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html

I can help with the iOS effort if needed. In the meantime, I'm trying
to use cpp.io.File for my persistent storage needs on iOS, but I'm
having trouble creating a file. When I do this:

var out:cpp.io.FileOutput =
cpp.io.File.write(flash.Lib.getResourcePath() +
"assets/data/myCookie.coo", false);
out.writeString("foobarbaz");
out.close();

I get this error:

Error [file_open,
/var/mobile/Applications/SOME-HEX-DIGITS/MyApp.app/assets/data/myCookie.coo]

Is this a permissions problem, or am I not properly using the file I/O
functions?

Thanks,
Josh

On Wed, Jun 29, 2011 at 9:41 PM, Alex Liebert <[hidden email]> wrote:

> Hey Hugh,
>
> Been a bit slow finishing the work I started on this because things
> are busy at the day job- I hope to submit a patch by this weekend.
>
> Did some more research/looked back on some of my older code.  Here's
> the deal with the ACL issue:
>
> There's two standard paths to look at, appdata and common appdata.
> The common one is shared among all users.  Pro, could have high scores
> persist across users on the same computer.  Con- requires acl set on
> the directory.
> The 'right' answer is usually to have the installer set the ACL at the
> install time (say with nsis like you suggested.)  If that does get
> baked into nme maybe it should be optional though?
> I'd suggest the windows code should:
>
> see if its permitted to write to common app data.  if not, write to
> user appdata.  Incidentally I think there's some compatibility stuff
> in windows 7 that will try to do things like this anyway, since older
> versions were a lot more lax with permissions.
>
> Also I agree that the flash/air api is a fine model for the static
> methods to get directory locations, but no good reason to implement
> the rest of it (alot more verbose than haxes file io stuff anyway.)
>
> Alex
>
> On Tue, Jun 28, 2011 at 8:48 AM, Gamehaxe <[hidden email]> wrote:
>> Hi,
>> Yes - I think SharedObject is probably good so you can port you flash
>> game easily - eg, local high score table.  However, with options like
>> "Documents", you could consider enhancing you app with something
>> like multiple saved games that the user can choose to manage with the
>> normal file system tools (eg, make a backup using windows explorer).
>> Possibly having "#if nme" to add some extra features.
>>
>> The Adobe "AIR" API is not really a primary goal of NME as far as I can see.
>> If you need to stray outside the bounds of the web api, then you may as
>> well go to the NME api, rather than the AIR api.
>> That said, the adobe APIs are generally well thought-out (and mesh well
>> with the other classes), and NME could do worse than to mimic them.
>>
>> Hugh
>>
>>> I totally agree with using SharedObject as an analogy to the way Cookies
>>> are
>>> used in browsers. Makes a lot of sense.
>>>
>>> I'm not sure if you should completely copy the way Flash's File system
>>> works, there might be things we can improve and simply wrap back into
>>> Flash,
>>> so it's good to think about that. Maybe there's someone here who's had a
>>> lot
>>> of experience with AIR APIs and can give us some advice on the benefits
>>> and
>>> caveats of the system?
>>>
>>> With SharedObject the advantage is you can simply store objects,
>>> serialized
>>> of course, and hopefully get them back as such. So it's a little different
>>> than cookies. Flash sets a limit to the size of these, changeable by
>>> request
>>> to the user for security, but I've found that storing super large objects
>>> in
>>> there can be a lot of work on the system and sometimes not worth it (ie
>>> it's
>>> quicker to re-load them from the net stupidly).
>>>
>>> The problem is still in making it easy to create applications that simply
>>> use their own data, AND give users who need it complete control over the
>>> system. I think we already have that with the File APIs in Neko / CPP so
>>> why
>>> not replicate those, then have a LocalStorage (like HTML5) for Application
>>> Data stuff, and the SharedObject for cookies (preferences etc)? I think as
>>> long as it's obvious in documentation what each is intended for then it
>>> shouldn't create too much havock.
>>>
>>>
>>> Tarwin Stroh-Spijer
>>> _______________________
>>>
>>> Touch My Pixel
>>> http://www.touchmypixel.com/
>>> phone: +61 3 8060 5321
>>> _______________________
>>>
>>>
>>> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>>>
>>>> Hi,
>>>> Yes it makes a great deal of sense.
>>>> Will also have to think about permissions for reading APP DATA.
>>>> I am thinking about a NSIS option for windows,
>>>> which could chmod a directory if required.
>>>>
>>>> Hugh
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  What do you think?
>>>>>
>>>>> Does it make sense to implement some of flash.filesystem.File's
>>>>> methods for getting documents and app data directories into nme, then
>>>>> treat sharedobject on a platform-by-platform basis as above?
>>>>> Alex
>>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Alex Liebert
I've already finished with Mac and iOS implementation.  Adding win and android soon- if it's useful to you sooner on iOS I can share the patch now though.

Sent from my Phone

On Jul 3, 2011, at 2:29 PM, Joshua Harlan Lifton <[hidden email]> wrote:

> I'm in the midst of putting together a persistent cookie system
> specific to my application on iOS, but I'd gladly switch over to the
> proposed SharedObject implementation as soon as it's ready. For iOS,
> it looks like the officially sanctioned way to handle persistent
> storage is using either NSUserDefaults or CFPreferences:
>
> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
> http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html
>
> I can help with the iOS effort if needed. In the meantime, I'm trying
> to use cpp.io.File for my persistent storage needs on iOS, but I'm
> having trouble creating a file. When I do this:
>
> var out:cpp.io.FileOutput =
> cpp.io.File.write(flash.Lib.getResourcePath() +
> "assets/data/myCookie.coo", false);
> out.writeString("foobarbaz");
> out.close();
>
> I get this error:
>
> Error [file_open,
> /var/mobile/Applications/SOME-HEX-DIGITS/MyApp.app/assets/data/myCookie.coo]
>
> Is this a permissions problem, or am I not properly using the file I/O
> functions?
>
> Thanks,
> Josh
>
> On Wed, Jun 29, 2011 at 9:41 PM, Alex Liebert <[hidden email]> wrote:
>> Hey Hugh,
>>
>> Been a bit slow finishing the work I started on this because things
>> are busy at the day job- I hope to submit a patch by this weekend.
>>
>> Did some more research/looked back on some of my older code.  Here's
>> the deal with the ACL issue:
>>
>> There's two standard paths to look at, appdata and common appdata.
>> The common one is shared among all users.  Pro, could have high scores
>> persist across users on the same computer.  Con- requires acl set on
>> the directory.
>> The 'right' answer is usually to have the installer set the ACL at the
>> install time (say with nsis like you suggested.)  If that does get
>> baked into nme maybe it should be optional though?
>> I'd suggest the windows code should:
>>
>> see if its permitted to write to common app data.  if not, write to
>> user appdata.  Incidentally I think there's some compatibility stuff
>> in windows 7 that will try to do things like this anyway, since older
>> versions were a lot more lax with permissions.
>>
>> Also I agree that the flash/air api is a fine model for the static
>> methods to get directory locations, but no good reason to implement
>> the rest of it (alot more verbose than haxes file io stuff anyway.)
>>
>> Alex
>>
>> On Tue, Jun 28, 2011 at 8:48 AM, Gamehaxe <[hidden email]> wrote:
>>> Hi,
>>> Yes - I think SharedObject is probably good so you can port you flash
>>> game easily - eg, local high score table.  However, with options like
>>> "Documents", you could consider enhancing you app with something
>>> like multiple saved games that the user can choose to manage with the
>>> normal file system tools (eg, make a backup using windows explorer).
>>> Possibly having "#if nme" to add some extra features.
>>>
>>> The Adobe "AIR" API is not really a primary goal of NME as far as I can see.
>>> If you need to stray outside the bounds of the web api, then you may as
>>> well go to the NME api, rather than the AIR api.
>>> That said, the adobe APIs are generally well thought-out (and mesh well
>>> with the other classes), and NME could do worse than to mimic them.
>>>
>>> Hugh
>>>
>>>> I totally agree with using SharedObject as an analogy to the way Cookies
>>>> are
>>>> used in browsers. Makes a lot of sense.
>>>>
>>>> I'm not sure if you should completely copy the way Flash's File system
>>>> works, there might be things we can improve and simply wrap back into
>>>> Flash,
>>>> so it's good to think about that. Maybe there's someone here who's had a
>>>> lot
>>>> of experience with AIR APIs and can give us some advice on the benefits
>>>> and
>>>> caveats of the system?
>>>>
>>>> With SharedObject the advantage is you can simply store objects,
>>>> serialized
>>>> of course, and hopefully get them back as such. So it's a little different
>>>> than cookies. Flash sets a limit to the size of these, changeable by
>>>> request
>>>> to the user for security, but I've found that storing super large objects
>>>> in
>>>> there can be a lot of work on the system and sometimes not worth it (ie
>>>> it's
>>>> quicker to re-load them from the net stupidly).
>>>>
>>>> The problem is still in making it easy to create applications that simply
>>>> use their own data, AND give users who need it complete control over the
>>>> system. I think we already have that with the File APIs in Neko / CPP so
>>>> why
>>>> not replicate those, then have a LocalStorage (like HTML5) for Application
>>>> Data stuff, and the SharedObject for cookies (preferences etc)? I think as
>>>> long as it's obvious in documentation what each is intended for then it
>>>> shouldn't create too much havock.
>>>>
>>>>
>>>> Tarwin Stroh-Spijer
>>>> _______________________
>>>>
>>>> Touch My Pixel
>>>> http://www.touchmypixel.com/
>>>> phone: +61 3 8060 5321
>>>> _______________________
>>>>
>>>>
>>>> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>>>>
>>>>> Hi,
>>>>> Yes it makes a great deal of sense.
>>>>> Will also have to think about permissions for reading APP DATA.
>>>>> I am thinking about a NSIS option for windows,
>>>>> which could chmod a directory if required.
>>>>>
>>>>> Hugh
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  What do you think?
>>>>>>
>>>>>> Does it make sense to implement some of flash.filesystem.File's
>>>>>> methods for getting documents and app data directories into nme, then
>>>>>> treat sharedobject on a platform-by-platform basis as above?
>>>>>> Alex
>>>>>>
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Joshua Harlan Lifton
Thanks, Alex. I could certainly put the patch to use now.

Cheers,
Josh

On Sun, Jul 3, 2011 at 9:25 PM, Alex Liebert <[hidden email]> wrote:

> I've already finished with Mac and iOS implementation.  Adding win and android soon- if it's useful to you sooner on iOS I can share the patch now though.
>
> Sent from my Phone
>
> On Jul 3, 2011, at 2:29 PM, Joshua Harlan Lifton <[hidden email]> wrote:
>
>> I'm in the midst of putting together a persistent cookie system
>> specific to my application on iOS, but I'd gladly switch over to the
>> proposed SharedObject implementation as soon as it's ready. For iOS,
>> it looks like the officially sanctioned way to handle persistent
>> storage is using either NSUserDefaults or CFPreferences:
>>
>> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
>> http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html
>>
>> I can help with the iOS effort if needed. In the meantime, I'm trying
>> to use cpp.io.File for my persistent storage needs on iOS, but I'm
>> having trouble creating a file. When I do this:
>>
>> var out:cpp.io.FileOutput =
>> cpp.io.File.write(flash.Lib.getResourcePath() +
>> "assets/data/myCookie.coo", false);
>> out.writeString("foobarbaz");
>> out.close();
>>
>> I get this error:
>>
>> Error [file_open,
>> /var/mobile/Applications/SOME-HEX-DIGITS/MyApp.app/assets/data/myCookie.coo]
>>
>> Is this a permissions problem, or am I not properly using the file I/O
>> functions?
>>
>> Thanks,
>> Josh
>>
>> On Wed, Jun 29, 2011 at 9:41 PM, Alex Liebert <[hidden email]> wrote:
>>> Hey Hugh,
>>>
>>> Been a bit slow finishing the work I started on this because things
>>> are busy at the day job- I hope to submit a patch by this weekend.
>>>
>>> Did some more research/looked back on some of my older code.  Here's
>>> the deal with the ACL issue:
>>>
>>> There's two standard paths to look at, appdata and common appdata.
>>> The common one is shared among all users.  Pro, could have high scores
>>> persist across users on the same computer.  Con- requires acl set on
>>> the directory.
>>> The 'right' answer is usually to have the installer set the ACL at the
>>> install time (say with nsis like you suggested.)  If that does get
>>> baked into nme maybe it should be optional though?
>>> I'd suggest the windows code should:
>>>
>>> see if its permitted to write to common app data.  if not, write to
>>> user appdata.  Incidentally I think there's some compatibility stuff
>>> in windows 7 that will try to do things like this anyway, since older
>>> versions were a lot more lax with permissions.
>>>
>>> Also I agree that the flash/air api is a fine model for the static
>>> methods to get directory locations, but no good reason to implement
>>> the rest of it (alot more verbose than haxes file io stuff anyway.)
>>>
>>> Alex
>>>
>>> On Tue, Jun 28, 2011 at 8:48 AM, Gamehaxe <[hidden email]> wrote:
>>>> Hi,
>>>> Yes - I think SharedObject is probably good so you can port you flash
>>>> game easily - eg, local high score table.  However, with options like
>>>> "Documents", you could consider enhancing you app with something
>>>> like multiple saved games that the user can choose to manage with the
>>>> normal file system tools (eg, make a backup using windows explorer).
>>>> Possibly having "#if nme" to add some extra features.
>>>>
>>>> The Adobe "AIR" API is not really a primary goal of NME as far as I can see.
>>>> If you need to stray outside the bounds of the web api, then you may as
>>>> well go to the NME api, rather than the AIR api.
>>>> That said, the adobe APIs are generally well thought-out (and mesh well
>>>> with the other classes), and NME could do worse than to mimic them.
>>>>
>>>> Hugh
>>>>
>>>>> I totally agree with using SharedObject as an analogy to the way Cookies
>>>>> are
>>>>> used in browsers. Makes a lot of sense.
>>>>>
>>>>> I'm not sure if you should completely copy the way Flash's File system
>>>>> works, there might be things we can improve and simply wrap back into
>>>>> Flash,
>>>>> so it's good to think about that. Maybe there's someone here who's had a
>>>>> lot
>>>>> of experience with AIR APIs and can give us some advice on the benefits
>>>>> and
>>>>> caveats of the system?
>>>>>
>>>>> With SharedObject the advantage is you can simply store objects,
>>>>> serialized
>>>>> of course, and hopefully get them back as such. So it's a little different
>>>>> than cookies. Flash sets a limit to the size of these, changeable by
>>>>> request
>>>>> to the user for security, but I've found that storing super large objects
>>>>> in
>>>>> there can be a lot of work on the system and sometimes not worth it (ie
>>>>> it's
>>>>> quicker to re-load them from the net stupidly).
>>>>>
>>>>> The problem is still in making it easy to create applications that simply
>>>>> use their own data, AND give users who need it complete control over the
>>>>> system. I think we already have that with the File APIs in Neko / CPP so
>>>>> why
>>>>> not replicate those, then have a LocalStorage (like HTML5) for Application
>>>>> Data stuff, and the SharedObject for cookies (preferences etc)? I think as
>>>>> long as it's obvious in documentation what each is intended for then it
>>>>> shouldn't create too much havock.
>>>>>
>>>>>
>>>>> Tarwin Stroh-Spijer
>>>>> _______________________
>>>>>
>>>>> Touch My Pixel
>>>>> http://www.touchmypixel.com/
>>>>> phone: +61 3 8060 5321
>>>>> _______________________
>>>>>
>>>>>
>>>>> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>>>>>
>>>>>> Hi,
>>>>>> Yes it makes a great deal of sense.
>>>>>> Will also have to think about permissions for reading APP DATA.
>>>>>> I am thinking about a NSIS option for windows,
>>>>>> which could chmod a directory if required.
>>>>>>
>>>>>> Hugh
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  What do you think?
>>>>>>>
>>>>>>> Does it make sense to implement some of flash.filesystem.File's
>>>>>>> methods for getting documents and app data directories into nme, then
>>>>>>> treat sharedobject on a platform-by-platform basis as above?
>>>>>>> Alex
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> haXe - an open source web programming language
>>>>>> http://haxe.org
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Gamehaxe
In reply to this post by Joshua Harlan Lifton
Hi,
The "resource" area is the installed area, and I don't think you
can write to it.  This should probably go in "application data" area.

Hugh

> I'm in the midst of putting together a persistent cookie system
> specific to my application on iOS, but I'd gladly switch over to the
> proposed SharedObject implementation as soon as it's ready. For iOS,
> it looks like the officially sanctioned way to handle persistent
> storage is using either NSUserDefaults or CFPreferences:
>
> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
> http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html
>
> I can help with the iOS effort if needed. In the meantime, I'm trying
> to use cpp.io.File for my persistent storage needs on iOS, but I'm
> having trouble creating a file. When I do this:
>
> var out:cpp.io.FileOutput =
> cpp.io.File.write(flash.Lib.getResourcePath() +
> "assets/data/myCookie.coo", false);
> out.writeString("foobarbaz");
> out.close();
>
> I get this error:
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Alex Liebert
In reply to this post by Joshua Harlan Lifton
Joshua,

Here's a partial diff from my mac.  Not ready for the primetime yet-
need to grab the android and windows bits from my pc- for windows i'll
use application data directory so thats a separate bit of work, we
should tie that together with the File.getApplicationData or whatever
we've talked about before.

Check this out on your local if you want, it's well for me- don't
commit though :) Off to a camping trip til tomorrow for the 4th but
going to wrap it all up after.  Maybe we can connect on this list to
sync this patch with the flash.filesystem.File /  directory get stuff
proposed.

Alex

On Sun, Jul 3, 2011 at 8:25 PM, Joshua Harlan Lifton
<[hidden email]> wrote:

> Thanks, Alex. I could certainly put the patch to use now.
>
> Cheers,
> Josh
>
> On Sun, Jul 3, 2011 at 9:25 PM, Alex Liebert <[hidden email]> wrote:
>> I've already finished with Mac and iOS implementation.  Adding win and android soon- if it's useful to you sooner on iOS I can share the patch now though.
>>
>> Sent from my Phone
>>
>> On Jul 3, 2011, at 2:29 PM, Joshua Harlan Lifton <[hidden email]> wrote:
>>
>>> I'm in the midst of putting together a persistent cookie system
>>> specific to my application on iOS, but I'd gladly switch over to the
>>> proposed SharedObject implementation as soon as it's ready. For iOS,
>>> it looks like the officially sanctioned way to handle persistent
>>> storage is using either NSUserDefaults or CFPreferences:
>>>
>>> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
>>> http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html
>>>
>>> I can help with the iOS effort if needed. In the meantime, I'm trying
>>> to use cpp.io.File for my persistent storage needs on iOS, but I'm
>>> having trouble creating a file. When I do this:
>>>
>>> var out:cpp.io.FileOutput =
>>> cpp.io.File.write(flash.Lib.getResourcePath() +
>>> "assets/data/myCookie.coo", false);
>>> out.writeString("foobarbaz");
>>> out.close();
>>>
>>> I get this error:
>>>
>>> Error [file_open,
>>> /var/mobile/Applications/SOME-HEX-DIGITS/MyApp.app/assets/data/myCookie.coo]
>>>
>>> Is this a permissions problem, or am I not properly using the file I/O
>>> functions?
>>>
>>> Thanks,
>>> Josh
>>>
>>> On Wed, Jun 29, 2011 at 9:41 PM, Alex Liebert <[hidden email]> wrote:
>>>> Hey Hugh,
>>>>
>>>> Been a bit slow finishing the work I started on this because things
>>>> are busy at the day job- I hope to submit a patch by this weekend.
>>>>
>>>> Did some more research/looked back on some of my older code.  Here's
>>>> the deal with the ACL issue:
>>>>
>>>> There's two standard paths to look at, appdata and common appdata.
>>>> The common one is shared among all users.  Pro, could have high scores
>>>> persist across users on the same computer.  Con- requires acl set on
>>>> the directory.
>>>> The 'right' answer is usually to have the installer set the ACL at the
>>>> install time (say with nsis like you suggested.)  If that does get
>>>> baked into nme maybe it should be optional though?
>>>> I'd suggest the windows code should:
>>>>
>>>> see if its permitted to write to common app data.  if not, write to
>>>> user appdata.  Incidentally I think there's some compatibility stuff
>>>> in windows 7 that will try to do things like this anyway, since older
>>>> versions were a lot more lax with permissions.
>>>>
>>>> Also I agree that the flash/air api is a fine model for the static
>>>> methods to get directory locations, but no good reason to implement
>>>> the rest of it (alot more verbose than haxes file io stuff anyway.)
>>>>
>>>> Alex
>>>>
>>>> On Tue, Jun 28, 2011 at 8:48 AM, Gamehaxe <[hidden email]> wrote:
>>>>> Hi,
>>>>> Yes - I think SharedObject is probably good so you can port you flash
>>>>> game easily - eg, local high score table.  However, with options like
>>>>> "Documents", you could consider enhancing you app with something
>>>>> like multiple saved games that the user can choose to manage with the
>>>>> normal file system tools (eg, make a backup using windows explorer).
>>>>> Possibly having "#if nme" to add some extra features.
>>>>>
>>>>> The Adobe "AIR" API is not really a primary goal of NME as far as I can see.
>>>>> If you need to stray outside the bounds of the web api, then you may as
>>>>> well go to the NME api, rather than the AIR api.
>>>>> That said, the adobe APIs are generally well thought-out (and mesh well
>>>>> with the other classes), and NME could do worse than to mimic them.
>>>>>
>>>>> Hugh
>>>>>
>>>>>> I totally agree with using SharedObject as an analogy to the way Cookies
>>>>>> are
>>>>>> used in browsers. Makes a lot of sense.
>>>>>>
>>>>>> I'm not sure if you should completely copy the way Flash's File system
>>>>>> works, there might be things we can improve and simply wrap back into
>>>>>> Flash,
>>>>>> so it's good to think about that. Maybe there's someone here who's had a
>>>>>> lot
>>>>>> of experience with AIR APIs and can give us some advice on the benefits
>>>>>> and
>>>>>> caveats of the system?
>>>>>>
>>>>>> With SharedObject the advantage is you can simply store objects,
>>>>>> serialized
>>>>>> of course, and hopefully get them back as such. So it's a little different
>>>>>> than cookies. Flash sets a limit to the size of these, changeable by
>>>>>> request
>>>>>> to the user for security, but I've found that storing super large objects
>>>>>> in
>>>>>> there can be a lot of work on the system and sometimes not worth it (ie
>>>>>> it's
>>>>>> quicker to re-load them from the net stupidly).
>>>>>>
>>>>>> The problem is still in making it easy to create applications that simply
>>>>>> use their own data, AND give users who need it complete control over the
>>>>>> system. I think we already have that with the File APIs in Neko / CPP so
>>>>>> why
>>>>>> not replicate those, then have a LocalStorage (like HTML5) for Application
>>>>>> Data stuff, and the SharedObject for cookies (preferences etc)? I think as
>>>>>> long as it's obvious in documentation what each is intended for then it
>>>>>> shouldn't create too much havock.
>>>>>>
>>>>>>
>>>>>> Tarwin Stroh-Spijer
>>>>>> _______________________
>>>>>>
>>>>>> Touch My Pixel
>>>>>> http://www.touchmypixel.com/
>>>>>> phone: +61 3 8060 5321
>>>>>> _______________________
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> Yes it makes a great deal of sense.
>>>>>>> Will also have to think about permissions for reading APP DATA.
>>>>>>> I am thinking about a NSIS option for windows,
>>>>>>> which could chmod a directory if required.
>>>>>>>
>>>>>>> Hugh
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  What do you think?
>>>>>>>>
>>>>>>>> Does it make sense to implement some of flash.filesystem.File's
>>>>>>>> methods for getting documents and app data directories into nme, then
>>>>>>>> treat sharedobject on a platform-by-platform basis as above?
>>>>>>>> Alex
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> haXe - an open source web programming language
>>>>>>> http://haxe.org
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org

so_ios_patch (1).patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Joshua Harlan Lifton
Thanks, Alex. I'll be traveling as well, but should resurface in a day
or two. Yes, let's coordinate the SharedObject and File patches.

Thanks again,
Josh

On Mon, Jul 4, 2011 at 1:44 PM, Alex Liebert <[hidden email]> wrote:

> Joshua,
>
> Here's a partial diff from my mac.  Not ready for the primetime yet-
> need to grab the android and windows bits from my pc- for windows i'll
> use application data directory so thats a separate bit of work, we
> should tie that together with the File.getApplicationData or whatever
> we've talked about before.
>
> Check this out on your local if you want, it's well for me- don't
> commit though :) Off to a camping trip til tomorrow for the 4th but
> going to wrap it all up after.  Maybe we can connect on this list to
> sync this patch with the flash.filesystem.File /  directory get stuff
> proposed.
>
> Alex
>
> On Sun, Jul 3, 2011 at 8:25 PM, Joshua Harlan Lifton
> <[hidden email]> wrote:
>> Thanks, Alex. I could certainly put the patch to use now.
>>
>> Cheers,
>> Josh
>>
>> On Sun, Jul 3, 2011 at 9:25 PM, Alex Liebert <[hidden email]> wrote:
>>> I've already finished with Mac and iOS implementation.  Adding win and android soon- if it's useful to you sooner on iOS I can share the patch now though.
>>>
>>> Sent from my Phone
>>>
>>> On Jul 3, 2011, at 2:29 PM, Joshua Harlan Lifton <[hidden email]> wrote:
>>>
>>>> I'm in the midst of putting together a persistent cookie system
>>>> specific to my application on iOS, but I'd gladly switch over to the
>>>> proposed SharedObject implementation as soon as it's ready. For iOS,
>>>> it looks like the officially sanctioned way to handle persistent
>>>> storage is using either NSUserDefaults or CFPreferences:
>>>>
>>>> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
>>>> http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html
>>>>
>>>> I can help with the iOS effort if needed. In the meantime, I'm trying
>>>> to use cpp.io.File for my persistent storage needs on iOS, but I'm
>>>> having trouble creating a file. When I do this:
>>>>
>>>> var out:cpp.io.FileOutput =
>>>> cpp.io.File.write(flash.Lib.getResourcePath() +
>>>> "assets/data/myCookie.coo", false);
>>>> out.writeString("foobarbaz");
>>>> out.close();
>>>>
>>>> I get this error:
>>>>
>>>> Error [file_open,
>>>> /var/mobile/Applications/SOME-HEX-DIGITS/MyApp.app/assets/data/myCookie.coo]
>>>>
>>>> Is this a permissions problem, or am I not properly using the file I/O
>>>> functions?
>>>>
>>>> Thanks,
>>>> Josh
>>>>
>>>> On Wed, Jun 29, 2011 at 9:41 PM, Alex Liebert <[hidden email]> wrote:
>>>>> Hey Hugh,
>>>>>
>>>>> Been a bit slow finishing the work I started on this because things
>>>>> are busy at the day job- I hope to submit a patch by this weekend.
>>>>>
>>>>> Did some more research/looked back on some of my older code.  Here's
>>>>> the deal with the ACL issue:
>>>>>
>>>>> There's two standard paths to look at, appdata and common appdata.
>>>>> The common one is shared among all users.  Pro, could have high scores
>>>>> persist across users on the same computer.  Con- requires acl set on
>>>>> the directory.
>>>>> The 'right' answer is usually to have the installer set the ACL at the
>>>>> install time (say with nsis like you suggested.)  If that does get
>>>>> baked into nme maybe it should be optional though?
>>>>> I'd suggest the windows code should:
>>>>>
>>>>> see if its permitted to write to common app data.  if not, write to
>>>>> user appdata.  Incidentally I think there's some compatibility stuff
>>>>> in windows 7 that will try to do things like this anyway, since older
>>>>> versions were a lot more lax with permissions.
>>>>>
>>>>> Also I agree that the flash/air api is a fine model for the static
>>>>> methods to get directory locations, but no good reason to implement
>>>>> the rest of it (alot more verbose than haxes file io stuff anyway.)
>>>>>
>>>>> Alex
>>>>>
>>>>> On Tue, Jun 28, 2011 at 8:48 AM, Gamehaxe <[hidden email]> wrote:
>>>>>> Hi,
>>>>>> Yes - I think SharedObject is probably good so you can port you flash
>>>>>> game easily - eg, local high score table.  However, with options like
>>>>>> "Documents", you could consider enhancing you app with something
>>>>>> like multiple saved games that the user can choose to manage with the
>>>>>> normal file system tools (eg, make a backup using windows explorer).
>>>>>> Possibly having "#if nme" to add some extra features.
>>>>>>
>>>>>> The Adobe "AIR" API is not really a primary goal of NME as far as I can see.
>>>>>> If you need to stray outside the bounds of the web api, then you may as
>>>>>> well go to the NME api, rather than the AIR api.
>>>>>> That said, the adobe APIs are generally well thought-out (and mesh well
>>>>>> with the other classes), and NME could do worse than to mimic them.
>>>>>>
>>>>>> Hugh
>>>>>>
>>>>>>> I totally agree with using SharedObject as an analogy to the way Cookies
>>>>>>> are
>>>>>>> used in browsers. Makes a lot of sense.
>>>>>>>
>>>>>>> I'm not sure if you should completely copy the way Flash's File system
>>>>>>> works, there might be things we can improve and simply wrap back into
>>>>>>> Flash,
>>>>>>> so it's good to think about that. Maybe there's someone here who's had a
>>>>>>> lot
>>>>>>> of experience with AIR APIs and can give us some advice on the benefits
>>>>>>> and
>>>>>>> caveats of the system?
>>>>>>>
>>>>>>> With SharedObject the advantage is you can simply store objects,
>>>>>>> serialized
>>>>>>> of course, and hopefully get them back as such. So it's a little different
>>>>>>> than cookies. Flash sets a limit to the size of these, changeable by
>>>>>>> request
>>>>>>> to the user for security, but I've found that storing super large objects
>>>>>>> in
>>>>>>> there can be a lot of work on the system and sometimes not worth it (ie
>>>>>>> it's
>>>>>>> quicker to re-load them from the net stupidly).
>>>>>>>
>>>>>>> The problem is still in making it easy to create applications that simply
>>>>>>> use their own data, AND give users who need it complete control over the
>>>>>>> system. I think we already have that with the File APIs in Neko / CPP so
>>>>>>> why
>>>>>>> not replicate those, then have a LocalStorage (like HTML5) for Application
>>>>>>> Data stuff, and the SharedObject for cookies (preferences etc)? I think as
>>>>>>> long as it's obvious in documentation what each is intended for then it
>>>>>>> shouldn't create too much havock.
>>>>>>>
>>>>>>>
>>>>>>> Tarwin Stroh-Spijer
>>>>>>> _______________________
>>>>>>>
>>>>>>> Touch My Pixel
>>>>>>> http://www.touchmypixel.com/
>>>>>>> phone: +61 3 8060 5321
>>>>>>> _______________________
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> Yes it makes a great deal of sense.
>>>>>>>> Will also have to think about permissions for reading APP DATA.
>>>>>>>> I am thinking about a NSIS option for windows,
>>>>>>>> which could chmod a directory if required.
>>>>>>>>
>>>>>>>> Hugh
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  What do you think?
>>>>>>>>>
>>>>>>>>> Does it make sense to implement some of flash.filesystem.File's
>>>>>>>>> methods for getting documents and app data directories into nme, then
>>>>>>>>> treat sharedobject on a platform-by-platform basis as above?
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> haXe - an open source web programming language
>>>>>>>> http://haxe.org
>>>>>>
>>>>>> --
>>>>>> haXe - an open source web programming language
>>>>>> http://haxe.org
>>>>>>
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Alex Liebert
I've just committed SharedObject for android and ios to trunk.  feel
free to give it a whirl!

On Mon, Jul 4, 2011 at 7:07 PM, Joshua Harlan Lifton
<[hidden email]> wrote:

> Thanks, Alex. I'll be traveling as well, but should resurface in a day
> or two. Yes, let's coordinate the SharedObject and File patches.
>
> Thanks again,
> Josh
>
> On Mon, Jul 4, 2011 at 1:44 PM, Alex Liebert <[hidden email]> wrote:
>> Joshua,
>>
>> Here's a partial diff from my mac.  Not ready for the primetime yet-
>> need to grab the android and windows bits from my pc- for windows i'll
>> use application data directory so thats a separate bit of work, we
>> should tie that together with the File.getApplicationData or whatever
>> we've talked about before.
>>
>> Check this out on your local if you want, it's well for me- don't
>> commit though :) Off to a camping trip til tomorrow for the 4th but
>> going to wrap it all up after.  Maybe we can connect on this list to
>> sync this patch with the flash.filesystem.File /  directory get stuff
>> proposed.
>>
>> Alex
>>
>> On Sun, Jul 3, 2011 at 8:25 PM, Joshua Harlan Lifton
>> <[hidden email]> wrote:
>>> Thanks, Alex. I could certainly put the patch to use now.
>>>
>>> Cheers,
>>> Josh
>>>
>>> On Sun, Jul 3, 2011 at 9:25 PM, Alex Liebert <[hidden email]> wrote:
>>>> I've already finished with Mac and iOS implementation.  Adding win and android soon- if it's useful to you sooner on iOS I can share the patch now though.
>>>>
>>>> Sent from my Phone
>>>>
>>>> On Jul 3, 2011, at 2:29 PM, Joshua Harlan Lifton <[hidden email]> wrote:
>>>>
>>>>> I'm in the midst of putting together a persistent cookie system
>>>>> specific to my application on iOS, but I'd gladly switch over to the
>>>>> proposed SharedObject implementation as soon as it's ready. For iOS,
>>>>> it looks like the officially sanctioned way to handle persistent
>>>>> storage is using either NSUserDefaults or CFPreferences:
>>>>>
>>>>> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
>>>>> http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html
>>>>>
>>>>> I can help with the iOS effort if needed. In the meantime, I'm trying
>>>>> to use cpp.io.File for my persistent storage needs on iOS, but I'm
>>>>> having trouble creating a file. When I do this:
>>>>>
>>>>> var out:cpp.io.FileOutput =
>>>>> cpp.io.File.write(flash.Lib.getResourcePath() +
>>>>> "assets/data/myCookie.coo", false);
>>>>> out.writeString("foobarbaz");
>>>>> out.close();
>>>>>
>>>>> I get this error:
>>>>>
>>>>> Error [file_open,
>>>>> /var/mobile/Applications/SOME-HEX-DIGITS/MyApp.app/assets/data/myCookie.coo]
>>>>>
>>>>> Is this a permissions problem, or am I not properly using the file I/O
>>>>> functions?
>>>>>
>>>>> Thanks,
>>>>> Josh
>>>>>
>>>>> On Wed, Jun 29, 2011 at 9:41 PM, Alex Liebert <[hidden email]> wrote:
>>>>>> Hey Hugh,
>>>>>>
>>>>>> Been a bit slow finishing the work I started on this because things
>>>>>> are busy at the day job- I hope to submit a patch by this weekend.
>>>>>>
>>>>>> Did some more research/looked back on some of my older code.  Here's
>>>>>> the deal with the ACL issue:
>>>>>>
>>>>>> There's two standard paths to look at, appdata and common appdata.
>>>>>> The common one is shared among all users.  Pro, could have high scores
>>>>>> persist across users on the same computer.  Con- requires acl set on
>>>>>> the directory.
>>>>>> The 'right' answer is usually to have the installer set the ACL at the
>>>>>> install time (say with nsis like you suggested.)  If that does get
>>>>>> baked into nme maybe it should be optional though?
>>>>>> I'd suggest the windows code should:
>>>>>>
>>>>>> see if its permitted to write to common app data.  if not, write to
>>>>>> user appdata.  Incidentally I think there's some compatibility stuff
>>>>>> in windows 7 that will try to do things like this anyway, since older
>>>>>> versions were a lot more lax with permissions.
>>>>>>
>>>>>> Also I agree that the flash/air api is a fine model for the static
>>>>>> methods to get directory locations, but no good reason to implement
>>>>>> the rest of it (alot more verbose than haxes file io stuff anyway.)
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> On Tue, Jun 28, 2011 at 8:48 AM, Gamehaxe <[hidden email]> wrote:
>>>>>>> Hi,
>>>>>>> Yes - I think SharedObject is probably good so you can port you flash
>>>>>>> game easily - eg, local high score table.  However, with options like
>>>>>>> "Documents", you could consider enhancing you app with something
>>>>>>> like multiple saved games that the user can choose to manage with the
>>>>>>> normal file system tools (eg, make a backup using windows explorer).
>>>>>>> Possibly having "#if nme" to add some extra features.
>>>>>>>
>>>>>>> The Adobe "AIR" API is not really a primary goal of NME as far as I can see.
>>>>>>> If you need to stray outside the bounds of the web api, then you may as
>>>>>>> well go to the NME api, rather than the AIR api.
>>>>>>> That said, the adobe APIs are generally well thought-out (and mesh well
>>>>>>> with the other classes), and NME could do worse than to mimic them.
>>>>>>>
>>>>>>> Hugh
>>>>>>>
>>>>>>>> I totally agree with using SharedObject as an analogy to the way Cookies
>>>>>>>> are
>>>>>>>> used in browsers. Makes a lot of sense.
>>>>>>>>
>>>>>>>> I'm not sure if you should completely copy the way Flash's File system
>>>>>>>> works, there might be things we can improve and simply wrap back into
>>>>>>>> Flash,
>>>>>>>> so it's good to think about that. Maybe there's someone here who's had a
>>>>>>>> lot
>>>>>>>> of experience with AIR APIs and can give us some advice on the benefits
>>>>>>>> and
>>>>>>>> caveats of the system?
>>>>>>>>
>>>>>>>> With SharedObject the advantage is you can simply store objects,
>>>>>>>> serialized
>>>>>>>> of course, and hopefully get them back as such. So it's a little different
>>>>>>>> than cookies. Flash sets a limit to the size of these, changeable by
>>>>>>>> request
>>>>>>>> to the user for security, but I've found that storing super large objects
>>>>>>>> in
>>>>>>>> there can be a lot of work on the system and sometimes not worth it (ie
>>>>>>>> it's
>>>>>>>> quicker to re-load them from the net stupidly).
>>>>>>>>
>>>>>>>> The problem is still in making it easy to create applications that simply
>>>>>>>> use their own data, AND give users who need it complete control over the
>>>>>>>> system. I think we already have that with the File APIs in Neko / CPP so
>>>>>>>> why
>>>>>>>> not replicate those, then have a LocalStorage (like HTML5) for Application
>>>>>>>> Data stuff, and the SharedObject for cookies (preferences etc)? I think as
>>>>>>>> long as it's obvious in documentation what each is intended for then it
>>>>>>>> shouldn't create too much havock.
>>>>>>>>
>>>>>>>>
>>>>>>>> Tarwin Stroh-Spijer
>>>>>>>> _______________________
>>>>>>>>
>>>>>>>> Touch My Pixel
>>>>>>>> http://www.touchmypixel.com/
>>>>>>>> phone: +61 3 8060 5321
>>>>>>>> _______________________
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> Yes it makes a great deal of sense.
>>>>>>>>> Will also have to think about permissions for reading APP DATA.
>>>>>>>>> I am thinking about a NSIS option for windows,
>>>>>>>>> which could chmod a directory if required.
>>>>>>>>>
>>>>>>>>> Hugh
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  What do you think?
>>>>>>>>>>
>>>>>>>>>> Does it make sense to implement some of flash.filesystem.File's
>>>>>>>>>> methods for getting documents and app data directories into nme, then
>>>>>>>>>> treat sharedobject on a platform-by-platform basis as above?
>>>>>>>>>> Alex
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> haXe - an open source web programming language
>>>>>>>>> http://haxe.org
>>>>>>>
>>>>>>> --
>>>>>>> haXe - an open source web programming language
>>>>>>> http://haxe.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> haXe - an open source web programming language
>>>>>> http://haxe.org
>>>>>>
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Joshua Harlan Lifton
Hi Alex,

I'm using SharedObject on iOS to store a HTTP cookie for my app. Works
like a charm, and just when I needed it at that. Thanks!

Cheers,
Josh

On Fri, Jul 8, 2011 at 9:56 PM, Alex Liebert <[hidden email]> wrote:

> I've just committed SharedObject for android and ios to trunk.  feel
> free to give it a whirl!
>
> On Mon, Jul 4, 2011 at 7:07 PM, Joshua Harlan Lifton
> <[hidden email]> wrote:
>> Thanks, Alex. I'll be traveling as well, but should resurface in a day
>> or two. Yes, let's coordinate the SharedObject and File patches.
>>
>> Thanks again,
>> Josh
>>
>> On Mon, Jul 4, 2011 at 1:44 PM, Alex Liebert <[hidden email]> wrote:
>>> Joshua,
>>>
>>> Here's a partial diff from my mac.  Not ready for the primetime yet-
>>> need to grab the android and windows bits from my pc- for windows i'll
>>> use application data directory so thats a separate bit of work, we
>>> should tie that together with the File.getApplicationData or whatever
>>> we've talked about before.
>>>
>>> Check this out on your local if you want, it's well for me- don't
>>> commit though :) Off to a camping trip til tomorrow for the 4th but
>>> going to wrap it all up after.  Maybe we can connect on this list to
>>> sync this patch with the flash.filesystem.File /  directory get stuff
>>> proposed.
>>>
>>> Alex
>>>
>>> On Sun, Jul 3, 2011 at 8:25 PM, Joshua Harlan Lifton
>>> <[hidden email]> wrote:
>>>> Thanks, Alex. I could certainly put the patch to use now.
>>>>
>>>> Cheers,
>>>> Josh
>>>>
>>>> On Sun, Jul 3, 2011 at 9:25 PM, Alex Liebert <[hidden email]> wrote:
>>>>> I've already finished with Mac and iOS implementation.  Adding win and android soon- if it's useful to you sooner on iOS I can share the patch now though.
>>>>>
>>>>> Sent from my Phone
>>>>>
>>>>> On Jul 3, 2011, at 2:29 PM, Joshua Harlan Lifton <[hidden email]> wrote:
>>>>>
>>>>>> I'm in the midst of putting together a persistent cookie system
>>>>>> specific to my application on iOS, but I'd gladly switch over to the
>>>>>> proposed SharedObject implementation as soon as it's ready. For iOS,
>>>>>> it looks like the officially sanctioned way to handle persistent
>>>>>> storage is using either NSUserDefaults or CFPreferences:
>>>>>>
>>>>>> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
>>>>>> http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html
>>>>>>
>>>>>> I can help with the iOS effort if needed. In the meantime, I'm trying
>>>>>> to use cpp.io.File for my persistent storage needs on iOS, but I'm
>>>>>> having trouble creating a file. When I do this:
>>>>>>
>>>>>> var out:cpp.io.FileOutput =
>>>>>> cpp.io.File.write(flash.Lib.getResourcePath() +
>>>>>> "assets/data/myCookie.coo", false);
>>>>>> out.writeString("foobarbaz");
>>>>>> out.close();
>>>>>>
>>>>>> I get this error:
>>>>>>
>>>>>> Error [file_open,
>>>>>> /var/mobile/Applications/SOME-HEX-DIGITS/MyApp.app/assets/data/myCookie.coo]
>>>>>>
>>>>>> Is this a permissions problem, or am I not properly using the file I/O
>>>>>> functions?
>>>>>>
>>>>>> Thanks,
>>>>>> Josh
>>>>>>
>>>>>> On Wed, Jun 29, 2011 at 9:41 PM, Alex Liebert <[hidden email]> wrote:
>>>>>>> Hey Hugh,
>>>>>>>
>>>>>>> Been a bit slow finishing the work I started on this because things
>>>>>>> are busy at the day job- I hope to submit a patch by this weekend.
>>>>>>>
>>>>>>> Did some more research/looked back on some of my older code.  Here's
>>>>>>> the deal with the ACL issue:
>>>>>>>
>>>>>>> There's two standard paths to look at, appdata and common appdata.
>>>>>>> The common one is shared among all users.  Pro, could have high scores
>>>>>>> persist across users on the same computer.  Con- requires acl set on
>>>>>>> the directory.
>>>>>>> The 'right' answer is usually to have the installer set the ACL at the
>>>>>>> install time (say with nsis like you suggested.)  If that does get
>>>>>>> baked into nme maybe it should be optional though?
>>>>>>> I'd suggest the windows code should:
>>>>>>>
>>>>>>> see if its permitted to write to common app data.  if not, write to
>>>>>>> user appdata.  Incidentally I think there's some compatibility stuff
>>>>>>> in windows 7 that will try to do things like this anyway, since older
>>>>>>> versions were a lot more lax with permissions.
>>>>>>>
>>>>>>> Also I agree that the flash/air api is a fine model for the static
>>>>>>> methods to get directory locations, but no good reason to implement
>>>>>>> the rest of it (alot more verbose than haxes file io stuff anyway.)
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> On Tue, Jun 28, 2011 at 8:48 AM, Gamehaxe <[hidden email]> wrote:
>>>>>>>> Hi,
>>>>>>>> Yes - I think SharedObject is probably good so you can port you flash
>>>>>>>> game easily - eg, local high score table.  However, with options like
>>>>>>>> "Documents", you could consider enhancing you app with something
>>>>>>>> like multiple saved games that the user can choose to manage with the
>>>>>>>> normal file system tools (eg, make a backup using windows explorer).
>>>>>>>> Possibly having "#if nme" to add some extra features.
>>>>>>>>
>>>>>>>> The Adobe "AIR" API is not really a primary goal of NME as far as I can see.
>>>>>>>> If you need to stray outside the bounds of the web api, then you may as
>>>>>>>> well go to the NME api, rather than the AIR api.
>>>>>>>> That said, the adobe APIs are generally well thought-out (and mesh well
>>>>>>>> with the other classes), and NME could do worse than to mimic them.
>>>>>>>>
>>>>>>>> Hugh
>>>>>>>>
>>>>>>>>> I totally agree with using SharedObject as an analogy to the way Cookies
>>>>>>>>> are
>>>>>>>>> used in browsers. Makes a lot of sense.
>>>>>>>>>
>>>>>>>>> I'm not sure if you should completely copy the way Flash's File system
>>>>>>>>> works, there might be things we can improve and simply wrap back into
>>>>>>>>> Flash,
>>>>>>>>> so it's good to think about that. Maybe there's someone here who's had a
>>>>>>>>> lot
>>>>>>>>> of experience with AIR APIs and can give us some advice on the benefits
>>>>>>>>> and
>>>>>>>>> caveats of the system?
>>>>>>>>>
>>>>>>>>> With SharedObject the advantage is you can simply store objects,
>>>>>>>>> serialized
>>>>>>>>> of course, and hopefully get them back as such. So it's a little different
>>>>>>>>> than cookies. Flash sets a limit to the size of these, changeable by
>>>>>>>>> request
>>>>>>>>> to the user for security, but I've found that storing super large objects
>>>>>>>>> in
>>>>>>>>> there can be a lot of work on the system and sometimes not worth it (ie
>>>>>>>>> it's
>>>>>>>>> quicker to re-load them from the net stupidly).
>>>>>>>>>
>>>>>>>>> The problem is still in making it easy to create applications that simply
>>>>>>>>> use their own data, AND give users who need it complete control over the
>>>>>>>>> system. I think we already have that with the File APIs in Neko / CPP so
>>>>>>>>> why
>>>>>>>>> not replicate those, then have a LocalStorage (like HTML5) for Application
>>>>>>>>> Data stuff, and the SharedObject for cookies (preferences etc)? I think as
>>>>>>>>> long as it's obvious in documentation what each is intended for then it
>>>>>>>>> shouldn't create too much havock.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tarwin Stroh-Spijer
>>>>>>>>> _______________________
>>>>>>>>>
>>>>>>>>> Touch My Pixel
>>>>>>>>> http://www.touchmypixel.com/
>>>>>>>>> phone: +61 3 8060 5321
>>>>>>>>> _______________________
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> Yes it makes a great deal of sense.
>>>>>>>>>> Will also have to think about permissions for reading APP DATA.
>>>>>>>>>> I am thinking about a NSIS option for windows,
>>>>>>>>>> which could chmod a directory if required.
>>>>>>>>>>
>>>>>>>>>> Hugh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  What do you think?
>>>>>>>>>>>
>>>>>>>>>>> Does it make sense to implement some of flash.filesystem.File's
>>>>>>>>>>> methods for getting documents and app data directories into nme, then
>>>>>>>>>>> treat sharedobject on a platform-by-platform basis as above?
>>>>>>>>>>> Alex
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> haXe - an open source web programming language
>>>>>>>>>> http://haxe.org
>>>>>>>>
>>>>>>>> --
>>>>>>>> haXe - an open source web programming language
>>>>>>>> http://haxe.org
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> haXe - an open source web programming language
>>>>>>> http://haxe.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> haXe - an open source web programming language
>>>>>> http://haxe.org
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME SharedObject implementation proposal

Alex Liebert
awesome, glad it helped!

Alex

On Sat, Jul 9, 2011 at 12:45 PM, Joshua Harlan Lifton
<[hidden email]> wrote:

> Hi Alex,
>
> I'm using SharedObject on iOS to store a HTTP cookie for my app. Works
> like a charm, and just when I needed it at that. Thanks!
>
> Cheers,
> Josh
>
> On Fri, Jul 8, 2011 at 9:56 PM, Alex Liebert <[hidden email]> wrote:
>> I've just committed SharedObject for android and ios to trunk.  feel
>> free to give it a whirl!
>>
>> On Mon, Jul 4, 2011 at 7:07 PM, Joshua Harlan Lifton
>> <[hidden email]> wrote:
>>> Thanks, Alex. I'll be traveling as well, but should resurface in a day
>>> or two. Yes, let's coordinate the SharedObject and File patches.
>>>
>>> Thanks again,
>>> Josh
>>>
>>> On Mon, Jul 4, 2011 at 1:44 PM, Alex Liebert <[hidden email]> wrote:
>>>> Joshua,
>>>>
>>>> Here's a partial diff from my mac.  Not ready for the primetime yet-
>>>> need to grab the android and windows bits from my pc- for windows i'll
>>>> use application data directory so thats a separate bit of work, we
>>>> should tie that together with the File.getApplicationData or whatever
>>>> we've talked about before.
>>>>
>>>> Check this out on your local if you want, it's well for me- don't
>>>> commit though :) Off to a camping trip til tomorrow for the 4th but
>>>> going to wrap it all up after.  Maybe we can connect on this list to
>>>> sync this patch with the flash.filesystem.File /  directory get stuff
>>>> proposed.
>>>>
>>>> Alex
>>>>
>>>> On Sun, Jul 3, 2011 at 8:25 PM, Joshua Harlan Lifton
>>>> <[hidden email]> wrote:
>>>>> Thanks, Alex. I could certainly put the patch to use now.
>>>>>
>>>>> Cheers,
>>>>> Josh
>>>>>
>>>>> On Sun, Jul 3, 2011 at 9:25 PM, Alex Liebert <[hidden email]> wrote:
>>>>>> I've already finished with Mac and iOS implementation.  Adding win and android soon- if it's useful to you sooner on iOS I can share the patch now though.
>>>>>>
>>>>>> Sent from my Phone
>>>>>>
>>>>>> On Jul 3, 2011, at 2:29 PM, Joshua Harlan Lifton <[hidden email]> wrote:
>>>>>>
>>>>>>> I'm in the midst of putting together a persistent cookie system
>>>>>>> specific to my application on iOS, but I'd gladly switch over to the
>>>>>>> proposed SharedObject implementation as soon as it's ready. For iOS,
>>>>>>> it looks like the officially sanctioned way to handle persistent
>>>>>>> storage is using either NSUserDefaults or CFPreferences:
>>>>>>>
>>>>>>> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
>>>>>>> http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html
>>>>>>>
>>>>>>> I can help with the iOS effort if needed. In the meantime, I'm trying
>>>>>>> to use cpp.io.File for my persistent storage needs on iOS, but I'm
>>>>>>> having trouble creating a file. When I do this:
>>>>>>>
>>>>>>> var out:cpp.io.FileOutput =
>>>>>>> cpp.io.File.write(flash.Lib.getResourcePath() +
>>>>>>> "assets/data/myCookie.coo", false);
>>>>>>> out.writeString("foobarbaz");
>>>>>>> out.close();
>>>>>>>
>>>>>>> I get this error:
>>>>>>>
>>>>>>> Error [file_open,
>>>>>>> /var/mobile/Applications/SOME-HEX-DIGITS/MyApp.app/assets/data/myCookie.coo]
>>>>>>>
>>>>>>> Is this a permissions problem, or am I not properly using the file I/O
>>>>>>> functions?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Josh
>>>>>>>
>>>>>>> On Wed, Jun 29, 2011 at 9:41 PM, Alex Liebert <[hidden email]> wrote:
>>>>>>>> Hey Hugh,
>>>>>>>>
>>>>>>>> Been a bit slow finishing the work I started on this because things
>>>>>>>> are busy at the day job- I hope to submit a patch by this weekend.
>>>>>>>>
>>>>>>>> Did some more research/looked back on some of my older code.  Here's
>>>>>>>> the deal with the ACL issue:
>>>>>>>>
>>>>>>>> There's two standard paths to look at, appdata and common appdata.
>>>>>>>> The common one is shared among all users.  Pro, could have high scores
>>>>>>>> persist across users on the same computer.  Con- requires acl set on
>>>>>>>> the directory.
>>>>>>>> The 'right' answer is usually to have the installer set the ACL at the
>>>>>>>> install time (say with nsis like you suggested.)  If that does get
>>>>>>>> baked into nme maybe it should be optional though?
>>>>>>>> I'd suggest the windows code should:
>>>>>>>>
>>>>>>>> see if its permitted to write to common app data.  if not, write to
>>>>>>>> user appdata.  Incidentally I think there's some compatibility stuff
>>>>>>>> in windows 7 that will try to do things like this anyway, since older
>>>>>>>> versions were a lot more lax with permissions.
>>>>>>>>
>>>>>>>> Also I agree that the flash/air api is a fine model for the static
>>>>>>>> methods to get directory locations, but no good reason to implement
>>>>>>>> the rest of it (alot more verbose than haxes file io stuff anyway.)
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> On Tue, Jun 28, 2011 at 8:48 AM, Gamehaxe <[hidden email]> wrote:
>>>>>>>>> Hi,
>>>>>>>>> Yes - I think SharedObject is probably good so you can port you flash
>>>>>>>>> game easily - eg, local high score table.  However, with options like
>>>>>>>>> "Documents", you could consider enhancing you app with something
>>>>>>>>> like multiple saved games that the user can choose to manage with the
>>>>>>>>> normal file system tools (eg, make a backup using windows explorer).
>>>>>>>>> Possibly having "#if nme" to add some extra features.
>>>>>>>>>
>>>>>>>>> The Adobe "AIR" API is not really a primary goal of NME as far as I can see.
>>>>>>>>> If you need to stray outside the bounds of the web api, then you may as
>>>>>>>>> well go to the NME api, rather than the AIR api.
>>>>>>>>> That said, the adobe APIs are generally well thought-out (and mesh well
>>>>>>>>> with the other classes), and NME could do worse than to mimic them.
>>>>>>>>>
>>>>>>>>> Hugh
>>>>>>>>>
>>>>>>>>>> I totally agree with using SharedObject as an analogy to the way Cookies
>>>>>>>>>> are
>>>>>>>>>> used in browsers. Makes a lot of sense.
>>>>>>>>>>
>>>>>>>>>> I'm not sure if you should completely copy the way Flash's File system
>>>>>>>>>> works, there might be things we can improve and simply wrap back into
>>>>>>>>>> Flash,
>>>>>>>>>> so it's good to think about that. Maybe there's someone here who's had a
>>>>>>>>>> lot
>>>>>>>>>> of experience with AIR APIs and can give us some advice on the benefits
>>>>>>>>>> and
>>>>>>>>>> caveats of the system?
>>>>>>>>>>
>>>>>>>>>> With SharedObject the advantage is you can simply store objects,
>>>>>>>>>> serialized
>>>>>>>>>> of course, and hopefully get them back as such. So it's a little different
>>>>>>>>>> than cookies. Flash sets a limit to the size of these, changeable by
>>>>>>>>>> request
>>>>>>>>>> to the user for security, but I've found that storing super large objects
>>>>>>>>>> in
>>>>>>>>>> there can be a lot of work on the system and sometimes not worth it (ie
>>>>>>>>>> it's
>>>>>>>>>> quicker to re-load them from the net stupidly).
>>>>>>>>>>
>>>>>>>>>> The problem is still in making it easy to create applications that simply
>>>>>>>>>> use their own data, AND give users who need it complete control over the
>>>>>>>>>> system. I think we already have that with the File APIs in Neko / CPP so
>>>>>>>>>> why
>>>>>>>>>> not replicate those, then have a LocalStorage (like HTML5) for Application
>>>>>>>>>> Data stuff, and the SharedObject for cookies (preferences etc)? I think as
>>>>>>>>>> long as it's obvious in documentation what each is intended for then it
>>>>>>>>>> shouldn't create too much havock.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Tarwin Stroh-Spijer
>>>>>>>>>> _______________________
>>>>>>>>>>
>>>>>>>>>> Touch My Pixel
>>>>>>>>>> http://www.touchmypixel.com/
>>>>>>>>>> phone: +61 3 8060 5321
>>>>>>>>>> _______________________
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Jun 28, 2011 at 10:10 AM, Gamehaxe <[hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> Yes it makes a great deal of sense.
>>>>>>>>>>> Will also have to think about permissions for reading APP DATA.
>>>>>>>>>>> I am thinking about a NSIS option for windows,
>>>>>>>>>>> which could chmod a directory if required.
>>>>>>>>>>>
>>>>>>>>>>> Hugh
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Does it make sense to implement some of flash.filesystem.File's
>>>>>>>>>>>> methods for getting documents and app data directories into nme, then
>>>>>>>>>>>> treat sharedobject on a platform-by-platform basis as above?
>>>>>>>>>>>> Alex
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> haXe - an open source web programming language
>>>>>>>>>>> http://haxe.org
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> haXe - an open source web programming language
>>>>>>>>> http://haxe.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> haXe - an open source web programming language
>>>>>>>> http://haxe.org
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> haXe - an open source web programming language
>>>>>>> http://haxe.org
>>>>>>
>>>>>> --
>>>>>> haXe - an open source web programming language
>>>>>> http://haxe.org
>>>>>>
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org