Skip navigation
Currently Being Moderated

Asynchronous File I/O on iOS seems to behave only synchronously - VERY LONG write time

Jan 18, 2013 7:50 AM

Tags: #air #flash #flex #mobile #ios #3 #actionscript #slow #builder #latency #bytearray #3.5 #asynchronous #filestream #async #writebytes #synchronous

I'm experiencing my app behaving as though any FileStream.openAsync() for writing has been opened using FileStream.open().

 

When I open a FileStream asynchronously and then writeBytes from a small ByteArray (85k), the app -halts- all other threads for WELL OVER A MINUTE until it completes the operation.

 

The halt is so complete and so disruptive, that if I change the value of a bindable String variable bound to the 'text' property of an already visible Label entity, or a bindable BitmapData variable bound to the 'source' property of an already visible Image entity, or a bindable Boolean variable bound to the 'visible' and 'includeInLayout' properties of a BusyIndicator, that none of these changes will be visible if I then immediately open a FileStream and try to write out even a tiny XML file using writeUTF()... forgive me... I don't -immediately- open the FileStream, I perform several operations to open a file entity to the ApplicationStorageDirectory, resolve a path change, test to see if it exists and if not, creates it and if so tests if it is a directory and if not, erases it and creates the directory.... and then I do the same with a second path resolution, ... i.e., lots of little calls, but even so, the updates to the visual interface don't appear until after the File I/O operations have completed....

 

It's so bad that even if I already have a BusyIndicator visible and swirling away, it HALTS the swirling!

 

If I add a simple half-second timer before the File I/O, the variable changes are reflected in the visual elements... but of course the BusyIndicator is still halted.

 

It takes 1 minute and 22 seconds to write an 85kb image to the ApplicationStorageDirectory!

 

Any help or clarification is greatly appreciated.   Even knowing if the Async running Sync is just an iOS restriction and if the long write times are as well.

 
Replies
  • Currently Being Moderated
    Jan 22, 2013 5:00 PM   in reply to Bramblethorne

    Sorry, this is not my area of knowledge.  I would recommend writing a non-Flex ActionScript-only project and see if you can reproduce the problem.  If you can, you will have to work with the AIR team.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 22, 2013 10:27 PM   in reply to Bramblethorne

    This is a Flex forum.  Writing a test app without Flex helps identify whether you have a Flex problem or simply an AIR problem.  If it is not a Flex problem and the folks on this forum can’t help you, you have the option of filing an issue with the AIR team at bugbase.adobe.com.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 23, 2013 12:47 PM   in reply to Bramblethorne

    If you are processing a lot of data, that can certainly freeze the UI.  A 640x480 image shouldn’t freeze the UI though.  You said this is only a problem on the device and not in the ‘emulator’?  Otherwise the profiler might help figure out why it is locking up.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points