Stream PDF to iOS

[mjsoftware]

Hi,

I'm building an app for the iPhone to receive a generated PDF (typically 49k in size) to the iPhone. 

When I compile the application in Delphi XE2, it works, and receives the PDF.  However, it doesn't work on the iPhone. 

Below is the code used to receive the PDF in a stream and tries to save to the applications sandbox document folder.   

Code:

procedure TFrmFetchPDFs.RtcResult1Return(Sender: TRtcConnection; Data,
  Result: TRtcValue);
var
theFile: TFilestream;
thefilename: String;
begin
thefilename:=Trim(ExtractFilePath(ParamStr(0)));
thefilename:=Copy(thefilename,1,length(thefilename)-23)+'/Documents/invoice.pdf';
theFile := TFileStream.Create(thefilename, fmCreate);
Try
  TheFile.CopyFrom(Result.asByteStream, 0);
Except
Showmessage('Oh dear - something went wrong with writing the invoice.pdf');
End;
thefile.Free;
End;

[D.Tkalcec (RTC)]

I can't help you with PDF or file-system related questions on iOS devices (because this isn't a job of the RTC SDK), but I can assure you that your iPhone app will receive exactly the same content as your Windows app. If this wasn't the case, then RTC iOS examples using the database wouldn't work either, since they are using the same methods for sending a ByteStream over RTC Remote functions.

Anyway ... what exactly do you mean by "doesn't work on the iPhone"? Are you getting an exception (if yes, what is the exception message and where is it being raised), or is the ByteStream size wrong (smaller/bigger than expected or empty), or something else?

Best Regards,
Danijel Tkalcec

[mjsoftware]

Hi Danijel,

Thanks for your reply.  I appreciate it is beyond the scope of your company to provide assistance with this - I was just wondering generally, if it was possible and whether any other RTC user's had tried this. 

What I'm trying to achieve is to overcome the lack of reporting/printing facilities offered in iOS at this stage, something I'm sure other Firemonkey iOS user's are likely to benefit from and require. 

I've done further investigations into this, now you've said it is feasible to receive stream's to the iOS, and it seems to be folder path that's the issue from what I can see.

If I manage to get any further I'll post back, so at least other users can benefit.

Thanks,

Martyn

[mjsoftware]

Hi,

I think I've managed to sort out the code, however when running on the iPhone 4S it takes 10 minutes to stream the 50k PDF?!.  On a Mac Book Pro i7, 8Gb and via the iPhone emulator it takes about 2 minutes +.  (This is via a wifi network link too).

I'm I trying to do the impossible here? Or are there any settings other than the default which are needed on the client or server?

Thanks

M

[D.Tkalcec (RTC)]

There are no special performance settings, but you need to use the "FMX_GUI" unit in your iOS Project. If you don't have the "FMX_GUI" unit in the uses clause, synchronization between the main thread and background threads will be unreasonably slow.

For MacOSX and Windows FireMonkey Projects, the unit to be used is "FMX.GUI".

Only for Windows projects, you shouldn't use either of these units, because synchronization between the main and background threads on Windows works through Windows messages and is handled by the Delphi VCL for Windows.

PS. There are also some FireMonkey components which are causing extreme App slow-downs, because they are continually executing paint events and using up most of the CPU, leaving very little free CPU time for the rest of your App. Basically, anything that changes state (a cursor blinking, animations, animating gauges) can affect the CPU. While this won't be a huge problem on a desktop PC with a few GHz CPU power, it will be quite noticable on a mobile device.

Best Regards,
Danijel Tkalcec

[D.Tkalcec (RTC)]

By the way ... the "FMX_GUI" unit for iOS (and the "FMX.GUI" for MacOSX) is required ONLY if you are using the TRtcHttpServer component, or if your TRtcHttpClient component has its "Blocking" or "MultiThreaded" property set to TRUE.

If you are only using a TRtcHttpClient component and you set "MultiThreaded" as well as "Blocking" to FALSE, no background threads will be created by the RTC SDK, so there will be no need for synchronization between the main and background threads.

With a TRtcHttpClient component using MultiThreaded=False and Blocking=False, you will get the highest possible transfer rate, because there will be no thread synchtonization. The down-side of using this true blocking mode is that your App will appear unresponsive to the user and the OS, so chances are high that it will get "killed" - either by the user or the OS thinking the app "froze".

Best Regards,
Danijel Tkalcec

[mjsoftware]

Thanks Danijel, I'm afraid I'd already added the FMX_GUI unit to the uses clause, and switching off blocking/multi-threaded did reduce the download time to about 5 minutes. 

I think I better think of another strategy for this.

Thanks anyway.

[D.Tkalcec (RTC)]

If nothing helps to get your transfer rate up, then you either have problems with your bandwidth (very slow connection), or there are other components flooding the CPU (probably from background threads).

With my iPhone 4S, over a 3G connection from my mobile internet provider (BASE), using the File_Client demo for iOS, it takes only 7 seconds (including the time to open a connection) to download the complete RealThinClient SDK Starter edition ZIP file from the RealThinClient.com WebServer, simply by using default settings (Blocking=False and MultiThreaded=False). And that file has 2,57 MB (2.704.003 Bytes).

To fetch the complete "FishFacts" table (including several images, total 116 KB in size) with the iosTestClient demo, it takes about 1 second using my iPhone 4S over a WiFi connection and a Server running inside LAN. You can see that in this YouTube video, which was recorded by another RTC user:
http://www.youtube.com/watch?v=LPV4fWAw69g

So ... my suggestion is to try finding out what is causing this slow-down. If it isn't your available bandwidth, make a small test app using only RTC components, a TButton and a TLabel from FireMonkey (no Memo, Gauge or other visual components) to see if it makes a difference. With such small files, over a 3G connection, it shouldn't take a lot more than 1 second to transfer a 60kb file. Also remove any code that writes the file on to a device, so you can measure pure transfer time.

Best Regards,
Danijel Tkalce