What do you mean when you say that the performance is not smooth? If you are running it on device, compile and run the release version of you app. There are way too many logging statements in the DPF.iOS.UITabeView.pas which would slow down the performance in the debug mode.
Also, I notice that your are populating the table on form create. If this form is being created at the app launch time, then it is likely that you app would fail to launch. iOS doesn't like apps that take too long to launch. (It will launch fine though if you run it from the Delphi.) Without making any changes, reboot your device and run the app by touching its icon on your device and see if it launches.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are using v4.2, then please download and go back to 4.1. There were some new bugs introduced in the latest version, specifically affecting UITableview. Test again with 4.1 and post your results.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I mean that touching tableview to scroll is not smooth, not app launch time.
The scroll experience is better than FM, but less than Xcode.
The demo is TableViewCustomView.dpr in Delphi iOS Native Components packet. everybody can test it.
It was complied with v4.1, not v4.2.
My iPhone is 4S, v6.1.3
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you capture the loading time of a single view in xcode, and then in delphi create a similar app and capture the loading time and post the results? This will maybe set a benchmark to try to achieve.
Also do you receive the same result if you do not use frames, but just load into the itemtext.text and skip the frames?
I would check myself, but I do not use xcode nor have i been using apple products for long enough to agree or disagree...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tyson: Johnson try to tell you, that not the launch of his application is slow, but the scrolling of a tableview with 500+ items. Otherwise I experienced the same result in my app with as low as 120 cells (iPhone 4). It's not so bad, totally usable, but a user will notice the small lags. I hope somehow it can be fixed.
Johnson: I don't have time now to investigate it, but if you could, try to modify your code to have custom draw and do not draw anything. Is it slow? Or you can try to add the 500 items to 10 sections, to test what slows it down, many items in one section, or the total item count.
Please report it. Thanks
Last edit: Fenistil 2013-09-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know its not the app thats loading slow. What i was asking is to capture the time it takes to create and load an individual tableview item into the table view.
for example
starttime
load/draw tableview item
stoptime
total time = stoptime-starttime
This would need to be done in the DPF.iOS.UITableview.pas file.
I would do it, but i don't have my mac with me. and i was just asking if he could do the same in xcode so i could see how much faster the loading is in xcode.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's ok, but I don't think the speed (or lagging) of the scrolling is based on the items' loading time. Loading <> Drawing. I think it doesn't matter how long it takes to load the items, after every item is added, the scrolling should be smooth always. Maybe something wrong with the implementation of the TableItems, but I don't have time now for it, however I also need it to be fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know that lag of scrolling only appear in the case of custom drawing.
In the table scrolling process, you can see that each item seems to have be created or redrawn once, leading to a lag.
I think the problem must be in the DPF.iOS.UITableView.pas, following function:
function TTableViewDataSourceDelegate.tableView( tableView: UITableView; cellForRowAtIndexPath: NSIndexPath ): UITableViewCell;
...
// maybe Res is nil every time, bring to lag
Res := tableView.dequeueReusableCellWithIdentifier( NSStr( CellIdentifier ) );
A lot of code I Still do not understand, more time, maybe find out the problem code.
The returned UITableViewCell object is frequently one that the application reuses for performance reasons. You should fetch a previously created cell object that is marked for reuse by sending a dequeueReusableCellWithIdentifier: message to tableView. Various attributes of a table cell are set automatically based on whether the cell is a separator and on information the data source provides, such as for accessory views and editing controls.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been working on this also, I believe the problem to be in
for I := 0 to TableItem.GetFrame.ChildrenCount - 1 do
begin
CObj := TableItem.GetFrame.Children[i];
if CObj is TDPFiOSBaseControl then
begin
C := CObj as TDPFiOSBaseControl;
C.AddThisToSubView := false;
C.Loaded;
Result.addSubview( FDPFUITableView.GetControlView( C.UIControl ) );
end;
end
This is loaded every time the applyframedata is called, this presents a tremendous amount of lag during the display. if you want to test, just go an comment this section out and run your app, the lines will be blank, but you will have smooth scrolling.
What I did was create an additional property in the TTableitem to store this loaded view during the frame assignment vs doing it while scrolling, this took away all of the lag during scrolling... 1000+ records no problem... running an iphone 3... so iphone 4 should be even faster.
There is a downside to this approach...... the overhead is shifted from the displayed cells to all upfront during the loading sequence... this is undesirable, however it did solve the scrolling issues... really smooth.
My thought initially would be to create a collection of views based on the number of rows visible (Screen height/rowheight) and create upfront as many views as required that would fit on the screen (Really talking about 20 or so), these views could then be recycled as you scroll.... this would reduce the overhead and give you smooth scrolling.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I test two demo(TableViewCustomView/TableViewCustomViewFrame), complied and put into iphone device, the experience is not good.
I also modify following code 50 to 500 to test. Implementing the same functionality with xcode, UI is very smooth.
I guess the reason, maybe is a bug about reusing TableCell.
procedure TForm3.FormCreate( Sender: TObject );
var
I: Integer;
begin
...
with DPFUITableView1.Sections.Add do
begin
end;
...
end;
What do you mean when you say that the performance is not smooth? If you are running it on device, compile and run the release version of you app. There are way too many logging statements in the DPF.iOS.UITabeView.pas which would slow down the performance in the debug mode.
Also, I notice that your are populating the table on form create. If this form is being created at the app launch time, then it is likely that you app would fail to launch. iOS doesn't like apps that take too long to launch. (It will launch fine though if you run it from the Delphi.) Without making any changes, reboot your device and run the app by touching its icon on your device and see if it launches.
If you are using v4.2, then please download and go back to 4.1. There were some new bugs introduced in the latest version, specifically affecting UITableview. Test again with 4.1 and post your results.
I mean that touching tableview to scroll is not smooth, not app launch time.
The scroll experience is better than FM, but less than Xcode.
The demo is TableViewCustomView.dpr in Delphi iOS Native Components packet. everybody can test it.
It was complied with v4.1, not v4.2.
My iPhone is 4S, v6.1.3
Can you capture the loading time of a single view in xcode, and then in delphi create a similar app and capture the loading time and post the results? This will maybe set a benchmark to try to achieve.
Also do you receive the same result if you do not use frames, but just load into the itemtext.text and skip the frames?
I would check myself, but I do not use xcode nor have i been using apple products for long enough to agree or disagree...
Tyson: Johnson try to tell you, that not the launch of his application is slow, but the scrolling of a tableview with 500+ items. Otherwise I experienced the same result in my app with as low as 120 cells (iPhone 4). It's not so bad, totally usable, but a user will notice the small lags. I hope somehow it can be fixed.
Johnson: I don't have time now to investigate it, but if you could, try to modify your code to have custom draw and do not draw anything. Is it slow? Or you can try to add the 500 items to 10 sections, to test what slows it down, many items in one section, or the total item count.
Please report it. Thanks
Last edit: Fenistil 2013-09-05
I know its not the app thats loading slow. What i was asking is to capture the time it takes to create and load an individual tableview item into the table view.
for example
starttime
load/draw tableview item
stoptime
total time = stoptime-starttime
This would need to be done in the DPF.iOS.UITableview.pas file.
I would do it, but i don't have my mac with me. and i was just asking if he could do the same in xcode so i could see how much faster the loading is in xcode.
It's ok, but I don't think the speed (or lagging) of the scrolling is based on the items' loading time. Loading <> Drawing. I think it doesn't matter how long it takes to load the items, after every item is added, the scrolling should be smooth always. Maybe something wrong with the implementation of the TableItems, but I don't have time now for it, however I also need it to be fixed.
The UITable in my app has 1200 items, doesn't have any custom draw etc. No problems at all in scrolling in debug or release build.
Same here: in my app I load more than 3000 items, no custom draw. Very smooth scrolling in debug and release.
Looking forward to a resolution for the searchbar in the current release.
Hmm, interesting. I try to test it tomorrow.
GJB: What type of iPhone and iOS version do you have?
I know that lag of scrolling only appear in the case of custom drawing.
In the table scrolling process, you can see that each item seems to have be created or redrawn once, leading to a lag.
I think the problem must be in the DPF.iOS.UITableView.pas, following function:
function TTableViewDataSourceDelegate.tableView( tableView: UITableView; cellForRowAtIndexPath: NSIndexPath ): UITableViewCell;
...
// maybe Res is nil every time, bring to lag
Res := tableView.dequeueReusableCellWithIdentifier( NSStr( CellIdentifier ) );
A lot of code I Still do not understand, more time, maybe find out the problem code.
apple ios sdk
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITableViewDataSource_Protocol/Reference/Reference.html
Discussion
The returned UITableViewCell object is frequently one that the application reuses for performance reasons. You should fetch a previously created cell object that is marked for reuse by sending a dequeueReusableCellWithIdentifier: message to tableView. Various attributes of a table cell are set automatically based on whether the cell is a separator and on information the data source provides, such as for accessory views and editing controls.
I use an iPad 4 with ios 6.1.3 and an iphone 5 with ios 6.1.4
I have been working on this also, I believe the problem to be in
This is loaded every time the applyframedata is called, this presents a tremendous amount of lag during the display. if you want to test, just go an comment this section out and run your app, the lines will be blank, but you will have smooth scrolling.
What I did was create an additional property in the TTableitem to store this loaded view during the frame assignment vs doing it while scrolling, this took away all of the lag during scrolling... 1000+ records no problem... running an iphone 3... so iphone 4 should be even faster.
There is a downside to this approach...... the overhead is shifted from the displayed cells to all upfront during the loading sequence... this is undesirable, however it did solve the scrolling issues... really smooth.
My thought initially would be to create a collection of views based on the number of rows visible (Screen height/rowheight) and create upfront as many views as required that would fit on the screen (Really talking about 20 or so), these views could then be recycled as you scroll.... this would reduce the overhead and give you smooth scrolling.
Hi,
I improved custom view performance. and will apply if to frame property.
And i will make a virtual creating instead of:
Regards
I test v4.6.2 have fixed this problem.
Thanks Babak for your hard work.