7 Replies Latest reply on Jan 23, 2013 1:48 PM by Bramblethorne

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

    Bramblethorne Level 1

      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.

        • 2. Re: Asynchronous File I/O on iOS seems to behave only synchronously - VERY LONG write time
          Flex harUI Adobe Employee

          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.

          • 3. Re: Asynchronous File I/O on iOS seems to behave only synchronously - VERY LONG write time
            Bramblethorne Level 1

            I'm confused?  How would I use the Flex SDK + AIR SDK for mobile w/o flex, and why?   The functionality is part of the AIR sdk.  Am I missing something?

            • 4. Re: Asynchronous File I/O on iOS seems to behave only synchronously - VERY LONG write time
              Flex harUI Adobe Employee

              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.

              • 5. Re: Asynchronous File I/O on iOS seems to behave only synchronously - VERY LONG write time
                Bramblethorne Level 1

                I see.  If some other investigations fail me, I'll probably give that a go.  I'm so far beyond deadline (Thanksgiving) that it almost has me histerically laughing.

                 

                I'm suspecting that it's not actually the File I/O now, but the JPGEncoder that's freezing the device.  I just discovered the new-ish BmpData.encode() method, but so far, I've been completely unable to get it working even when copying and pasting the examples from the Adobe docs.  I'll likely need to start a new discussion thread.

                 

                The commented line is the copied example.  Neither work.

                 

                // bmpData.encode(new Rectangle(0,0,640,480), new flash.display.JPEGEncoderOptions(), png);

                bmpData.encode(new Rectangle(0, 0, bmpData.width, bmpData.height), new flash.display.PNGEncoderOptions(true),png);

                 

                 

                 

                ReferenceError: Error #1065: Variable flash.display::JPEGEncoderOptions is not defined.

                ReferenceError: Error #1065: Variable flash.display::PNGEncoderOptions is not defined.


                Pre-instantiating the encoder options yeilds different but no more functional results

                 

                private var pngEncoderOptions:PNGEncoderOptions = new flash.display.PNGEncoderOptions(true);

                 

                VerifyError: Error #1014: Class flash.display::PNGEncoderOptions could not be found.


                 

                This despite:

                 


                <fx:Script>


                <![CDATA[



                import flash.display.BitmapData;



                import flash.filters.BitmapFilterQuality;



                import flash.display.*;



                import flash.display.PNGEncoderOptions;



                import flash.display.JPEGEncoderOptions;

                 

                No manner of import statements, or usage of the class name or the fully qualified class name    blah = new this.that.theotherthing();  changes anything.

                 

                Going to try to write a class and do the encoding there, but I don't have much in the way of hope.  The only relevant posts I'm finding here, stackoverflow, et. al.,  has to do with classes not being declared public... as I'm not using a class....  but I'll try putting it in an external class anyways.

                • 6. Re: Asynchronous File I/O on iOS seems to behave only synchronously - VERY LONG write time
                  Flex harUI Adobe Employee

                  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.

                  • 7. Re: Asynchronous File I/O on iOS seems to behave only synchronously - VERY LONG write time
                    Bramblethorne Level 1

                    I haven't tried it in the emulator because my image source is not available in the emulator... the CameraUI or CameraRoll.  I suppose that it might have been wise to embed an image for testing purposes and use the emulator.  I cringe to say that such things usually just don't occur to me... I get so tunnel-visioned when things start getting frustrated that I lose sleep and fail to do simple trials like this).

                     

                    I have ascertained that the very long write time that prompted me to start the discussion has nothing to do with File I/O and is entirely caused by the encoder I've been using.  When I just wrote the BitmapData(s) to files as ByteArrays, the execution was near enough instantaneous.

                     

                    It was then that I discovered the encode() method that has recently been added to the BitmapData class.  I was very much hoping that this 'official' functionality would allow me to use compressed data, and all the better because it would be lossless PNG (at the cost of filesize, yes) and keep the source clean for being resized and such.  It seems not to work at all due to a compiler or linker, or some other strange error.

                     

                    I'm moving ahead with the uncompressed ByteArray because my job is in jeopardy, but I'd really very much like to see the API function as written as the next step after this prototype is complete is to begin synchronizing these assets with a server over a network connection, where every bit of bandwidth counts.

                     

                    Thanks for your help on this.    I'll be honest, I've never learned to use the profiler, and I probably should... I seem to always be putting out fires instead of learning how to build a more fireproof building.