5 replies to this topic

[Tarek]

Dear all,

STV 3.4.0 has just been released. The release addresses almost all known issues with STV 3.3.0. For a detailed change log, please refer to your community downloads section.

 

This will most probably be the last update before our upcoming STV 4.0 major update.

Thank you!

[Dave Guerin]

Hi Tarek,

 

You asked for any issues with STV 3.4.x to be added to this thread, so here's a couple...

 

Firstly, a link to an example project which shows the problems:

 

https://dl.dropboxus...lectionCell.zip

 

 

Selection Cell Issues:

Add SensibleTableView.framework and STV+CoreData.framework.

Build and Run.

 

Enable Edit Mode, add a Setlist, go into the Setlist, enable Edit Mode, add a Song, go into the Song, and then go into Instruments which is a SCObjectSelectionCell, enable Edit Mode and add a number of Instruments, for example Ins0, Ins1, Ins2, Ins3, Ins4, Ins5. 

 

Then select some Instruments, Ins1, Ins2, and Ins3. Going back up correctly show then as the selected items.

 

Go back into the Instruments and move Ins4 to be above Ins0. Going back up now shows Ins0, Ins1, Ins2 as the selected items, which is incorrect.

 

Reorder the instruments back to Ins0, Ins1, Ins2, Ins3, Ins4, Ins5, and select Ins1, Ins3, and Ins5. Back up to the song to check they are the correctly selected items.

 

Now go back into Instruments and delete Ins4. Going back up causes a crash.

 

 

Note also the in the instrumentsPropertyDefinition.cellActions.willConfigure that cell.commitChangesLive is set to TRUE otherwise the selections are not persisted. The documentation says TRUE is the default but it appears to be FALSE.

 

 

 

Extra Sections Issues:

If I build using STV 3.3.0 then the logging in viewDidAppear shows that there is only ever 1 section.

 

If I build using STV 3.4.1 then the logging in viewDidAppear shows that there is now 2 sections, and section 0 always has 0 cells. Where has the extra section come from? 

 

 

 

 

STV 3.4.1 seems to have fixed the other issues I was experiencing, thank you very much for that Tarek, hopefully there could be a 3.4.2 release with fixes for these issues as well.

 

 

 

[Tarek]

Hi Dave,

 

Thank you very much for the sample, it was really helpful. All your reported issues have now been fixed in STV 3.4.2 (please confirm).

 

Regarding cell.commitChangesLive: this is not a bug. commitChangesLive indeed defaults to TRUE, but when a cell is inside an SCObjectSection in a detail view, the detail view sets it to FALSE to give the user a chance to cancel the entered values (by tapping "Cancel").

 

Thanks again for all your feedback.

[Dave Guerin]

Hi Tarek,

 

Sorry for my slow reply, I've been a bit busy with other projects recently.

 

STV 3.4.2 fixed all the problems I was experiencing in that example project, great.

 

However when I updated to STV 3.4.2 in my app there are issues with the selected items changing between the detail view and the SCSelectionCell view. I'm still investigating but I think it's because I'm setting a filterPredicate on the selectionItemsFetchOptions. I'll do an updated example project and post a link here.

 

Regarding cell.commitChangesLive and a SCObjectSection, the documentation needs updating to reflect whats actually happening because it took me ages to work out why my selections weren't sticking, I have no Done button in my UI so STV wasn't committing any changes.

[Aris Kox]

Is it possible to have an STV version that compiles on the 64-bit simulator?

[Dave Guerin]

Hi Tarek,

 

The problems I was still experiencing with the SCSelectionCell was because I was setting a filterPredicate on the selectionItemsFetchOptions. Here's an example project:

 

https://dl.dropboxus...lectionCell.zip

 

Add SensibleTableView.framework and STV+CoreData.framework.

 

Build and Run.

 

Enable Edit Mode, add a Setlist manually, go into the Setlist, enable Edit Mode, add a Song, go into the Song, and then go into Instruments which is a SCObjectSelectionCell, enable Edit Mode and add a number of Instruments, for example Ins0, Ins1, Ins2, Ins3. 

 

Back up to the root view, and add the example data.

 

Go back to the manually added Setlist, drill down to the manually added Song, and into the manually added Instruments. Add a few more Instruments, Ins4, Ins5, Ins6, Ins7.

 

Then select some Instruments, Ins1, Ins3, Ins5, and Ins7. Going back up correctly show them as the selected items.

 

Go back into the Instruments and move Ins7 to be above Ins1. Going back up now shows Ins7, Ins3, Ins4, Ins6 as the selected items, which is incorrect.

 

SCSelectionCell is expecting the orderAttributeName values to be 0 to n -1. Because of the filterPredicate they are not ordered like that, there are more Instrument entity than are used in the SCSelectionCell, so reordering the Instruments causes other items to be selected.

 

In my main app I've worked round this by updated all the orderAttributeName from 0 to n -1 in the SCTableViewModelDelegate method tableViewModelWillBeginEditing: which looks to be working correctly.

 

All the "Example Data" Setlists will work as expected, until you add additional Instruments to them and then reorder the additional Instruments above already existing instruments.